Comment by dlisboa
8 hours ago
> 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.
Deleting important data without warning is not the same as not providing a feature users might want.
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]: https://xkcd.com/1172/
> 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.
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.
2 replies →
> It's a feature most software doesn't even have
"All software should be shit because most software is shit"
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.
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?
Vim's persist undo is disabled by default, perhaps for privacy reasons. edit: I see sebzim4500 got there first.
* https://bastian.rieck.me/blog/2015/persistent_undo_vim/
Stop looking for post-hoc justifications for behavior that is clearly wrong.
2 replies →
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
Not really since the feature is opt in
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.
Insane? Abhorrent?
Relax for a second. Get some perspective.
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.
2 replies →
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.
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?
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".
All they had to do was pick a different file name
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.
They knew about it in advance. They decided people shouldn't care about that data.
https://github.com/neovim/neovim/pull/13973#issuecomment-789...
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.