alt Hacker NewsOn caring for user data: NeoVim caused Vim undo files to be deleted
Comments
As a Neovim user, this stopped me dead with painful realization: I may have suffered the same thing but didn't realize it. There was a time when I could not undo something, and it was after a Neovim upgrade.
Unlike Dr. Chisnall, I started my editor journey on Neovim, so it wasn't a transition that bit me. However, if the format of the persistent undo file is unstable, and Neovim just deletes it when it doesn't recognize the previous format, then it seems conceivable (to me) that an upgrade after changing the format would delete the file too.
Ouch. This is making me think about getting off of Neovim. Yes, FOSS comes as-is, but if there's an alternative...
I've used vim since the first time it appeared in Debian repos. I have been told a thousand times that NeoVim is better, more modern and solves many (conveniently never cited) issues. I just ignored it and carried on. Feeling terribly vindicated at this point as it's a feature I use regularly and have no idea that it would be an issue in NeoVim.
I was also a very early user of Neovim.
The way I personally remember it being positioned was “Vim, but with breaking changes.”
> 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.
Am I missing something? Are people using persistent undo as backup?
This seems however more like of a documentation and UX problem. Neovim should warn and ask before deleting old undo files, or at least back them up, but it's not neovim's fault if people don't use reliable backup and versioning systems. Relying on persistent undo for this is kind of a self inflicted wound.
Use the proper tools for the job. Saying that neovim developers "had no concept of a duty of care to their users" is really disrespectful. Neovim's Lua API is overflowing with care, you just need to go look.
According to the rev history for VIM, persistent undo arrived in version 7.3, released in 2010. So Chisnall may have used it since 2000, but he didn't have persistent undo for at least two of the books he wrote. And it means it wasn't "maintained for almost 20 years", it's at best 16.
But it is a nice feature.
I do that by using version control. I have it hooked to my editor so that "save" is "check in". Now I have persistent, versioned, copies of all my states independent of whatever tools I happen to be using.
Software developers do sometimes make promises to their users, but I think these promises ought to be explicit rather than assumed. You can't simply assume a "duty of care" and expect that other people will understand them the same way you do.
(Or rather, you can, but you will likely be disappointed.)
Undo files and persistent undo are not meant to work that way. They are just persistent across process restarts. That's all.
They live in ~/.cache which is defined as "user-specific non-essential (cached) data".
Despite this user's impressive résumé, they simply misunderstood the feature.
This incident not withstanding, persistent undo breaks my mental model of file state. I treat writes as commits, which allows an open and modify session to be an exploratory branch until I decide to save it.
It is counterintuitive in the same manner as when excel persists undo history chronologically across the running application process, and not separately per document.
Similarly AutoCAD intersperses application parameters and tool configurations alongside actual data operations in it's undo history.
For similar functionality in nano, if anyone's interested, every time you save (regardless of exiting), nano keeps a backup.
Not on by default, you have to enable it in your .nanorc (not least because you need to provide a backup folder where you want to store these backups).
Very handy. Occasionally I've deleted files accidentally or made destructive changes, and could restore a working version from the past as if I had a timemachine.
The discussion here is going to be hamstrung without direct access to the entire Mastodon post:
Today it's the work of a moment to get a coding agent to change the format of a file for you. I guess the point of this story is supposed to be like the famous Van Halen brown M&Ms contract clause. But the world is changing fast and I think it makes sense to start taking more ownership of your own computing experience, especially when the software you use is open source. If you don't like it, have an agent change it! You don't need to convince a maintainer of anything.
They are open source developers, giving away free software as a gift. There is no duty here.
We can speak, respectfully, of how important backwards compatibility is to us, and ask nicely for them to give more of their time to support it when their free sodftware isn't backwards compatible. Perhaps we can even offer to help implement it.
But they have no duty to do so or to "care" for their users. (They have already demonstrated they care for their users, btw, by giving them free software.)
EDIT: I missed an important part of the story, which is that they mutated existing files in a non-backwards compatible manner. That should have been avoided, I understand where the (secondary) author is coming from now.
>I deleted something from this file, maybe last week
Don't forget time travel: `:earlier 7d`
To be the devil’s advocate here, I think Vim needs less backwards compatibility, not more. In the sanctifying of “muscle memory” it completely stopped innovation, to the point of slowly drifting to obscurity.
Of the over a hundred students I taught when I helped out in uni, basically no one wanted to learn it, despite my enthusiasm.
And I sympathise. As I get older, I slowly grow more and more distaste for software that does not respect my time enough to give me properly-crafted defaults. Vim, in the age of modern editors, cannot compete. Not without 20 plugins with conflicting shortcuts and its self-imposed cliff of a learning curve.
And I’m saying this from a place of love; I’ve been using Vim (at least as a VSCode extension) every day for the last 10 years. But it never really grew up to the promise that the “Vim Creep” essay [1] gave me.
[1]: https://web.archive.org/web/20190227031109/https://www.norfo...
:wq
While I agree with the article's point, we should note that collisions do not happen out of the box because Neovim defaults undodir to $XDG_STATE_HOME/nvim/undo/ (~/.local/state/nvim/undo/), while Vim defaults to storing .un~ files alongside the edited file or inside ~/.vim/undo/. Data loss only occurs if both editors are configured to share an undo directory or save inline .un~ files.
duty of care is kinda absent in too much of software engineering. its painfully missing in recent anthropic models because of the broken value framework they use for ethics. but broadly: i currently have the stance that text gen language models should prioritize users wellbeing rather than model orovider liability
"Vibe shift" is all the rage these days but one area where it's most apparent is modern software.
People of Raskin's vintage had a very humanist approach to computing. The mentality was very much an outgrowth of the cultural revolution of the 60s. Computer usage should be joyful rather than toiling. The computer should help you. It should make you feel good about what you create.
That stands in stark contrast today, where things are more hostile. Not just in terms of "Dark patterns", or writing off user needs for the sake of expediency... but even the way we talk about technology today. You need to use X, do Y or you're "not going to make it" / "escape the permanent underclass". It's bleak.
I recently restored a vintage Macintosh SE I picked up at VCF Midwest and despite its limitations that machine was an absolute JOY to use despite its limitations and nearly 40 years of age. This was a machine and software designed by Raskin's contemporaries and it shows.
Awkwardly speaking, Microsoft Word is a great example of a program that appreciates backward compatibility.
VIM should be in the title here as well
That’s why I stopped getting all those swap file messages every time I opened vim…
Continuing the analogy - rather than a relationship that might even possibly include a duty of care, the relationship of the modern surveillance industry (Faceboot, Google, etc) to its "users" is that of arms manufacturers to military targets.
Unsaid in the blog post is that disabling persistant undo is one of the most common config changes for vim users who bother to set things up the way they like. Persistent undo is what causes your filesystem to be littered with tilde files, which have the same name but prefixed with a tilde. Every file you touch with vim gets a tilde version. Your ls output becomes polluted with noise.
[dead]
> Apparently now they’re platforming white supremacists. I am completely unsurprised. Different facets of the same underlying attitude.
This was the end of the original Mastodon. Which is why I just can't with Mastodon or Bluesky. Casually tossing around ridiculous claims to back up an opinion on persistent undo.
[dead]
[flagged]
It’s Open source.
Some people just want to keep looking at the gift horse in the mouth.
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.
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...