Re: vim.basic stürzt ab
Christian Brabandt - 24.10.17, 13:56:
> Martin Steigerwald schrieb am Dienstag, den 24. Oktober 2017:
[…]
> > - und ich an sich erwarte, dass Upstream-Entwickler und Tester so eine
> > krasse Geschichte schon bemerken, wenn sie die Auswirkungen von neuen
> > Standard- Optionen wie Maus-Handling testen,
>
> Aus deinem verlinkten Bugreport:
> ,----
>
> | These problems are more typically due to people/software setting
> | incorrect values for $TERM and/or related options in Vim ('ttymouse',
> | 'term', etc.). Vim can only act on the information it has, so when
> | that's incorrect -- garbage in, garbage out.
>
> `----
>
> Das hört sich schon ganz anders an als hier zu behaupten, dass es ein
> "krasse Geschichte" ist, den Entwickler leicht bemerken könnten.
Naja, ich hab ein Konsole-Fenster aufgemacht und das Vim benutzt. Das war
alles, was es dazu brauchte.
Mit anderen Worten: Ich hab den Fehler nicht gesucht. Der Fehler hat mich
gefunden, ohne, dass ich danach gefragt hätte.
> > Der Fehler war hier jedoch leicht reproduzierbar. Konsole-Fenster, SSH
> > auf eine Debian 9 Box, evtl. noch Screen dazwischen, vim aufmachen,
> > versuchen Datei zu bearbeiten. Schreibmarke springt lustig umher und
> > Vim reagiert nicht mehr wirklich auf Anfrage. Ich glaub, das wurde
> > besser… als ich dann mal temporär in ein anderes Fenster klickte.
> > Davor war Vim jedoch wiederholt schlicht unbenutzbar.
>
> Hier fängt es ja schon an: Was hast Du denn für ein Terminal benutzt?
> Wie ist es konfiguriert, worauf ist $TERM gesetzt? Benutzt Du gpm (bzw.
> gibt es da eigentlich noch)? Du hast die Maus nicht benutzt? Wie ist
> deine Vim Konfiguration, oder benutzt du nie eine .vimrc Datei, also
> reproduzierbar mit vim --clean?
$TERM ist xterm-256color – ich hab da nix angepasst, das dürfte also in
Konsole Standard sein. Konsole hat die übliche XFree86-Tastenbelegung
eingestellt. Da hab ich auch nix geändert. Screen läuft bis auf die
Statuszeile mit Standard-Einstellungen bzw. mit "term screen-256color", weil
Screen sonst ein Terminal wählt, dass weder Debian 8, noch SLES 12 noch RHEL 7
unterstützten¹
[1] screen: after sshing, some commands give error "Error opening terminal:
screen.xterm-256color."
https://bugs.debian.org/854414
vimrc.local und wie ich im verschiedenen Threads hier mehrfach erwähnte: Keine
eigene ~/.vimrc, sonst hätte ich mit den kaputten neuen VIM-Einstellungen ja
nix am Hut gehabt.
" Keine defaults.vim
" Sinnvolle VIM-Konfiguration, keine Maussteuerung, kein Zeilenumbruch usw.
usf., siehe:
" vim: 'set mouse=' in /etc/vim/vimrc.local is ignored unless ~/.vimrc exists
" https://bugs.debian.org/864074
let g:skip_defaults_vim = 1
" Syntax-Highlighting
syntax on
" Zeilennummern
set number
" Optionale Anzeige von Formatierungszeichen mit :set list
set list listchars=tab:»·,trail:·
set nolist
" Hintergrund auf dunkel, da ich mittlerweile meistens Terminals mit
" scharzem Hintergrund hab, wie es in Konsole aus KDE 4 Standard ist
set bg=dark
" Zeile, in der die Schreibmarke ist, markieren
" Vim - Der Supereditor
" Thomas Birnthaler
" http://www.franken.de/veranstaltungen/knf-kongress/2007/vortraege/vim-der-supereditor/
" http://www.franken.de/uploads/media/Vim.pdf
set cursorline
(Das mit dem Zeilenumbruch war evtl. was Anderes. James sagte, dazu definiert
die defaults.vim nix)
vim ist 2:8.0.1144-1+b1… was es zum Zeitpunkt war, als ich die Fehler
bemerkte, weiß ich nicht mehr. Irgendwas zwischen der Version in Stretch und
dieser aktuellen Version in Unstable.
> > "evtl. noch Screen dazwischen"
>
> Das macht das Analysieren des Fehlers nochmal deutlich komplexer.
>
> Gib mal bitte eine reproduzierbares Beispiel an, also welches Terminal
> involviert ist, was ist $TERM, starte vim --clean, `:set mouse=a`, gehe
> in Insertmodues, klicke mit der Maus, etc. Wann genau springt die
> Schreibmarke? Welches ist die getestete Vim Version?
Christian, auf einen Punkt hast Du Dich nicht mehr bezogen und ihn in Deiner
Antwort offenbar auch nicht beachtet:
> - ich im allgemeinen etwas besseres zu tun habe, als Fehler in Funktionen zu
> berichten, die ich ohnehin nicht nutzen würde, auch wenn sie funktionieren
> würden, und dann dazu noch auf Nachfragen der Entwickler / Paketbetreuer zu
> antworten,
Damit meine ich genau das.
Ich habe keine Lust, weitere Zeit darin zu investieren, das Fehlverhalten mit
einer Vim-Funktion zu analysieren, die ich gar nicht nutze.
Also nix vim --clean, vim irgendeine Option oder irgendwelche weiteren Tests
von meiner Seite. Das ist nämlich genau das Problem:
Neue Standard-Einstellungen, z.B. in Vim und Screen, in Debian Stretch machen
Probleme auf Benutzer-Systemen und sorgen dafür, dass Anwender Zeit aufwenden
müssen, um diese Probleme zu beheben. Ich finde es jetzt etwas unfair, jetzt
noch gebeten zu werden, weitere Zeit dafür aufzuwenden, eine Funktion zu
debuggen, die mich nullkommanix interessiert. Wenn ich einen GUI-Editor will,
dann nehme ich Kate. Der funktioniert auch einfach so Out of the box, ohne
dass ich groß an der Konfiguration rum basteln muss.
Aus meiner Erfahrung mit obigen Screen-Verhalten weiß ich, dass ich in ein
weiteres Debugging dieser Fehlfunktion mit Leichtigkeit einen halben Tag und
mehr investieren möchte. Dabei möchte ich doch einfach mit Funktionen in Ruhe
gelassen werden, die offenbar zumindest auf einem Teil der Anwender-Setups
nicht gescheit funktionieren.
Danke für Deine Beachtung!
Danke,
--
Martin
Reply to: