Thread

On caring for user data: NeoVim caused Vim undo files to be deleted

384 points · 346 comments · jandeboevrie

jeremyjh · 1790526713 · focus · HN ↗
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.
<a href="https://github.com/neovim/neovim/pull/13973#issuecomment-789262094" rel="nofollow">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.
1. dtech · 1790528548 · focus · HN ↗
  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
  1. [deleted] · 1790530368 · focus · HN ↗
    [deleted]
  2. wonnage · 1790530988 · focus · HN ↗
    So if a program decided it owned .cache and deleted it every startup you’d be fine with it?
    dtech · 1790533176 · focus · HN ↗
    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.
    freehorse · 1790538604 · focus · HN ↗
    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.
    yjftsjthsd-h · 1790538414 · focus · HN ↗
    Honestly, kinda? It'd be rude and cause a performance regression, but it shouldn't break anything.
  3. [deleted] · 1790532893 · focus · HN ↗
    [deleted]
  4. buu700 · 1790533036 · focus · HN ↗
    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.
  5. MatthiasPortzel · 1790534813 · focus · HN ↗
    NeoVim docs say it defaults to "$XDG_STATE_HOME/nvim/undo//". Do you have a source for ~/.cache?
    => <a href="https://neovim.io/doc/user/options/#'undodir'" rel="nofollow">https://neovim.io/doc/user/options/#'undodir'
  6. soraminazuki · 1790535627 · focus · HN ↗
    That's some weird technicality that has nothing to do with the issue while also being completely false.
    <a href="https://github.com/neovim/neovim/blob/fc3f0041fbe01c96f38224d65d27664b22b5ef78/runtime/doc/options.txt#L7146" rel="nofollow">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.
    <a href="https://neovim.io/doc/user/undo/#persistent-undo" rel="nofollow">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.
  7. kelnos · 1790547395 · focus · HN ↗
    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".
    em-bee · 1790630329 · focus · HN ↗
    it's not the default place, it's where the user decided to put it.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.