Remix.run Logo
▲ jeremyjh 2 hours ago

This story has no references that support the author's version of events, but it does appear to be substantially true that:

1. The change would break undo history, for both Neovim and Vim [see edit: this is not the really the case]

2. This means Neovim would delete data created by a different program, on another user's computer.

3. This was known before the feature was released.

4. They did it anyway.

I don't think there can really be any post-hoc justification of this.

https://github.com/neovim/neovim/pull/13973#issuecomment-789...

edit: I missed an important detail. The user specified the same path for undodir in both nvim and vim. Vim requires a path to enable the feature - there is no shared default path. The user sharing a path changes the story considerably in my view, because now this is a case of nvim deleting data created by nvim as an alternative to writing a data migration for it.

I could still disagree with that, but it makes alternatives like "just use a different path" more complicated at a minimum and really changes my read of this situation completely. I think Neovim's decisions are justfiable in this context. Maybe they could have saved the contents of the old undo folder somewhere and notified the user - arguably that would be more empathic I don't really agree they had a moral duty to do this.

▲dtech 2 hours ago | parent | next [-]

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

▲buu700 16 minutes ago | parent | next [-]

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.

▲ 19 minutes ago | parent | prev | next [-]
[deleted]
▲ an hour ago | parent | prev | next [-]
[deleted]
▲wonnage an hour ago | parent | prev [-]

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

▲dtech 14 minutes ago | parent [-]

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.

▲johnnypangs 42 minutes ago | parent | prev | next [-]

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.

▲ 18 minutes ago | parent | next [-]
[deleted]
▲johnnypangs 31 minutes ago | parent | prev [-]

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

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

▲ 22 minutes ago | parent [-]
[deleted]
▲Insanity 2 hours ago | parent | prev | next [-]

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).

▲schmichael an hour ago | parent [-]

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.

▲loeg 2 hours ago | parent | prev | next [-]

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.

▲jeremyjh an hour ago | parent [-]

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

▲loeg 40 minutes ago | parent [-]

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?

▲ 21 minutes ago | parent [-]
[deleted]
▲ludicrousdispla 2 hours ago | parent | prev [-]

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