Thread

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

384 points · 346 comments · jandeboevrie

dlisboa · 1790522895 · focus · HN ↗
> the attitude that just because something is a persistent file on your filesystem that contains data that you might want is no reason for their program not to delete it meant they had no concept of a duty of care to their users.
That's the wrong way to look at it. NeoVIM has a different concept of care for their users. They're optimizing for another kind of care, more in line with modern expectations, which VIM did not care about (hence the fork).
It's not better or worse, just different.
This same article could've been written about how VIM has no native LSP integration or autocomplete and they don't have duty or care for their users.
1. pdonis · 1790523038 · focus · HN ↗
  Deleting important data without warning is not the same as not providing a feature users might want.
  1. luma · 1790525196 · focus · HN ↗
    There is a flip side to this - is vim encrypting this data it keeps forever? If I delete something I consider sensitive, I might unwittingly be recording that presumed-deleted piece of data to my user profile somewhere to be deleted never.
    jeremyjh · 1790525382 · focus · HN ↗
    Stop looking for post-hoc justifications for behavior that is clearly wrong.
    phoghed · 1790526022 · focus · HN ↗
    Second time in this thread you’re telling other people how to think and behave because they aren’t acting like you
    tehwebguy · 1790527479 · focus · HN ↗
    OK and you are doing the dril wise man tweet sincerely
    phoghed · 1790556115 · focus · HN ↗
    How would you know?
    sebzim4500 · 1790525712 · focus · HN ↗
    Not really since the feature is opt in
    MaxBarraclough · 1790525779 · focus · HN ↗
    Vim's persist undo is disabled by default, perhaps for privacy reasons. edit: I see sebzim4500 got there first.
    * <a href="https://news.ycombinator.com/item?id=49867678">https://news.ycombinator.com/item?id=49867678
    * <a href="https://bastian.rieck.me/blog/2015/persistent_undo_vim/" rel="nofollow">https://bastian.rieck.me/blog/2015/persistent_undo_vim/
    webstrand · 1790525808 · focus · HN ↗
    That doesn't justify its deletion, it might justify warning the user, but unconditionally deleting data not owned by the app shared with other apps?
    nikanj · 1790527460 · focus · HN ↗
    How could you possibly encrypt it in a way that holds water? Any attacker who cares enough to get your undo file can also get your undo keys, unless you want to wire a whole system of undo-now-requires-password-auth-with-MFA
  2. crote · 1790527965 · focus · HN ↗
    It's a feature most software doesn't even have, and it is off-by-default. If you rely on your undo history to store "important data", you are doing something horribly wrong - to the level of storing your critical emails in the Trash folder.
    Persistent undo exists to recover from an accidental write-and-quit mid-session nuking some stuff you really didn't intend to delete. If you care about its contents beyond a handful of hours, you either need to adopt proper version management, or start making backups.
    Reading the PR the change was needed because the old undofile format was fundamentally broken. They considered making an undofile-upgrade mechanism, but it would've caused more issues that it would've solved. In other words: stuck between a rock and a hard place.
    A duty of care also means occasionally having to break things to make it better, or else you end up being stuck with spacebar heating[0] forever. As a user it does suck, but that's the price you have to pay for using actively-developed software.
    [0]: <a href="https://xkcd.com/1172/" rel="nofollow">https://xkcd.com/1172/
    pdonis · 1790531927 · focus · HN ↗
    > Persistent undo exists to recover from an accidental write-and-quit mid-session nuking some stuff you really didn't intend to delete.
    That's one use case, sure, but not the only possible one.
    > Reading the PR the change was needed because the old undofile format was fundamentally broken.
    That's a good reason to have a new undo file that's completely separate from the old one, and use the new one instead, and tell users "Hey, whatever undo information you had in your old undo file isn't accessible any more through neovim, you'll have to use vim if you need to get to it."
    It's not a good reason for just deleting the old undo file with no warning. All the new version needs to do is ignore it, not nuke it.
    applfanboysbgon · 1790538599 · focus · HN ↗
    > It's a feature most software doesn't even have
    "All software should be shit because most software is shit"
    soraminazuki · 1790540139 · focus · HN ↗
    User data shouldn't be silently deleted just because you think they aren't worthy enough. Especially when the name of the feature, persistent undo, and the docs explicitly promise that the edit history will be preserved.
    xigoi · 1790542196 · focus · HN ↗
    The user data in question lies in ~/.cache, which is a directory for files that aren’t meant to last long.
    soraminazuki · 1790544062 · focus · HN ↗
    That's completely false and also irrelevant to the point I made. Even if true, it doesn't justify deleting user data in direct conflict with what the docs say.
    <a href="https://news.ycombinator.com/item?id=49869740">https://news.ycombinator.com/item?id=49869740
2. jeremyjh · 1790525324 · focus · HN ↗
  It is insane that people are defending behavior that is clearly abhorrent just because they like the software. Are the claims even true? If they are, you should be updating your opinions about the person writing this software.
  1. dlisboa · 1790526058 · focus · HN ↗
    Insane? Abhorrent?
    Relax for a second. Get some perspective.
    jeremyjh · 1790526882 · focus · HN ↗
    My perspective is that the Neovim maintainer implemented a change that would delete data created by another program on other people's computers. They knew this would happen in advance, and it was done anyway.
    em-bee · 1790545174 · focus · HN ↗
    vim and neovim have different defaults for the undo file, if neovim overwrites a vim file then it can only be because the user changed the paths for both to be the same. in that case neovim had no way of knowing that the file was used by another program.
    kelnos · 1790549038 · focus · HN ↗
    AFAICT neither has any default for `undodir`; the user must set it explicitly. I think a user could be forgiven for assuming that it was fine to use the same value when trying out a migration from vim to neovim, and that neovim wouldn't actively delete vim's state data.
    Sure, maybe they should have backed it up or used a different directory, but I think it's reasonable to expect that many people wouldn't. If a software developer is only going to consider the scenario where their users are thinking/behaving exactly as they are, then they aren't particularly good at what they're doing.
    em-bee · 1790559714 · focus · HN ↗
    vim: Undo files are normally saved in the same directory as the file
    neovim: by default they are saved to the dedicated directory in the application data folder
    I think a user could be forgiven for assuming that it was fine to use the same value when trying out a migration from vim to neovim
    neovim would also overwrite its own old version of the file. the point is that the expectation that neovim should watch out for files that are used by other applications is in my opinion not reasonable. it won't even watch out for its own old undo files.
    users may have the expectation that neovim and vim are compatible, but that expectation is simply not entirely fulfilled. you can't share config files unless you have some minimal ones that just happen to work. so why would you be able to share other files?
    the question is, how are these expectations formed, and what is reasonable to expect?
    when it started out neovim was very compatible with vim. but from my experience with FOSS and based on the stated goal of neovim at least to me it was clear that compatibility was not going to last. not everyone shares that experience, and thus their expectations are different. neovim should perhaps make that more clear and for one be aware that people expect compatibility and warn users accordingly. an argument could be made that if a user changes the undodir value, there is a higher chance that they may try to use the same for vim. but then vim devs would need to do that too.
    but does not considering that make devs not good at what they are doing? i don't think so. for one, if someone thinks the devs are not good enough they should stop using neovim (as some people here in the thread announced they are doing. their choice). personally i think this is average for FOSS and good enough. we can't expect everyone to be perfect. the correct response to an issue besides reporting it is not to complain but to contribute a fix.
    zeratax · 1790846914 · focus · HN ↗
    that's not what is happening here though?
    <a href="https://github.com/neovim/neovim/pull/13973#issuecomment-879067052" rel="nofollow">https://github.com/neovim/neovim/pull/13973#issuecomment-879...
    >> 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.
  2. [deleted] · 1790526581 · focus · HN ↗
    [deleted]
  3. kebman · 1790527338 · focus · HN ↗
    From Cambridge Dictionary:
```markdown
abhorrent
/əbˈhɒr(ə)nt/
Abhorrent is an adjective that means morally very bad, hateful, or causing strong disgust and loathing.
```
    I realise that this causes strong disgust and loathing in you, but can you please expand upon how it's morally very bad to prioritise speed and ease of use over undelete capability in Neovim? Are you unable to make backups or use Git?
    overfeed · 1790528761 · focus · HN ↗
    You are presenting a false dilemma: Neovim could have easily done both without the deletion. Willful negligence is morally very bad when it can cause user harm.
    > Are you unable to make backups or use Git?
    Ah yes, the old perty theft justification as applied to intentionally-inflicted data loss; "They won't mind if I take/delete this, they (should) have insurance".
  4. oh_my_goodness · 1790528442 · focus · HN ↗
    Sci-fi premise. Somewhere [1] there is a message board where developers openly celebrate those feelings of dislike and disdain toward users.
    On that board, silently deleting a user's files is obviously justified. What would be out of line is complaining about software silently deleting user files.
    [1] Long ago. Galaxy far away.
3. lokar · 1790526257 · focus · HN ↗
  All they had to do was pick a different file name
  1. dlisboa · 1790526585 · focus · HN ↗
    True. But it’s not like they planned some vengeance against the VIM backup file.
    People are making it sound like this is a huge company with a product and not a grouping of curious people with a couple hours of free time on a Sunday.
    Most likely they never thought about it, then it broke, then it was not impactful enough to fix on their free time compared to other stuff.
    jeremyjh · 1790527012 · focus · HN ↗
    They knew about it in advance. They decided people shouldn't care about that data.
    <a href="https://github.com/neovim/neovim/pull/13973#issuecomment-789262094" rel="nofollow">https://github.com/neovim/neovim/pull/13973#issuecomment-789...
    roryirvine · 1790527560 · focus · HN ↗
    But they hold themselves out as being a normal software project, suitable for use by casual users. They even talk about having a "stable release" and advertise various sponsors.
    If it's really just a toy with no expectation of not unexpectedly destroying user data then they ought to make that more clear.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.