NeoVim löschte seine Undo-Dateien – und ein Nutzer vertraut ihm nie wieder
"They had no concept of a duty of care to their users."
Der Informatiker David Chisnall nutzt vim seit 2000 und schätzt dessen persistentes Undo, das über 20 Jahre und mehrere große Versionssprünge hinweg zuverlässig funktioniert. Als er NeoVim testete, stellte er fest, dass es das Undo-Format änderte, die alten vim-Undo-Dateien kurzerhand löschte und durch für vim unlesbare Dateien ersetzte. Die Antwort der Entwickler: Das Format sei instabil, Nutzer sollten sich nicht auf die Daten einer ausdrücklich „persistenten“ Funktion verlassen. Für Chisnall ein klarer Verstoß gegen Raskins Erste Regel – und ein Grund, NeoVim nie wieder zu verwenden.
Die Autoren haben sofort gezeigt, dass man ihnen keines meiner Daten anvertrauen kann. Das Brechen des persistenten Undo könnte ich als Bug verzeihen, aber die Haltung, dass die bloße Tatsache, dass etwas eine persistente Datei auf deinem Dateisystem ist, die Daten enthält, die du vielleicht willst, kein Grund für ihr Programm sei, sie nicht zu löschen, bedeutete, dass sie kein Konzept von einer Fürsorgepflicht gegenüber ihren Nutzern hatten.
- jeremyjh
Diese Geschichte enthält keine Belege, die die Version des Autors stützen, aber es scheint im Wesentlichen wahr zu sein, dass:
1. Die Änderung würde die Undo-Historie zerstören, sowohl für Neovim als auch für Vim [siehe Bearbeitung: das ist nicht wirklich der Fall]
2. Das bedeutet, dass Neovim Daten löschen würde, die von einem anderen Programm auf dem Computer eines anderen Nutzers erstellt wurden.
3. Das war bekannt, bevor das Feature veröffentlicht wurde.
4. Sie haben es trotzdem getan.
Ich glaube nicht, dass es dafür wirklich eine nachträgliche Rechtfertigung geben kann.
https://github.com/neovim/neovim/pull/13973#issuecomment-789...
Bearbeitung: Ich habe ein wichtiges Detail übersehen. Der Nutzer hat denselben Pfad für undodir sowohl in nvim als auch in vim angegeben. Vim erfordert einen Pfad, um das Feature zu aktivieren – es gibt keinen gemeinsamen Standardpfad. Dass der Nutzer einen Pfad teilt, ändert die Geschichte meiner Meinung nach erheblich, denn jetzt ist es ein Fall, in dem nvim Daten löscht, die von nvim erstellt wurden, als Alternative zum Schreiben einer Datenmigration dafür.
Ich könnte dem immer noch widersprechen, aber es macht Alternativen wie „verwende einfach einen anderen Pfad“ zumindest komplizierter und ändert meine Lesart dieser Situation völlig. Ich denke, Neovims Entscheidungen sind in diesem Kontext vertretbar. Vielleicht hätten sie den Inhalt des alten Undo-Ordners irgendwo speichern und den Nutzer benachrichtigen können – das wäre wohl einfühlsamer gewesen. Ich stimme nicht wirklich zu, dass sie eine moralische Pflicht dazu hatten.
- gavinhoward
Als Neovim-Nutzer hat mich das mit schmerzhafter Erkenntnis abrupt gestoppt: Vielleicht habe ich dasselbe erlitten, ohne es zu merken. Es gab eine Zeit, in der ich etwas nicht rückgängig machen konnte, und das war nach einem Neovim-Upgrade.
Anders als Dr. Chisnall begann ich meine Editor-Reise mit Neovim, also war es kein Übergang, der mich gebissen hat. Wenn jedoch das Format der persistenten Undo-Datei instabil ist und Neovim sie einfach löscht, wenn es das vorherige Format nicht erkennt, dann erscheint es (mir) denkbar, dass ein Upgrade nach einer Formatänderung die Datei ebenfalls löschen würde.
Autsch. Das bringt mich dazu, über einen Ausstieg aus Neovim nachzudenken. Ja, FOSS kommt wie es ist, aber wenn es eine Alternative gibt...
- sdcfgy
Ich benutze vim seit dem ersten Mal, als es in den Debian-Repos auftauchte. Mir wurde tausendmal gesagt, dass NeoVim besser, moderner sei und viele (bequemerweise nie zitierte) Probleme löse. Ich habe es einfach ignoriert und weitergemacht. Fühle mich jetzt furchtbar gerechtfertigt, da es ein Feature ist, das ich regelmäßig nutze und von dem ich keine Ahnung hatte, dass es in NeoVim ein Problem sein würde.
- BarbaryCoast
Laut der Revisionsgeschichte von VIM kam persistentes Undo in Version 7.3, veröffentlicht 2010. Chisnall mag es also seit 2000 verwendet haben, aber für mindestens zwei der Bücher, die er geschrieben hat, hatte er kein persistentes Undo. Und das bedeutet, es wurde nicht „fast 20 Jahre lang gepflegt“, sondern bestenfalls 16.
Aber es ist ein nettes Feature.
Ich mache das über Versionskontrolle. Ich habe sie an meinen Editor angebunden, sodass „Speichern“ gleich „Einchecken“ ist. Jetzt habe ich persistente, versionierte Kopien all meiner Zustände, unabhängig von den Tools, die ich gerade benutze.
- gchamonlive
Übersehe ich etwas? Nutzen Leute persistentes Undo als Backup?
Das scheint mir jedoch eher ein Dokumentations- und UX-Problem zu sein. Neovim sollte warnen und fragen, bevor alte Undo-Dateien gelöscht werden, oder sie zumindest sichern, aber es ist nicht Neovims Schuld, wenn Leute keine zuverlässigen Backup- und Versionierungssysteme verwenden. Sich dafür auf persistentes Undo zu verlassen, ist eine Art selbst zugefügte Wunde.
Verwende die richtigen Werkzeuge für die Aufgabe. Zu sagen, die Neovim-Entwickler hätten „kein Konzept einer Fürsorgepflicht gegenüber ihren Nutzern“ gehabt, ist wirklich respektlos. Neovims Lua-API strotzt nur so vor Fürsorge, man muss nur nachsehen.
- ghtbircshotbe
Neovim wird als Plug-in-Ersatz für vim beworben, was zu 100 % nicht stimmt. Viele Dinge sind anders, einschließlich Undo-Dateien und :!. Ich kann mich nicht an das Feature erinnern, das mich aufgeben ließ, aber irgendwann wurde der Wechsel mehr Arbeit als es wert war, wenn man bedenkt, dass mein vim-Setup bereits funktioniert. Ich bin nicht sicher, was ich tun würde, wenn ich heute anfangen würde.
- natbennett
Ich war auch ein sehr früher Nutzer von Neovim.
So wie ich es persönlich in Erinnerung habe, wurde es positioniert als „Vim, aber mit Breaking Changes“.
- justinmk
Vim undofile „Datenverlust“ passiert, weil Vim (VIM!) die undofile zurücksetzen wird, wenn ein externes Tool (git, nano) die Datei geändert hat, während Vim nicht läuft.
Nur zu, probier es aus:
# Mach ein paar Änderungen, dann beende vim (denk dran, zu beenden).
vim --clean +'set undofile' foo.txt
# Bearbeite dieselbe Datei mit non-vim; speichere die Änderungen.
nano foo.txt
# Öffne die Datei erneut und versuche „u“. Dann poste auf bluesky über Vims „Fürsorgepflicht“.
vim --clean +'set undofile' foo.txt
Das ist dokumentiert unter `:help undo-persistence`.
- dlisboa
> die Haltung, dass nur weil etwas eine persistente Datei auf deinem Dateisystem ist, die Daten enthält, die du vielleicht willst, das kein Grund für ihr Programm ist, sie nicht zu löschen, bedeutete, dass sie kein Konzept einer Fürsorgepflicht gegenüber ihren Nutzern hatten.
Das ist die falsche Sichtweise. NeoVIM hat ein anderes Konzept von Fürsorge für seine Nutzer. Sie optimieren auf eine andere Art von Fürsorge, mehr im Einklang mit modernen Erwartungen, die VIM nicht wichtig war (daher der Fork).
Es ist nicht besser oder schlechter, nur anders.
Derselbe Artikel hätte über VIM geschrieben werden können, wie es keine native LSP-Integration oder Autovervollständigung hat und sie keine Pflicht oder Fürsorge für ihre Nutzer haben.
- RVuRnvbM2e
Undo-Dateien und persistentes Undo sind nicht dafür gedacht, so zu funktionieren. Sie sind nur persistent über Prozessneustarts hinweg. Das ist alles.
Sie liegen in ~/.cache, was definiert ist als „benutzerspezifische nicht essentielle (zwischengespeicherte) Daten“.
Trotz des beeindruckenden Lebenslaufs dieses Nutzers hat er das Feature einfach missverstanden.