Yeah, this hasn't been a problem since forever (or at least I haven't noticed). They had to break the undo file format a while ago to actually work correctly for byte-level buffer change events (very important for tree sitter and other plugins listening for buffer changes). The undo file format is versioned, too, so it's not just YOLO'd; Neovim has since forever returned an error saying there's a version incompatibility. The outrage here doesn't make a lot of sense to me.
The original author of this post (on Mastodon) appears to have a bone to pick with Neovim since it's "platforming white supremacists"? I couldn't figure out what this meant. Some sort of internet drama I guess.
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.)
This is absolutely true. On the other hand, if there's Vim, Neovim, emacs, MS Word, Google Docs etc and some treat me with respect and others do not, that might affect my choice of which software to use.
Sure. And likewise, users who care about backwards compatibility have no duty to do anything for the Neovim developers--they can simply use a different editor that suits their preferences.
The argument is that developers have a duty not to arbitrarily delete data on your system that you may have relied on that was produced by another program just because they’d like to replace it with something in their own format.
I don’t care if you’re volunteering your time; if you build something whose implied purpose and success depends on other people using it, you emphatically have a duty to those people not to silently destroy stuff that was there before your software was.
A duty, like a responsibility, can be something you feel or choose for yourself. The fact that the maintainers of some software don’t feel it is a perfectly good argument for not using that software. There is no necessary connection to compensation or transactional thinking.
This is a very apt analogy. If you give someone a car (or sell it cheap) and you know there is a problem with the car, then it is your duty to tell them. "Hey, I've been having trouble with the breaks they need to be pumped. Be careful about that."
By your reasoning, a doctor who volunteers to provide free care to people has no duty of care to those patients. This is patently absurd - ethics and norms are a large part of what defines a profession.
There is not a duty but there is an image and quality issue. Something many open source projects suffer from and should not.
And even mentioning that results in "fork it if you're not happy" which immediately turns everyone off who's had to maintain a fork to fix a minor issue in something before. And anyone who can't fork it is being told to go to hell.
Everyone needs to quite frankly get off their high horse, crank the ego down and listen to users. Because you're damaging open source with the attitude.
30 years ago, things were better. They got a lot worse, particularly since github appeared.
HN commenters constantly mistake “what I should do” with “what I am obligated to do.” Nobody is saying open source developers are legally mandated to be careful with user data. We are saying they should. There’s no need to haul out the license and put our lawyer hats on here. One can be within one’s legal rights and still be wrong.
They wrote this software with the explicit intention of offering it to other people to use. Their program deleted data created with a different program, on someone else’s computer. If they have no sense of duty that would preclude doing that, no one should use their software.
It's hardly a rant. Not once did either author question the birthright of the Neovim developers in Russian.
I think more software engineers should worry about this stuff. If I had to teach a bunch of juniors in a computer science or software engineering degree program, I'd make them read this as a case study alongside good ol' Therac-25. The software we create is _useful_. How it affects other people _matters_. We ought to care about that no matter what the legal disclaimers say.
I hate this attitude. It is what makes the free software community look like utter dicks to the user community, particularly those who can't really fork or contribute to it. It's a serious image issue.
Hell I can and have contributed and have been told to fuck off and fork it or entirely ignored.
Do you have a link to how this happened? From what I understand you’d have to point the undodir at the same place as vim for this to happen? It’s not this way by default and you have to put a copy of the exact same thing in your neovim vimrc right without understanding that it would do this?
The point was they did it in a completely stupid way and responded to a bug report about it in a way that suggested this might not be just the occasional stupid that we've all had slip into our code.
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...
If you ignore it, do you continue allowing edits to the file? Now undo history is corrupt and useless anyway. Or do you disallow editing until the user manually deletes some hidden, implementation-detail file for a feature they probably never use?
It's some sort of industry standard, though, isn't it? Google Chrome on Android auto-deletes the history database silently if it deems it corrupted (e.g., due to a bad write on a system with low storage). You just open your browser one day and it's all gone.
It feels like a mismatch in expectations. It's fairly obvious the developers consider the persistent undo feature to be a convenience for short-term continuity if you are exiting and re-entering the editor over a single edit session, not a long-term storage of the history of the file. All of their decisions make perfect sense in that context, but it seems that expectation is not shared by some of their users, who considered it to be an important piece of data meant to be kept long-term. This feels a bit odd to me, given the tendency for undo systems to be fragile anyway, and the documented fragility of this persistence. The author of this article even had deliberate workarounds for some of this fragility which I feel would put me in 'should I even trust this feature?' mode. To me the main fix would be updating the documentation to scream even more loudly "Don't expect this to stay around!".
To me it's a bit like storing your important files in a ramfs and then complaining that your OS doesn't respect user data when it crashes. Sure, it's not exactly a documented behaviour of the system, but you're also not storing your data in a place the developers of the OS expected you to put important data.
> but you're also not storing your data in a place the developers of the OS expected you to put important data.
So exactly the opposite of persistent undo?
The short-termism changes little here, losing weeks' worth of work just because you deleted it recently by mistake and then upgraded with the app deleting the undo, is also bad
That's the point, though, undo (in most applications) is a fragile place to hold much work, regardless of whether it normally survives restarting the app. You could argue about whether it should be that way (infinite, robust, persistent undo is a nice safety net in general), but I would not assume that is the case unless it's very well documented otherwise (and the UI is adjusted accordingly: you really need an undo tree, else a large series of undos followed by an accidental edit will also wipe out a lot of data), and neovim's documentation does not say that it is intended to work that way.
Sorry for my ignorance, but what is the usefulness of undo persistence after a IDE restart? Don't you normally save your changes and finish a piece of work before exiting an DE?
The reason why this feature is particularly useful in vi-likes is because they are not IDEs. I hop in and out of vi all day long. Depending on the task I might create a new tab, run a command in vi, or exit vi to run it. Vi’s appeal is that it is “just” an editor and your terminal and workstation form your un-integrated development environment.
One silly example: sometimes I'll open up source or config file to make a quick, temporary change in order to test something. But then instead of ctrl+z backgrounding it, I'll accidentally quit vim. Then I start it back up to undo the change, and find that there's no undo history.
I didn't know about persistent undo until seeing this posted here on HN, but now I've enabled it! Of course, turns out it's an unreliable feature on nvim... maybe I'll consider switching back to the original (for that and other reasons).
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.)
> 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 and they don't have duty or care for their users.
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.
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
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.
> 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.
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.
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.
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.
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.
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.
>> 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.
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".
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.
Continuing the analogy - rather than a relationship that could possibly include a duty of care, the relationship of the modern surveillance industry (Faceboot, Google, etc) to its "users" is that of arms manufactures to military targets.
"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.
Software’s purpose is clearly shifting from “what’s good for the user” to “what’s good for the developer.” Instead of enabling me, software now seeks to lock me in. Instead of making my life easier, software decisions are made based on what makes developers’ jobs easier. Instead of being careful with my data, software now comes with giant legal terms that allow developers to be utterly careless with it. Software is now designed primarily to funnel money to the developer, not to bring joy to the user.
And look at this article’s HN discussion. Many people indignantly defending it. “It’s open source. If you don’t like it deleting your data, don’t use it!”
Computer nerds are a rare breed. We like to be right. And we like to be arrogant. And if we have a solution to a harmful problem… it’s your fault for not being “smart enough” and you suffer your consequences.
Maybe we aren’t so rare. I can think of another group that values enduring hardship over progress making things easier for everyone.
> 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.
That's just how people market things these days, preying on desperation and fear of missing out. It's not how normal humans talk, I hope.
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.
No it’s just as crap as it always was. There just wasn’t much point in moving the code to anything else as it only gets updated once every 5-6 years.
It’s a utility that converts a horribly obsolete binary format from a thoroughly obsolete bit of hardware into text so it can be processed. Working since 1989.
Hah, makes perfect sense. I have a handful of ancient Perl scripts I run for specific purposes every great once in a while. If I used them enough to actually need to maintain them, I’d probably port them to Python or something. I think we both ended up in the same place via the same route.
It does something using neovim's internal terminal mode rather than use the file descriptors it was called with. Most commonly this breaks when a command produces an interactive command or uses a pager.
Bare vi does not have windows, visual selection mode, multiple level undo, color schemes, etc.
NVim wants to improve some defaults, which cannot be done if it is beholden to all legacy code. That being said, I still think this specific undo example is insane.
Vim is good enough now. The reason I switched to NeoVim in like 2015 is because it had async plugin support. With vanilla Vim at the time, if you had a lot of plugins it could get pretty slow and stuttery pretty quickly.
Vanilla Vim added it in 2016 I think, but by that time I had already fully switched to NeoVim and it didn't seem worth it to me to switch.
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.
Vim is always going to be obscure because it's not obvious from looking at it how you use it. Muscle memory is the entire point. You don't need to change any keybinds, and I don't.
As for default plugins, it'd be neat if they curated a set of optional ones, but nothing should be preinstalled.
I dream of a Vim that would embrace colours and Unicode and can better communicate modes and context.
I dream of a Vim that wóuld guide and teach me how to use it, so that it does not scare away people because they can’t close it.
I dream of a Vim that embraces the needs of editing contemporary programming languages and fills in its UX gaps correspondingly (changes single to double quotes, anyone? Function argument order?).
I dream of a Vim with native Git gutters.
I dream of a Vim with sane default leader commands.
I dream of a Vim where I see line numbers by default.
I dream of a Vim where “Y” is consistent with other commands.
I dream of a Vim that detects correct indentation by default. And that can visualise whitespace.
I dream of a Vim where Ctrl+V does not have an assigned action that looks like it blocks input.
I dream of a Vim that experiments with keyboard ergonomics, not just mnemonics.
I dream of a Vim where quintuple-tapping Escape is not a habit I subconsciously form why learning it.
I dream of a Vim I stumble on people discovering and exploring, and not have to persuade people for months just to try it.
Well in these ages of vibecoding. Maybe you are doing it for yourself. Or because you can? Actually caring of users hasn't been very high for most software for long time...
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.
vim power user left in shambles after training wheels removed from different version of the bicycle he's been riding 40 years
I don’t often need the persistent undo. But on the few occasions when I have needed it, it’s been invaluable: ooops, I deleted something from this file, maybe last week and one reboot ago, what was it? Undo until I find it, copy it, paste it into the current version. Or, a bit more commonly: I had this working, then I tidied it up ready to commit, now it isn’t working, what did I do?
It's time to just acknowledge that using modern software engineering practices and nano is far better than being stuck in the 1980s using vim undo as your DR solution.
> 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.
Of course they do not. Read the licenses. They explicitly tell you that there is no warranty or fitness of purpose. It explicitly tells you that it is not fit for purpose. Expecting it to be is your own duty.
I've always assumed that undo history is ephemeral in any application I use, other than maybe an application where history is first-class in a timeline like Fusion360. I'm surprised to hear that people rely on it being persistent.
It's more persistent than a session but that's it; (n)vim itself resets it from time to time as long as the file is changed without a edit in vim.
For example applying the recover file (well it's a huge pitfall in vim on its own) resets not only the current undo history but also the "persistent" one.
Not using it as a backup strategy. But it doesn’t matter. Vim has a feature, persistent undo. People are using it for whatever reason. Under your blessing or not. A different app, neovim, broke vim’s feature.
They don't get a pass because you disagree with an imagined use case.
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.
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?
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).
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.
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
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.
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.
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.
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.
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.
That headline would be inaccurate. Persistent undo is different than cache. Cache implies a temporary copy of data whose actual existence is elsewhere.
Persistent undo is advertised as persistent, not as temporary.
In practice the feature is as persistent as your last git checkout. There are countless events (including git checkouts, vim recoveries) that simply reset the status of the "persistent" undo. Use a real VCS if you treasure your history as this is just a best effort feature.
The feature that was broken is called persistent undo. The docs unambiguously state that edit history will be preserved unless Vim/Neovim detects that the "undo file is no longer synchronized with the file it was written for."
So even putting aside the Vim/Neovim interoperability angle, that contract was broken. Undo files created by old versions of Neovim will be deleted by more recent versions.
The interoperability issue can't be ignored either. Neovim was touted as a drop-in Vim replacement, and that needs to be taken into account when considering how changes affect users.
So many Neovim users have started by reusing their existing vimrc. I'm sure many still have ~/.config/nvim/init.vim symlinked to ~/.vimrc to this very day. With Vim, persistent undo is opt-in. Vim users who cared enough to opt in are highly likely to have explicitly set the path for undo files too. That's because Vim defaults it to the same directory as the file being edited, which clutters the filesystem. As a result, there are many users who shares undo files between Vim and Neovim simply because they reused their vimrc, not because they made the conscious choice to do so.
i think if program start and has a target as file and cannot read that file it should not proceed to overwrite it. maybe thats just me. that being said, it is silly to rely on programs to always behave how you expect. better to be careful.
> I think Neovim's decisions are justfiable in this context.
"A computer shall not harm your work or, through inaction, allow your work to come to harm."
"A computer shall not waste your time or require you to do more work than is strictly necessary."
"An interface is humane if it is responsive to human needs and considerate of human frailties."
Note in particular the third rule. Needing to know in advance that neovim requires a separate undodir to vim because neovim's persistent undo format is unstable, even though vim's is, but the feature is called the same thing and neovim bills itself as a plug and play replacement for vim...
This is not considerate of your user. If you are unwilling to move heaven and earth to preserve user data and carve a path through the weeds, even if it requires a whole other code path just to preserve expected behavior - well, you shouldn't be making end-user software.
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.
Maybe through autosave? If your editor makes a commit every time you're inactive for longer than X seconds that should solve that, which I'm pretty sure is how most editor undo stacks work at some level.
I just tried it in Nextcloud Notes on Android (FlorisBoard has undo/redo buttons), and it seems to work this way. If I type a bunch of words quickly and hit undo, it removes all of them. If I stop for a couple seconds between each word, it undos them one-by-one.
198 comments
[ 0.30 ms ] story [ 74.4 ms ] threadThe way I personally remember it being positioned was “Vim, but with breaking changes.”
The original author of this post (on Mastodon) appears to have a bone to pick with Neovim since it's "platforming white supremacists"? I couldn't figure out what this meant. Some sort of internet drama I guess.
Don't forget time travel: `:earlier 7d`
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.)
I don’t care if you’re volunteering your time; if you build something whose implied purpose and success depends on other people using it, you emphatically have a duty to those people not to silently destroy stuff that was there before your software was.
> The software is provided “as is”, without warranty of any kind, express or implied
Yes, OSS can start with just a passion without a duty, but as the scale grows you have a duty to make sure it does not have adverse effect.
If you don't like the duty, just make it die by building it crappy like VIM does.
“Ow, the gas pedal is actually a bear trap.”
“Why are you complaining? It’s free!”
And even mentioning that results in "fork it if you're not happy" which immediately turns everyone off who's had to maintain a fork to fix a minor issue in something before. And anyone who can't fork it is being told to go to hell.
Everyone needs to quite frankly get off their high horse, crank the ego down and listen to users. Because you're damaging open source with the attitude.
30 years ago, things were better. They got a lot worse, particularly since github appeared.
This is the extreme version of "I enjoy coding but I hate users."
It may be legally valid in absolute technical terms, but I'm going to take a lot of persuading that it's a healthy attitude.
By that logic, if Facebook gives away their services for free then they don't have the duty to protect their user's privacy and mental health?
They don't have to care about their users, it's a free software... If you don't like it, you can fork it or use something else
I think more software engineers should worry about this stuff. If I had to teach a bunch of juniors in a computer science or software engineering degree program, I'd make them read this as a case study alongside good ol' Therac-25. The software we create is _useful_. How it affects other people _matters_. We ought to care about that no matter what the legal disclaimers say.
Hell I can and have contributed and have been told to fuck off and fork it or entirely ignored.
Just by trying Neovim you can lose your vim undo file.
I don't know if this story is true, but you can't defend it when taken at face value.
The point was they did it in a completely stupid way and responded to a bug report about it in a way that suggested this might not be just the occasional stupid that we've all had slip into our code.
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 could see ignoring the old undo data or warning before discarding it but just silently wiping it is so user hostile it’s hard to comprehend.
If not, I wonder how Google justifies it.
Google is abysmal. In every sense of the word and in every product they touch.
To me it's a bit like storing your important files in a ramfs and then complaining that your OS doesn't respect user data when it crashes. Sure, it's not exactly a documented behaviour of the system, but you're also not storing your data in a place the developers of the OS expected you to put important data.
So exactly the opposite of persistent undo?
The short-termism changes little here, losing weeks' worth of work just because you deleted it recently by mistake and then upgraded with the app deleting the undo, is also bad
I didn't know about persistent undo until seeing this posted here on HN, but now I've enabled it! Of course, turns out it's an unreliable feature on nvim... maybe I'll consider switching back to the original (for that and other reasons).
`:earlier 1d`.
persistant undo is like a second brain to consolidate.
(Or rather, you can, but you will likely be disappointed.)
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 and they don't have duty or care for their users.
* https://news.ycombinator.com/item?id=49867678
* https://bastian.rieck.me/blog/2015/persistent_undo_vim/
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/
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 software should be shit because most software is shit"
https://news.ycombinator.com/item?id=49869740
Relax for a second. Get some perspective.
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.
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.
```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?
> 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".
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.
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.
And look at this article’s HN discussion. Many people indignantly defending it. “It’s open source. If you don’t like it deleting your data, don’t use it!”
Maybe we aren’t so rare. I can think of another group that values enduring hardship over progress making things easier for everyone.
That's just how people market things these days, preying on desperation and fear of missing out. It's not how normal humans talk, I hope.
It’s a utility that converts a horribly obsolete binary format from a thoroughly obsolete bit of hardware into text so it can be processed. Working since 1989.
Bare vi does not have windows, visual selection mode, multiple level undo, color schemes, etc.
NVim wants to improve some defaults, which cannot be done if it is beholden to all legacy code. That being said, I still think this specific undo example is insane.
Vanilla Vim added it in 2016 I think, but by that time I had already fully switched to NeoVim and it didn't seem worth it to me to switch.
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
As for default plugins, it'd be neat if they curated a set of optional ones, but nothing should be preinstalled.
I dream of a Vim that wóuld guide and teach me how to use it, so that it does not scare away people because they can’t close it.
I dream of a Vim that embraces the needs of editing contemporary programming languages and fills in its UX gaps correspondingly (changes single to double quotes, anyone? Function argument order?).
I dream of a Vim with native Git gutters.
I dream of a Vim with sane default leader commands.
I dream of a Vim where I see line numbers by default.
I dream of a Vim where “Y” is consistent with other commands.
I dream of a Vim that detects correct indentation by default. And that can visualise whitespace.
I dream of a Vim where Ctrl+V does not have an assigned action that looks like it blocks input.
I dream of a Vim that experiments with keyboard ergonomics, not just mnemonics.
I dream of a Vim where quintuple-tapping Escape is not a habit I subconsciously form why learning it.
I dream of a Vim I stumble on people discovering and exploring, and not have to persuade people for months just to try it.
https://ki-editor.org/
Some people just want to keep looking at the gift horse in the mouth.
I don’t often need the persistent undo. But on the few occasions when I have needed it, it’s been invaluable: ooops, I deleted something from this file, maybe last week and one reboot ago, what was it? Undo until I find it, copy it, paste it into the current version. Or, a bit more commonly: I had this working, then I tidied it up ready to commit, now it isn’t working, what did I do?
It's time to just acknowledge that using modern software engineering practices and nano is far better than being stuck in the 1980s using vim undo as your DR solution.
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.
Seems so. As smart as keeping tabs open in browser instead of using bookmarks, but "workflow".
The feature's name has "persistent" in it.
For example applying the recover file (well it's a huge pitfall in vim on its own) resets not only the current undo history but also the "persistent" one.
https://infosec.exchange/@david_chisnall/117172481079439378
They don't get a pass because you disagree with an imagined use case.
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...
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).
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
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.
=> https://neovim.io/doc/user/options/#'undodir'
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.
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.
I would consider deleting my persistent undo state, which would be something that I would have specifically enabled, to be "severely impacting".
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.
Two programs that save their cache in the same folder causes issues.
https://neovim.io/doc/user/undo/#_5.-undo-persistence
So even putting aside the Vim/Neovim interoperability angle, that contract was broken. Undo files created by old versions of Neovim will be deleted by more recent versions.
The interoperability issue can't be ignored either. Neovim was touted as a drop-in Vim replacement, and that needs to be taken into account when considering how changes affect users.
So many Neovim users have started by reusing their existing vimrc. I'm sure many still have ~/.config/nvim/init.vim symlinked to ~/.vimrc to this very day. With Vim, persistent undo is opt-in. Vim users who cared enough to opt in are highly likely to have explicitly set the path for undo files too. That's because Vim defaults it to the same directory as the file being edited, which clutters the filesystem. As a result, there are many users who shares undo files between Vim and Neovim simply because they reused their vimrc, not because they made the conscious choice to do so.
"A computer shall not harm your work or, through inaction, allow your work to come to harm."
"A computer shall not waste your time or require you to do more work than is strictly necessary."
"An interface is humane if it is responsive to human needs and considerate of human frailties."
Note in particular the third rule. Needing to know in advance that neovim requires a separate undodir to vim because neovim's persistent undo format is unstable, even though vim's is, but the feature is called the same thing and neovim bills itself as a plug and play replacement for vim...
This is not considerate of your user. If you are unwilling to move heaven and earth to preserve user data and carve a path through the weeds, even if it requires a whole other code path just to preserve expected behavior - well, you shouldn't be making end-user software.
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.
You do not have all your states available.
I just tried it in Nextcloud Notes on Android (FlorisBoard has undo/redo buttons), and it seems to work this way. If I type a bunch of words quickly and hit undo, it removes all of them. If I stop for a couple seconds between each word, it undos them one-by-one.