“They had no concept of a duty of care to their users.”
99 points by raymii
99 points by raymii
Some context from a related HN comment before the pitchforks come out:
While I agree with the article's point, we should note that collisions do not happen out of the box because Neovim defaults undodir to $XDG_STATE_HOME/nvim/undo/ (~ /.local/state/nvim/undo/), while Vim defaults to storing .un~ files alongside the edited file or inside ~ /.vim/undo/. Data loss only occurs if both editors are configured to share an undo directory or save inline .un~ files.
Data loss only occurs if both editors are configured to share an undo directory
which is going to be the case for ~100% of persistent undo users switching from vim to neovim, becuase you'll have the preference for this in your vimrc which you'll surely reuse across the two editors.
(the quote feels like such a classic orange site "gotcha" comment....)
why do you have an explicit preference for location of you persistent undo files?.. I didn’t have it configured on vim, and I don’t have it configured on neovim, because the default is Good Enough.
UPD: oh, is it impossible to get vim to store undo files in a centralized location unless you set it manually? then yes, meh, you’d probably have it set.
Having accidentally deleted important things from the file and not noticed for weeks is not a good look on the editor...which I have used for a decade and I still accidentally delete huge hunks as well. I usually catch it but glad I'm not the only one.
In case anybody is wondering afier reading this: yes persistent undo still works in Neovim. No it is not backwards compatible with VIM.
For folks who may be in hurry to read the article.
Additionally, the author is critiquing the neovim team for breaking Persistent Undo, a feature that saves per-file undo on the filesystem to allow you to pick up your changes even weeks later. The author believed this was a big and was shrugged off by the neovim team. The above should now make sense in context.
https://github.com/neovim/neovim/pull/13973#issuecomment-879067052
It shouldn't overwrite an unreadable file tho, unless I have completely misread the code.
It doesn't, but because it reads the vim-specific config file from the vim-specified location it then writes a file in that location with the name that vim expects, so files that I first edited in neovim ended up with undo files that vim couldn't read and vice versa. Both programs complained
Chisnall confirmed 5 years ago that it doesn't actually overwrite his old undofile, yet he keeps beating this horse every now and then
Also note that Vim has already broken the format once, all Neovim did was break it again (it changed the version from 2 to 3, 1 to 2 was all Vim)
The second comment really does read like there’s no data loss or deletion, there is just an ugly situation where both systems write files to the same location that the other one can’t read (of course vim is blameless here, since it was writing files there before neovim existed).
Neovim doesn't write to the same location as Vim unless you configure it to, which Chisnall did:
Neovim reads
$VIMINIT, which for me is set to source${XDG_CONFIG_HOME}/vimrc. It therefore reads my vimrc file, which sets the undo location. I had to modify my vimrc with an ifhas("nvim")block to set these locations.
I will reiterate that Neovim is completely blameless here too
a somewhat cursed use of this -- there are several unversioned org mode files and shell scripts across my systems that are very much throwaways -- from time to time i will need to edit again, and think "why the heck did i change this last time?". Spamming u turns into a little time machine in that sense. I've come to rely on similar behaviors in Emacs as well.
The annoying bit is that out-of-editor changes -- so version control updates in shared repos, LLMs making edits (more recently) -- will break the persistent undo. The latter has been especially frustrating.