Hacker News Reader

The feature that was broken is called persistent undo. The docs unambiguously state that edit history will be preserved unless Vim/Neovim detects that the "undo file is no longer synchronized with the file it was written for."

https://neovim.io/doc/user/undo/#_5.-undo-persistence

So even putting aside the Vim/Neovim interoperability angle, that contract was broken. Undo files created by old versions of Neovim will be deleted by more recent versions.

The interoperability issue can't be ignored either. Neovim was touted as a drop-in Vim replacement, and that needs to be taken into account when considering how changes affect users.

So many Neovim users have started by reusing their existing vimrc. I'm sure many still have ~/.config/nvim/init.vim symlinked to ~/.vimrc to this very day. With Vim, persistent undo is opt-in. Vim users who cared enough to opt in are highly likely to have explicitly set the path for undo files too. That's because Vim defaults it to the same directory as the file being edited, which clutters the filesystem. As a result, there are many users who shares undo files between Vim and Neovim simply because they reused their vimrc, not because they made the conscious choice to do so.

The data is stored in ~/.cache which has the contract that it user-wide cached data, which also means it can be deleted without severely impacting programs.

It seems the author has too high expectations of this feature, or vim is using an incorrect path to store this is they want to make it available more reliably

So if a program decided it owned .cache and deleted it every startup you’d be fine with it?

What a weird straw-man. The comparison here is a program breaking compatibility with a file in ~/.cache/... and deleting it instead of providing compatibility. I'd do that without thinking about it twice.

I don't see it as a strawman. The comparison here is a program breaking compatibility with a file _used by another program_. If vim and neovim undo files are incompatible, why does neovim delete vim's file instead of using its own file name/extension and not caring about vim's undo? And why do they use the same subdirectory even? To me it is a case of a program deleting cached files of another program, which, as a user, I see as deleting user data that said program should have touched.

Honestly, kinda? It'd be rude and cause a performance regression, but it shouldn't break anything.

This reads to me like a case of blame on both sides. Putting data you don't want to lose in ~/.cache is PEBKAC, but if that fact is incidental and NeoVim would have removed the undo history regardless of its filesystem path, then the point remains valid that NeoVim is deleting user data that isn't its place to delete.

A lot of the comments here are getting caught up in legal arguments which may or may not be valid. Those are irrelevant. No one is taking the NeoVim developers to court; the post is merely warning that they knowingly accepted behavior which can cause harm. The question is whether or not that choice was responsible, not whether it's legally actionable.

NeoVim docs say it defaults to "$XDG_STATE_HOME/nvim/undo//". Do you have a source for ~/.cache?

=> https://neovim.io/doc/user/options/#'undodir'

That's some weird technicality that has nothing to do with the issue while also being completely false.

https://github.com/neovim/neovim/blob/fc3f0041fbe01c96f38224...

The feature that was broken is called persistent undo. The feature was inherited from Vim. In case it's not obvious from the name, nowhere does it state in the docs for persistent undo that data may be deleted at any time.

https://neovim.io/doc/user/undo/#persistent-undo

That Neovim changed the default storage path for undo files is completely irrelevant to whether the contract for persistence should be broken.

That's the wrong place to store it. Data like that should be under $XDG_STATE_HOME (~/.local/state/ by default).

I would consider deleting my persistent undo state, which would be something that I would have specifically enabled, to be "severely impacting".

it's not the default place, it's where the user decided to put it.

I switched from Vim to NeoVim this year, after about 15 years on Vim.

Not withstanding this incident, I would say that on the whole it has been a good experience with Neovim. (I didn’t actually ever use the persistent undo functionality in vim. Guess because of VCS it’s less needed for my use-case).

Same timeline for me, but this was my 3rd or 4th attempt at switching. Not sure if something materially improved or maybe LLMs finally just got good enough at helping me convert.

Hadn’t tried previously, but will say that LLMs definitely helped me.

> I think Neovim's decisions are justfiable in this context.

Needing to know in advance that neovim requires a specifying a different undodir to vim, because neovim's persistent undo format is unstable even though vim's is stable, but the feature is called the same thing and neovim bills itself as a plug and play replacement for vim...

This is very predictably going to lead to loss of user data.

But you still have to share the undodir for both vim and neovim right? If your undo data was that precious why would you gamble the interoperability? You could just have them in different folders and it would be fine.

So the case is, you really need you undo history and want to try out neovim so you just copy paste you vimrc to the new place and accidentally delete your data? I don’t think it’s that bad personally. It’s bound to happen but it’s not automatic.

I have a far less sensationalist headline for this which is:

Two programs that save their cache in the same folder causes issues.

"Program that claims to be a drop-in replacement will arbitrarily delete data in ways that the program it replaces doesn't"

That headline would be inaccurate. Persistent undo is different than cache. Cache implies a temporary copy of data whose actual existence is elsewhere. Persistent undo is advertised as persistent, not as temporary.

In practice the feature is as persistent as your last git checkout. There are countless events (including git checkouts, vim recoveries) that simply reset the status of the "persistent" undo. Use a real VCS if you treasure your history as this is just a best effort feature.

It was ostensibly necessary for other, arguably more important features. Persistent undo maybe just isn't that important? I certainly don't use it nearly as much as the author seems to.

Why not give it a different name, so that it would not break vim?

Just editing the primary file without corresponding update to persistent undo record already breaks persistent undo. Do you prevent users from editing their own files in your text editor?

maybe they tried to undo the change, but were not able to

i think if program start and has a target as file and cannot read that file it should not proceed to overwrite it. maybe thats just me. that being said, it is silly to rely on programs to always behave how you expect. better to be careful.