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.
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.
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
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.
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.
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.
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.
> I think Neovim's decisions are justfiable in this context.
Needing to know in advance that neovim requires a specifying a different undodir to vim, because neovim's persistent undo format is unstable even though vim's is stable, but the feature is called the same thing and neovim bills itself as a plug and play replacement for vim...
This is very predictably going to lead to loss of user data.
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.
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 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.
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...
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.
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.
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?
If making a breaking change to the format of the file, why in root's name would neovim not just make its own new file!? Import the vim version if that's desired into persistent-undo.neovim and then just go from there. I don't understand their choice here at all nor why you're acting like this is complicated or there was some need for them to reuse the exact same file as vim?
To support you further, why would neovim users have any illusion there would be cross compatibility between undo files? Separate undo files seems the obvious and expected choice.
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?
Edit: some great examples in the replies here, thanks! Perhaps I should start using it in editors that support it, never gave it a thought before.
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.
The whole point of undo is that you realize you made a mistake later. If you've done that after you've saved your changes and exited the program, you'd have no expectation of undo still working unless you've enabled this feature.
It doesn't matter whether or not you can think of a reason you would want to enable it, but it should be pretty trivial to do so. Once you've enabled it, it should work.
I can give some as well. IDE crashes. Computer reboots at an undesired time. Even if my work is saved, I am not “finished”. I would like my undo history to extend before file / open time.
I often use it to edit system config files, often on embedded devices where I don't have my git credentials setup, or on servers. In these cases we're already not in an ideal world, I don't have good reliable version control or change management in place. In those less-than-ideal worlds, having proper undo history is nice.
> In these cases we're already not in an ideal world, I don't have good reliable version control or change management in place.
Most of the stuff I work on is properly scripted idempotent deploys, with good backups and all that. Or it's a one-off demo, or a prototype. Not having full undo history is never going to actually kill a project, it's just going to make early stage projects and one-offs more inconvenient.
#!/bin/sh
errecho() {
>&2 printf '%s\n' "$@"
}
if [ "$#" != 1 ] || [ -z "$1" ]
then
errecho 'Requires a single filename as the argument'
exit 1
fi
ORIGINAL=$1
if [ "${ORIGINAL#./}" == "$ORIGINAL" ] && [ "${ORIGINAL#/}" == "$ORIGINAL" ]
then
ORIGINAL=./"$ORIGINAL"
fi
# because of course the output of dirname can't be blindly joined with slash and the basename
DIRNAME=$(dirname -- "$ORIGINAL")
if [ "$DIRNAME" = / ]
then
DIRNAME=
fi
FILENAME=$(basename -- "$ORIGINAL")
# because of course extracting the filename's extension is not supported out of the box
case "$FILENAME" in
.*.* )
EXTENSION=.${FILENAME#.*.}
BASENAME=$(printf '%s' "$FILENAME" | cut -c-$((${#FILENAME} - ${#EXTENSION})) )
;;
.* )
EXTENSION=
BASENAME=$FILENAME
;;
*.[^.]* )
BASENAME=${FILENAME%%.*}
EXTENSION=${FILENAME#*.}
;;
* )
BASENAME=${FILENAME%%.*}
EXTENSION=$(printf '%s' "$FILENAME" | cut -c$((${#BASENAME} + 1))- )
;;
esac
if [ "$FILENAME" != "$BASENAME$EXTENSION" ] || [ -z "$BASENAME" ]
then
errecho 'Failed to properly split the extension from the filename:' "$FILENAME"
exit 1
fi
TIMESTAMP=$(date --utc --date=@"$(stat --format %Y "$ORIGINAL")" +'_%Y-%m-%d_%H%M%S')
if [ -z "$TIMESTAMP" ]
then
errecho 'Failed to get the timestamp of the file:' "$ORIGINAL"
exit 1
fi
NEW_FILENAME=$(printf '%s/%s_%s%s' "$DIRNAME" "$BASENAME" "$TIMESTAMP" "$EXTENSION")
if [ "$NEW_FILENAME" = "$ORIGINAL" ]
then
errecho 'Somehow the name for the backup is the same as the original file'
exit 1
fi
# this preserves the timestamps somewhat better
if ! mv --no-clobber --no-copy -- "$ORIGINAL" "$NEW_FILENAME"
then
errecho 'Failed to backup the file: ' "$ORIGINAL" "$NEW_FILENAME"
exit 1
fi
if ! cp -- "$NEW_FILENAME" "$ORIGINAL"
then
errecho 'Failed to backup the file: ' "$ORIGINAL" "$NEW_FILENAME"
mv --no-clobber --no-copy -- "$NEW_FILENAME" "$ORIGINAL"
fi
Actually, nevermind that bullshit, you know what? I think I'd prefer to have an editor with locally persisted edit history instead.
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).
Most apps don't have it, so you might not be used to it, but have you never wished that you could undo the changes you made after you restarted the program?
Moreover, the vim history tracking is amazingly advanced. It's almost like a mini version control system. I highly recommend getting to know it.
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.
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.
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 prompt or uses a pager.
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.
I used neovim because it felt way faster by default. I think treesitter runs circles around what classic vim is using to highlight syntax. That said, I never used both beyond basics, thus no horror stories either.
I haven't noticed any performance issues in vim to start with. It was fast on a 75MHz pentium for me. The syntax highlighting, same. No issues. I don't always use that though because I can't be bothered to set up anything much past the basic config.
At one point vim lacked asynchronous plugins. If a plugin was running a builder or linter it locked the editor up (from what I recall).
That fell apart when people wanted vim to do some more modern IDE kind of things like all the “… on save” stuff (build on save, test, lint, etc). I think LSP support is native in neovim as well.
I believe vim merged asynchronous plugin support a while back though, so I’m not sure how different they really are anymore.
It was a real problem, but as GP already mentioned, Vim has integrated some version of it since Vim 8 (2016), probably at least somewhat motivated by NeoVim (forked 2014).
IIRC vim became really slow with the combination of large source files (thousands of lines of code) and language server plugins (e.g. code completion and live error squiggles).
Tree-sitter is more performant for sure, and its potential for easier text objects is nice. However, Vim's syntax engine is more than good enough for non-complex highlighting (and many people don't want complex highlighting) and, while I don't have enough tree-sitter knowledge to explain this myself, I've seen examples of Lua versions of Vim plugins where tree-sitter is unable to handle some of the regex-based text objects present in the vimscript version.
As far as really cool uses for tree-sitter go, ast-grep is a fantastic tool. Of course it's a standalone program, so it doesn't need nvim to make use of it.
It’s two different dimensions in this case. VCS doesn’t preserve your local history (in JetBrains’ terms) of changes (and it wasn’t meant to by design)
VCS doesn't preserve your local history? Did we miss why git became successful? I mean I understand, you are not committing every 2 lines of code, so git is not replacement for persistent undo, but stil.
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.
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.
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.
Persistent undo is useful, but when it's unavailable or corrupted for me it's like "oh too bad", because it's just a convenience. And then I read things like this I get horrified by the workflows people adapt in order to avoid learning how to use the available tools properly. Seriously, it's just vim, borg and git...
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.
The entire story is a setup for a remark about a Neovim maintainer's refusal to remove a David Heinemeier Hansson quote from the Neovim homepage [0]. So with that in mind the rhetoric makes sense.
[0]: In spite of the author at Unsung saying that Neovim is "in news" for other reasons. Chisnall's account is being given in the immediate context of that news.
So you say the authors accusing neovim of being careless are themselves careless with the readers when they lure us into reading a piece that has second political intentions?
Maybe the author of the actual blog post had different intentions in sharing the Mastodon post than the author of the Mastodon post did. But the Mastodon post was made in response to the event that the blog post attempts to separate itself from. It's a reasonable thing to do if you're more interested in the technical issue and not the political one that the technical issue is being compared to.
But the context of the original post is meant to respond to a (techno-)political issue. This can explain why the post's rhetoric comes across as hyperbolic.
It doesn't help that UX seems to be talked about in ways that borrow the rhetoric of ethics from other disciplines like law and healthcare.
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.
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.
Gotta be honest, this seems like making a mountain out of a molehill. Yeah, DHH is an awful person. His endorsement was removed from the page pretty quickly, but of course not fast enough to avoid the social media mob handing down their verdict upon the thankless maintainers. I sympathize with the Neovim developer in that thread, the driveby Github commenters with seemingly no other involvement in the project are some of the least well-socialized people alive.
The social media mob descended because one of the neovim maintainers was immediately actively hostile and defensive in the github issue, accusing the person who opened the issue to be making "demands" and "threats" (when there were no such demands or threats).
If the first reply on that issue was, "sure, you're right, could you submit a PR to remove it from the website", or even "this isn't important to me but I can see why this might turn people away, let's remove it", then there wouldn't have been any kind of drama.
Actually calling someone a nazi for opposing mass immigration is certainly a choice, but it's not one we should be rewarding with deference. It carried an implicit threat, and the github issue was a form of triangulation intended to force others to take a position on something they're not party to.
I've never liked DHH, but as far as I can tell, he's neither a white supremacist or a nazi. I'm also not the viewpoint police, and I have zero trust or patience for anyone that tries to be.
It's also hard to stay cool and agree with the mob dogpiling you over (tbh) a triviality. Anyone who's had to have difficult conversations in the real world knows that. I'm not going to expect people to respond in the best way to such things (easy to project this expectation when you're an anonymous name in the crowd, though).
There wasn't dogpiling at first. The maintainer was the first person to reply to the initial issue report, and they were dismissive, defensive, and accused the person who opened the issue of bad faith.
All of that was uncalled-for and unnecessary, and then the dogpiling started.
I still don’t understand how quoting something that someone said about Neovim means that you support Nazism, just because said person happened to be a Nazi.
In this case, all evidence points to the lead maintainer sympathizing with DHH's views. If his immediate hostility towards someone politely suggesting the removal of DHH's endorsement didn't make his stance clear enough, here's an archive of his previously public YouTube playlist titled "history," full of talks from far right ideologues like Peter Thiel and Curtis Yarvin.
The relatively small core team has a member giving talks about Neovim at DHH's conference and another one prominently displaying Palantir as their employer in their GitHub profile.
It's clear where their sympathies lie, and that GitHub issue wasn't a one-off coming from a stressful online interaction.
I'm not gonna gather 'evidence' for or against what some guy who happens to maintain a text editor I use thinks about the issues of the day. It's just creepy behavior, and a huge violation of personal boundaries. Why do you think this is an acceptable thing to do? Go outside.
Regardless, the material you've posted doesn't indicate much about him to me beyond that we have political differences, which is okay. That's literally fine. It's definitely not enough to condemn someone as a Nazi sympathizer.
Before telling someone to "go outside," it's a good idea to make sure that you haven't written an entire paragraph filled with personal attacks using fresh throwaway accounts.
The things I listed are very public, each of which has raised very public concern. I didn't have to "collect" anything because the Neovim team already had a reputation for such things.
You may think the issues being raised are just "political differences." Enough people clearly see it differently. For many, the things DHH, Yarvin, and Thiel stand for crosses many lines. White supremacy, mass surveillance, or the destruction of democratic institutions aren't "fine." There's nothing more "creepier" than the ethnic targeting of people that Palantir enables.
Sorry, no, stalking people online is downright off-putting to anyone from the real world. Having non-political endorsements from people you (and, if you believe it, I) deeply dislike doesn't warrant this kind of treatment. You've simply worked yourself into a froth to justify doing it to someone you really don't know. What right have you to be 'concerned' about the Youtube videos someone watches in their private life? This is normal only to the social-media-mob-socialized.
This sort of runaway justification is a very common pattern from the self-righteous, across the political spectrum. It's why I need to use a throwaway to talk about these issues, even with people I ultimately agree with. Consider carefully how few hearts you've changed with this strategy.
So, yeah, I reiterate: go outside! Smell the roses! I'll follow my own advice, at this point.
What's off-putting is publishing a white suprematist course compilation on social media. Calling backlash against that "stalking" is utterly bizarre and detached from any actual meaning of the word.
Way back in junior high school our teacher showed us Adolf Hitler's speeches. Do you think she was actually a secret nazi preying on impressionable youths?
In my view the core of the "drama" is about whether quoting an unpolitical statement of a person endorses the person as a whole, including their political views.
The maintainer who originally responded to the github issue clearly thinks that it does not. The reporter and Twitter mob think that it does
Whether we disagree with his political views (I hope so) and how political a project like neovim is would be questions to answer once agreement on the first question is reached
When you put an endorsement quote on your project page, you're addressing it to a large range of unrelated people who majoritarly won't even be users of your project (yet).
It's basically advertisement, we won't ever reach some universal conclusion on what any specific aspect of it means for your project, it's all in the eye of the beholder.
It's also all social norms, the maintainer doesn't get a choice on how it will be taken.
Would you put up a quite from Hitler on your website endorsing your product, even if the quote wasn't about his views about anyone who is not a part of his "master race"? How about Pol Pot? Maybe Stalin?
If the answer is "yes", I think maybe you're a little out of touch with how people tend to view stuff like that.
Sure, DHH is not literally any of those people, but he certainly seems to really like Hitler. I just don't get why someone would want a quote on their website from someone who thinks minorities are pests to be exterminated, regardless of the content of their quote. Like, seriously, this is the hill you want to die on?
It doesn’t matter what his political views are, as they’re totally unrelated to what he said about Neovim. Quoting what he said about Neovim does not in any way indicate support of his political views.
Vim undofile "data loss" happens because Vim (VIM!) will reset the undofile will reset the undofile if an external tool (git, nano) changed the file while Vim is not running.
Go ahead, try it:
# Make some edits, then exit vim (remember to exit).
vim --clean +'set undofile' foo.txt
# Edit the same file with non-vim; save the changes.
nano foo.txt
# Open the file again and try "u". Then post on bluesky about Vim's "duty of care".
vim --clean +'set undofile' foo.txt
Spot on. It genuinely surprises me how many people don't realize that vim's persistent undo feature resets if the file is modified by anything outside of vim itself.
For example, a common scenario is rolling back a file via git, which triggers this reset. However, considering they treated it as a reliable version control system without actually reading the documentation, they probably aren't using git anyway.
The good news for them, however, is that they actually can bypass this limitation and treat their undo history like version control—by using nvim-fundo [1]. The catch is that they'll have to switch to nvim, as there isn't a direct equivalent for vim.
And vim will also reset it while "recover"ing the last unsaved changes. I believe no user relies on it to actually persist the history of a file. If someone is doing that whether in nvim or vim I'd seriously advise you to use a real VCS repo instead.
> 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.
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. 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.
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.
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.
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.
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.
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.
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".
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.
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.
Unless something changed very recently neither vim nor neovim defaults to storing persistent undo files in ~/.cache. It's application state, not cached data.
The undodir option in vim defaults to the directory of the file, and in neovim it defaults to ~/.local/state/nvim/undo/.
What did OP misunderstand? I am not sure how and where their understanding of "persistent undo" is different from "persistent across process restarts"?
Nobody should have to read release notes to avoid data loss; there should never be a change such that someone who hasn't read the release notes (or missed a detail in reading them) to avoid such a problem.
You're holding others to a standard that you yourself haven't adhered to. Please go read the release notes. No mention anywhere that old undo data will be deleted.
Also, what's up with people claiming that the undo files are stored under ~/.cache? That's completely made up. Or that persistent undo doesn't persist edit history, against what the docs say. Utter nonsense.
The lifetime of files in ~/.cache/ is the same as what the FHS documents for /var/cache [0]:
> Application cache data. Such data are locally generated as a result of time-consuming I/O or calculation. The application must be able to regenerate or restore the data. The cached files can be deleted without loss of data.
Meaning: the persistence of such files is not guaranteed across application restarts. If vim (and also neovim) had intended for the undo files to outlive the program, the files should have been put in ~/.local/state instead -- as also explicitly documented by the XDG [1]:
> [XDG_STATE_HOME] may contain: [..] current state of the application that can be reused on a restart (view, layout, open files, undo history, …)
That doesn't work here because the data was not wiped by a generic cache flush from a third party script or whatever, but a targeted hit from the application itself on files known to be persistent undo.
You just can't point the finger at file system standards, or shoulda-read-release notes or whatever.
There is no such thing as "by mistake, we historically stored persistent files in a directory with 'cache' in its name, contrary to a popular standard, so that makes it okay to trash them now".
> That doesn't work here because the data was not wiped by a generic cache flush from a third party script or whatever
But it was, it was program other than vim (neovim) that did it. It deleted a file in a space that is meant for transient files that may be deleted at any time for any given reason and should not cause data loss, and yet it did because vim, in the first place, broke the file system’s contract.
Neovim shouldn’t have been messing there but at the same time there’s a much bigger culprit here in that vim shouldn’t have been storing this kind of data there in the first place. It was a broken system that broke even further. Simple as that.
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.)
As a vim user, I feel neovim was useful for one thing: it shaked regular vim development a bit. That said, I see no reason to switch. Good old vim is rock solid and featureful. I hope it doesn't die due to neovim's competition.
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.
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.
It's worth pointing out that vim is not "another program" as far as Neovim is concerned. It's an earlier version of the same program. Neovim is a fork of vim, not a totally different editor that happens to share part of a name.
It absolutely is another program, I can tell this because it has a different name. To run it I type "nvim" instead of "vim". I use different config files to control its behavior. I install a different package on my system when I want to use it on a new computer.
This gift comes with the following clauses listed plainly in the license file:
7. Disclaimer of Warranty. Unless required by applicable law or
agreed to in writing, Licensor provides the Work (and each
Contributor provides its Contributions) on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied, including, without limitation, any warranties or conditions
of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
PARTICULAR PURPOSE. You are solely responsible for determining the
appropriateness of using or redistributing the Work and assume any
risks associated with Your exercise of permissions under this License.
8. Limitation of Liability. In no event and under no legal theory,
whether in tort (including negligence), contract, or otherwise,
unless required by applicable law (such as deliberate and grossly
negligent acts) or agreed to in writing, shall any Contributor be
liable to You for damages, including any direct, indirect, special,
incidental, or consequential damages of any character arising as a
result of this License or out of the use or inability to use the
Work (including but not limited to damages for loss of goodwill,
work stoppage, computer failure or malfunction, or any and all
other commercial damages or losses), even if such Contributor
has been advised of the possibility of such damages.
It's genuinely mind-blowing to me that software can do something obviously bad, someone can point it out, and then someone will link to the license file to say they have the right to do it.
That's such an obvious category mistake that I'm not sure how to respond. It almost feels like a bad-faith interpretation of Wichary's original point.
Right. It is weird that this has to be explained, but let's make it clear: in the Before Times, probably anytime up to at least the late '00s, probably approximately no-one in or around free or open source software would have endorsed the idea that the legal disclaimers completely free even the most mainstream, self-publicising, broad-userbase open source projects from any moral or ethical obligation to have even the slightest concern to ensure that their software doesn't hurt or betray its non-paying users, even in the most harmful ways. And if one of the many and often vocal FOSS opponents of the time had started claiming that this is what open-source developers really believe they'd have rightly been seen as having veered off into the lunatic fringe. And that's because it's a, frankly, bonkers idea which is radically detached from normal human understanding of the social and moral role and obligations of volunteers, voluntary organisations, charitable givers or gift-givers. And also because it's a wildly counterproductive idea to put out there if you're hoping to increase FOSS adoption.
That does leave the question of why this idea has started to take off more recently. Part of the answer is certainly that Rich Hickey, disgracefully, set the ball rolling in this direction, and that many others have welcomed it as one weird trick and one pat answer for all the worsening problems of developer burnout. Unfortunately it seems hard to dismiss the idea that it's also social breakdown driven by a broader trend, as over time we move further and further from the pre-'60s "neurotic society" of people obsessed with duty and social conformity (often with oppressive or destructive results, to be sure) into the "psychopathic society" in which even people who don't themselves merit a Cluster B diagnosis have internalised narcissistic and psychopathic attitudes.
Equally mindblowing that folks feel someone hacking on open source software has an obligation to do anything the way they feel it needs to be done when the whole point is that anyone gets to do more or less what they want with the code.
They get to do more or less what they want with the software, and others get to say more or less what they want about that. What's wrong with deciding they've crossed a line, being bothered by that, and warning others? Nobody's trying to get the law involved, or maliciously retaliate against them, or anything like that.
I think you are objecting to OP’s “duty of care” wording which could be interpreted as suggesting a legal obligation. Nobody in this thread is really arguing that open source developers have a legal obligation to do this and to not do that. We are just saying they should do this and should not do that.
"Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE."
Unclear? The fact that it's part of a license does not make it a legal-system-only warning.
The software might eat your dog, and feed your homework. Run it at your own risk, and be prepared to submit patches or fork it to make it behave the way one prefers.
This is one of the most exhausting (and frankly, exhausted) recurring arguments that comes up over and over again on HN.
Some bit of open source software does something bad or unwanted which causes people point out that it shouldn't do that bad thing. In this case, not even "the authors of this software should be held liable for the software doing the bad thing", just, "Hey, the right thing to do would be to update the software to not do the bad thing."
Why does this always lead a zillion people to come out of the woodwork to point at licenses and warnings or whatever? Like, yes, there's a warning. Your software having a warning doesn't mean people can't criticize you and your software for doing bad thing. Your software license does not give you immunity from criticism or from people saying you should change your software.
No, you don't have to change the software. Yes, other people are within their rights to fork the software themselves. But they can also point out that they told you that your software was doing the bad thing and you didn't fix it or change it, and that as a result they don't like you or your software or both — whatever. Nothing at all wrong with that.
I actually think you framed it really well. No parties involved have any particular obligations to each other. Nor should there be expectations otherwise without support. It sucks to lose data, everyone knows that, and no one wants it. And identifying things which can be improved is important. I stop at expecting someone else to do something because I want them to. I might hope they would, and try to convince them.
The software might eat your dog, and feed your homework
Sure, and when it does we can say “this piece of shit ate my dog, and the authors of the software have no concept of a duty of care to their users”. And no amount of “well, axually…” is going to make any difference. I have a hard believing someone is copy-pasting a license file in good faith in response.
Most open source software is written by individuals who aren't paid for the effort, and are solving their own problems. Presuming that they feel an obligation to the folks who download and use their work for free seems... bold.
If my neighbor mows my lawn for free, I'm not going to complain about his workmanship. If I want the job done a particular way, the solution is to do it myself, or pay someone to do it the way I like.
> If my neighbor mows my lawn for free, I'm not going to complain about his workmanship. If I want the job done a particular way, the solution is to do it myself, or pay someone to do it the way I like.
I think this is a decent analogy, but it works better the other way. If my neighbour offers to mow my lawn, I accept, and then he destroys the flower bed adjacent to the lawn, I will be upset, and I will have every right to complain about what he did. If he reacts by blithely dismissing my concern, then I certainly have the right (and arguably the obligation) to warn others that they should think twice about accepting his offers of gardening assistance.
Some expectations reasonably go without saying; "don't destroy my flower bed when mowing my lawn" is one, and IMO "don't destroy my data without a clear warning and a chance to back out" is another, though of course we might disagree about exactly where this does and doesn't apply.
Suppose that you build a childrens' slide in your front garden. You put up a big sign saying "Consider using my slide! https://neovim.io/ Here are several wonderful things about it. It's free for everyone!" in your yard. Underneath in smaller letters you add "[No liability]". You also put up noticeboard ads for your free kids' slide in neighbourhood shopping malls https://launchpad.net/ubuntu/+source/neovimhttps://wiki.archlinux.org/title/Neovim . Unfortunately, when you built the slide, you left sharp metal edges and corners sticking far up on the inside, reaching into the path of the user. No reasonably competent and diligent metalworker or slide-maker would have failed to notice these major flaws or failed to understand the serious danger they represented. Several neighbourhood children use the slide and receive serious gashes to the legs, arms or face, and have to go to the hospital. Even assuming that your no-liability small print somehow had you free and clear legally, do you believe that your behaviour would have been ethically and morally above all criticism? Do you think that "should have read the small print!" or "can't I build what I like in my own front yard?!" would have you covered? Do you think that your family and friends would agree?
If my neighbor mows my lawn and ruins my whole garden, I'd definitely complain. (And if I were in the neighbor's shoes, I'd feel awful about it and try to fix things.)
If my neighbor mows my lawn for free, and in the process mows my flower garden down, things change a bit though don't they. That is a closer analogy. In that case I am going to complain, and maybe also tell everybody he's careless and not to let him near their lawns.
There's a long literary tradition of representing contracts as a tool of villainy. Signing them is generally treated as a Faustian bargain.
This is a great example of why. Most humans have a sense, deep down, that contracts often exist to bridge the gulf between the ethically defensible and the legally defensible.
It's hard to imagine that any sane person who is just looking to use a popular editor would read some broad limitation of liability language like the above, and interpret it to mean, "By the way, we intend to quietly delete certain files created by a competing fork of this project whenever we find them."
It's true that contracts with liability limitation clauses like this are an absolute necessity in this day and age. But there's also a non-legal principle of mutual respect that is absolutely necessary to a healthy open source community.
> It's hard to imagine that any sane person who is just looking to use a popular editor would read some broad limitation of liability language like the above, and interpret it to mean, "By the way, we intend to quietly delete certain files created by a competing fork of this project whenever we find them."
Forks of projects trodding all over each others files is one of the more common problems that has happened, historically. Prior to the major efforts around freedesktop.org around configuration standardization, it was quite common. It'd be one of the first things I looked for when switching to a fork.
I’m not saying it doesn’t happen. I’m saying it shouldn’t be defended as good. It’s a defect. And in this particular incarnation it’s a defect that directly clashes with fundamental Free Software principles such as personal digital sovereignty.
I also suspect that few people actually believe it’s ok and these legalistic defenses are more about circling the wagons. How many people would defend Microsoft if a new Office version automatically and quietly stripped edit history from documents that were originally created by other versions? Would we be hunting for limited liability clauses in their EULA to defend the design decision?
> I also suspect that few people actually believe it’s ok and these legalistic defenses are more about circling the wagons.
For me it's more about healthy boundaries and expectations. If I'm somehow paying for a project's development, I have higher expectations. If I'm not, I understand that I've chosen the dev/test track and there will be bugs and issues. The developer may choose to run off in an odd direction coughGnome3cough and my only recourse is to fork or hope someone else does. Disagreements as to how things should work happen pretty often.
I'm not defending anything or anyone. Just describing the system as it exists.
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."
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.
Others are eating it and are fine, chances are you’re allergic. Fortunately all ingredients are listed, you can check - or even modify the recipe yourself.
The point would be that it's open source. And "chances are you're allergic" translates to "your use case / expectations are unusual". But in my opinion the analogy doesn't hold well at all, because destroying a persistent undo file without warning is pretty obviously incorrect and unexpected behavior.
According to TFA, it was completely intentional that they deleted someone’s data that had been created with a different program. Otherwise they would have acknowledged it was a bug. I do not know if this is true, only that it is what TFA claims.
It’s not great that Neovim destroyed/replaced files that aren’t clearly under its purview. They should have probably also made the consideration that a lot of Neovim users are going to be migrating from Vim.
Maybe if they’re making their own persistent undo standard, use different file naming conventions.
That said, as a fork of Vim, maybe the Neovim authors are at least partially reasonable in assuming that you’re not running multiple forks of Vim that could then potentially conflict with each other. It just sucks that they never really thought of a migration path for this particular feature.
Yes, everyone is aware of that. The parent poster was bringing up the example of food to demonstrate that our society does not agree that giving something away for free doesn't mean you have no obligation as to potential adverse effects of the thing.
Analogies like this don’t work when comparing against heavily regulated industry.
Neovim being free software is a lot different than United Airlines giving me a free flight or my doctor giving me a free consultation.
It’s very true that you can go to civil court and make a claim that a business or individual harmed you. If you do that with Neovim the judge is going to pretty quickly read bullet point #7 of the Apache 2.0 license, you’re going to struggle to prove any kind of mal-intent, you’re going to tell the judge that you paid $0 for the software, and you’ll be pretty quickly sent along your way with no damages awarded.
Only in the sense there's no explicit legal responsibility.
Do you really believe developers have exactly zero moral responsibility to their users? None at all?
Really?
Would you still believe that if you found the developers of ssh deliberately included a backdoor for hackers, or neovim was uploading everyone's code to the NSA?
That is why software should have very large liability for anything software they release do? Say your software due to bug destroys some document. Surely you should pay damages caused by such bug even if quite high?
"Your analogy is false because the two things you are comparing are not literally the same, dear sir!" is such a classic Internet discussion trope that it must have a name. If it doesn't, can I please name it? Maybe Perfect Analogy Fallacy?
But they couldn’t be further from different. You have to have a health inspector visit your kitchen just to sell food at all. You need affirmative permission from the government to sell food.
> If I give away food I have a duty not to poison you. It doesn’t matter you didn’t pay for it.
If I invite you to eat at my house, there is no health inspector and no government. I'm just giving you free food. Would you agree that I have a duty not to poison you in that case?
If we aren’t making the business analogy though, then Neovim has even less obligation to produce a professional quality product. When you come to my cookout the expectations are different than when you go to a restaurant.
What do you mean by "obligation"? Nobody is claiming they have some kind of legal obligation. Nobody is saying anything analogous to your "health department" analogy. I think you're arguing against something people by and large are not claiming.
Okay, apologies in advance for how ridiculous this is getting and a lot of that is my fault, but I do want you to understand what I mean.
At the top of this discussion parent to where I said “software is not food”
> If I give away food I have a duty not to poison you. It doesn’t matter you didn’t pay for it.
First, I’ll start with the loaded language here: “duty not to poison you.” Yes, duh, no matter what, intentional poisoning is a crime. But the phrase is “not to poison you” which I interpreted to mean that we are taking about harm mitigation/prevention rather than intentional crime.
In that context it very much does matter if the relationship is giving away food for free in a private home versus selling or giving away food in public.
If we are to consider Neovim to line up with the “giving away food for free at my backyard cookout” analogy, they have a more relaxed standard of care. We don’t go to a BBQ and expect the hosts to have training from the department of health and signs that say “employees must wash hands before returning to work.” In this sense, Neovim would say, “hey, we did our best, we tried to make good software but this condition caused it to fuck up your files. Sorry.”
If we are considering Neovim to line up with “McDonald’s giving away free hamburgers for national hamburger day,” then now we have to recognize that the software industry does not involve nearly as much regulation as McDonald’s. Neovim’s story doesn’t change: “hey, sorry, we did our best, …” but McDonald’s doesn’t have that same standard of operation. Whether or not the hamburgers are free they have to get all the same licenses, do all the same training, and make their employees keep all the meats to temperature and all of that.
There’s no regulation around the general quality of software. You don’t have a strong claim to damages if your software crashes or causes problems. The remediation for problems like that is accomplished via SLAs in the business world, which obviously nobody has with Neovim. They’re just providing software as-is with no warranty or guarantee of quality or fit for purpose (#7 in the license agreement) and they’ve even been nice enough to provide the code ahead of time so you can audit it.
So unless someone at Neovim is in an evil lair declaring that they want to delete stuff on purpose to fuck up your day, there’s really not much of a logical case for their negligence here. It was provided at no cost, there are no significant legal regulations on software quality, they offered the code so you can inspect it, and they warned you in the license that it is provided with no guarantees or promises.
This concept of “duty of care” doesn’t exist in the software world, as much as we might prefer it to really exist.
The guy you're arguing with made the mistake of switching to metaphors. The result is several back and forth posts, and neither mutual understanding nor useful discussion.
To avoid metaphors: There's an implicit assumption that when you install a piece of software, it will not fuck up your data/system without your consent. No, installing it is not consent, neither is using it. Neovim does exactly that. No amount of food analogies or license quotes will change that fact.
Neovim authors should've just used a separate file, just like they're happy to use separate format and files for the configuration. Instead, they've decided to be dickheads, and interfere with vim's file, even after the issue being pointed out to them.
My guess is that as a fork of Vim they’re intending to replace Vim and therefore see no reason to try and coexist with it. They would probably say something like “why are you trying to use Neovim and vim at the same time?”
Whether or not that’s a good design is definitely discussion-worthy.
I’m not sure I agree about the concept that programs promise not to fuck up your data without your consent. Programs can’t really know what you are consenting to. The authors can’t assume you’ve read the manual or understand what the program was designed to do.
I think there’s a decent argument to be made that persistent undo files are more akin to metadata, similar to Microsoft Word recovery files or search indexes, but I haven’t made that argument because the author’s frustration on the issue seems logical and valid. It seems like it’s still not meant to be a data storage or backup mechanism: you wouldn’t share it in an email or check it into source control.
> and therefore see no reason to try and coexist with it
This is my main point of disagreement. This is not their decision to make.
> The authors can’t assume you’ve read the manual or understand what the program was designed to do
I think this is correct, but, the principle of least surprise should be paramount here. If the program states something like "migrate all vim-related files to neovim(This will lose all metadata when opened by vim)? y/[N]", I'd concede that neovim wiping data if the user chose Y as acceptable. Yet, they neither display the prompt, nor keep existing data.
Sure, and then have it break again the next time upstream pushes a change. Or have something else break because upstream doesn't care about breaking things that I'm relying on.
The only way to "fix" this from a source code perspective would be to fork Neovim.
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.
> They are open source developers, giving away free software as a gift. There is no duty here.
But actually there is! They didn't start from scratch. They took another very successfull and beloved project with the promise "to make it better". There is some promise here and the duty not to make it worse.
"Better" is subjective. They made it better...for themselves. Then gave it away so people who share their opinion, had the opportunity to choose to use it.
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.
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 constitutes a professional.
And for what it's worth, I have flagged your comment for the inevitable pointless bickering it has precipitated. While applying reductionist frameworks and seeing where they lead is a necessary part of an individual's path to understanding, please avoid pushing ignorant assertions ("there is no duty here") as if they might constitute well reasoned truths.
Sure. And nobody has a duty to use it.
This user states that (s)he doesn't want to use an editor that doesn't care for its users. I don't blame anyone here.
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.
To be fair some malware has a better support and care experience than some open source software. The malware actively encourages you to contact them to pay the ransom. The open source software, no such luck.
I already build software where I hold myself to a higher standard than malware, so not sure I get your point. Why not strive for a better world with good software?
Your suggestion that it is malware is misleading. Malware is “any software intentionally designed to harm, disrupt, or steal data from computers”. I sincerely doubt that was the author’s intention.
Everyone in open source is trying to write good software and the definition of good is subjective depending on overall design, features, ease of use, quality, and performance.
If an open source project is missing a feature, go build it. If the project maintainers don’t want it, fork the project. Be the change you want to see in the world. That’s the beauty of open source.
> If an open source project is missing a feature, go build it.
> Be the change you want to see in the world.
The feature being: don't delete my data belonging by another program? It's kind of too late once deleted isn't it? And now even that other program cannot use the data either.
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.
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.
Vim does things at least as bad. Here’s something I wrote in 2020 that shows how the default Vim configuration can overwrite files created outside of Vim and cause autobuild systems to fail: https://lee-phillips.org/badvim/
And why my .vimrc starts with this:
set nobackup
set nowritebackup
set noundofile
set noswapfile
Neovim is advertised as being a plug in replacement for vim, which is 100% not true. Many things are different, including undo files and :!. I can't remember the feature that made me give up, but at some point the switch became more work than it was worth, considering my vim setup already works. I'm not sure what I would do if I were starting out today.
"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.
> 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.
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.
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.
More like in the LLM era, people are disrespecting the user and not sweating these details with ever increasing velocity. It isn't good.
This story is about software being a slow, deliberate process where a lack of gatekeeping can lead to data loss. This is the type of problem which is getting worse.
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.
We also live in a very different world now compared to 2021 when the problem was reported. A brief Gemini query to translate the old diff format to the new one returned in a few seconds with what appears to me a correct, < 40-line, solution.
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.
The simpler and less contentious way to adopt innovations is to make a new tool with the innovation. For example, you might like https://helix-editor.com/
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. I did feel discouraged to learn it at first because the people introducing it to me were doing pointlessly fancy things in it, some combination of custom keybinds and scripts to mass edit files.
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.
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.
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
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.
Talk about poor duty of care to users... been using him for 20 years and I have to enable it in my vimrc to take effect. So stupid. Why would I want this to be off?
It’s somewhat important for privacy reasons that the feature is opt-in. I don’t know if that’s the reason historically, but I wouldn’t want a text editor to persistently store a copy of everything I type without my consent. It’s almost like a keylogger.
Making privacy-sensitive features opt-in is a form of duty of care as well, to avert harm from the user.
I prefer persistent undo being off. I like being able to hold down u and revert to exactly how the file was before I opened it. (Maybe there's a better way to do this?) With persistent undo on, it just keeps going and going. And if I need long term source control, that's what git is for. With persistent undo off, it's like opening the file creates a checkpoint that I can get back to easily.
They have very vocal and entrenched users so that practically no defaults can be changed lest the single Amiga user will start a huge uproar.
And since they don't really have a BDFL or commercial pressure, they can be super detached even from standards or expectations that appeared 40 years ago.
Neovim was basically a reaction to that, for Vim, where they updated defaults to stuff basically every Unix editor since 2005 has.
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.
Disturbing to see justifications for this program behaviour. The only time a program I write explicitly deletes persistent user data is if the user is interacting with a modal that very, very clearly warns them they are taking an intentional action to delete data. Migrations always backup the files being operated on before performing any migration actions. This is surely common sense. It is clear that many of you have absolutely zero regard for anyone who uses your software. Which is, I suppose, not surprising given how much software is absolute unusable dogshit.
> 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.
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.
Put another way, why did the author “test in production” on their important work when evaluating a new piece of software they were unfamiliar with?
Vim is a very popular piece of software to the point where there are dozens or perhaps hundreds of forks made by all kinds of people. Many if not most of these forks are probably not very good.
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.
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.
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...
All the ones where you can build open source (excluding the ones where you elected governments that send police to your house for Facebook posts or where governments welcome “asylum seekers” that try to blow up your military bases and never “connect the dots”)
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.
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.
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."
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.
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
That's some weird technicality that has nothing to do with the issue while also being completely false.
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.
NeoVim docs say it defaults to "$XDG_STATE_HOME/nvim/undo//". Do you have a source for ~/.cache?
=> https://neovim.io/doc/user/options/#'undodir'
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.
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".
it's not the default place, it's where the user decided to put it.
So if a program decided it owned .cache and deleted it every startup you’d be fine with it?
Honestly, kinda? It'd be rude and cause a performance regression, but it shouldn't break anything.
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.
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.
Hadn’t tried previously, but will say that LLMs definitely helped me.
> I think Neovim's decisions are justfiable in this context.
Needing to know in advance that neovim requires a specifying a different undodir to vim, because neovim's persistent undo format is unstable even though vim's is stable, but the feature is called the same thing and neovim bills itself as a plug and play replacement for vim...
This is very predictably going to lead to loss of user data.
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.
I have a far less sensationalist headline for this which is:
Two programs that save their cache in the same folder causes issues.
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.
"Program that claims to be a drop-in replacement will arbitrarily delete data in ways that the program it replaces doesn't"
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.
Why not give it a different name, so that it would not break vim?
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?
maybe they tried to undo the change, but were not able to
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.
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...
It’s such an odd design decision.
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.
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.
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.
If not, I wonder how Google justifies it.
Google is the epitome of design that doesn't care at all about the user and user experience.
If Google does something in X way, you can almost always be certain that X way is the wrong way to do that.
Google is abysmal. In every sense of the word and in every product they touch.
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?
If making a breaking change to the format of the file, why in root's name would neovim not just make its own new file!? Import the vim version if that's desired into persistent-undo.neovim and then just go from there. I don't understand their choice here at all nor why you're acting like this is complicated or there was some need for them to reuse the exact same file as vim?
To support you further, why would neovim users have any illusion there would be cross compatibility between undo files? Separate undo files seems the obvious and expected choice.
[dead]
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?
Edit: some great examples in the replies here, thanks! Perhaps I should start using it in editors that support it, never gave it a thought before.
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.
The whole point of undo is that you realize you made a mistake later. If you've done that after you've saved your changes and exited the program, you'd have no expectation of undo still working unless you've enabled this feature.
It doesn't matter whether or not you can think of a reason you would want to enable it, but it should be pretty trivial to do so. Once you've enabled it, it should work.
The article gave 2 examples.
I can give some as well. IDE crashes. Computer reboots at an undesired time. Even if my work is saved, I am not “finished”. I would like my undo history to extend before file / open time.
I often use it to edit system config files, often on embedded devices where I don't have my git credentials setup, or on servers. In these cases we're already not in an ideal world, I don't have good reliable version control or change management in place. In those less-than-ideal worlds, having proper undo history is nice.
First, you need backups
Second (for servers), etckeeper
I mean I already responded to the comment
> In these cases we're already not in an ideal world, I don't have good reliable version control or change management in place.
Most of the stuff I work on is properly scripted idempotent deploys, with good backups and all that. Or it's a one-off demo, or a prototype. Not having full undo history is never going to actually kill a project, it's just going to make early stage projects and one-offs more inconvenient.
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).
Most apps don't have it, so you might not be used to it, but have you never wished that you could undo the changes you made after you restarted the program?
Moreover, the vim history tracking is amazingly advanced. It's almost like a mini version control system. I highly recommend getting to know it.
If your session / computer crashes, for one.
Another one:
`:earlier 1d`.
persistant undo is like a second brain to consolidate.
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've used vi and nvi and (now) vim, and tried neovim, but :! is broken and “Conform to POSIX vi” is one of their “Non-goals”.
POSIX vi is so barebones that nobody* wants that.
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.
Nvi2 it's almost POSIX vi+iconv, thus, Unicode support. Good enough for me.
Nvim's `:!` behaviour was a deliberate design decision, which is one of the reasons I just stick with Vim9.
What's the issue? I use nvim and regularly use :! and haven't noticed an issue.
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 prompt or uses a pager.
It doesn't support interactive commands. For example if you run a command that asks for input before finishing, it gets swallowed.
I've never used NeoVim because Vim has been good enough.
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.
I would probably do the same if I had an issue with Vim back then. Guess I just didn't have that many plugins.
*vimdicated
I used neovim because it felt way faster by default. I think treesitter runs circles around what classic vim is using to highlight syntax. That said, I never used both beyond basics, thus no horror stories either.
I haven't noticed any performance issues in vim to start with. It was fast on a 75MHz pentium for me. The syntax highlighting, same. No issues. I don't always use that though because I can't be bothered to set up anything much past the basic config.
At one point vim lacked asynchronous plugins. If a plugin was running a builder or linter it locked the editor up (from what I recall).
That fell apart when people wanted vim to do some more modern IDE kind of things like all the “… on save” stuff (build on save, test, lint, etc). I think LSP support is native in neovim as well.
I believe vim merged asynchronous plugin support a while back though, so I’m not sure how different they really are anymore.
That seems like solving the wrong problem.
Just run make from another terminal...
It was a real problem, but as GP already mentioned, Vim has integrated some version of it since Vim 8 (2016), probably at least somewhat motivated by NeoVim (forked 2014).
https://lwn.net/Articles/713114/
I hadn't noticed.
IIRC vim became really slow with the combination of large source files (thousands of lines of code) and language server plugins (e.g. code completion and live error squiggles).
I had a C program that was a single file 140,000 lines long back then. No issues.
Vanilla vim sure, no problem. But try to add syntax highlighting and code completion plugins.
Ah yes, the "I've never had this problem so obviously no one else could have possibly had it" argument.
No it's more the "what the hell are people doing to make their lives difficult?" argument.
To be fair, they were just sharing their experience. I don’t recall them saying anything close to your interpretation.
I was using vim-enhanced as red hat-based distro installed it. No customization. No customization of nvim either.
I often use vim or nvim on disposable machines, so persistent undo is something very low on my list of things I want.
Tree-sitter is more performant for sure, and its potential for easier text objects is nice. However, Vim's syntax engine is more than good enough for non-complex highlighting (and many people don't want complex highlighting) and, while I don't have enough tree-sitter knowledge to explain this myself, I've seen examples of Lua versions of Vim plugins where tree-sitter is unable to handle some of the regex-based text objects present in the vimscript version.
As far as really cool uses for tree-sitter go, ast-grep is a fantastic tool. Of course it's a standalone program, so it doesn't need nvim to make use of it.
[dead]
If one really needs an undo in today's day and age, use git.
It’s two different dimensions in this case. VCS doesn’t preserve your local history (in JetBrains’ terms) of changes (and it wasn’t meant to by design)
VCS doesn't preserve your local history? Did we miss why git became successful? I mean I understand, you are not committing every 2 lines of code, so git is not replacement for persistent undo, but stil.
I don't use git. I actually have something still using RCS.
Ok, I’ve gotta hear this. For what? I haven’t touched rcs since we upgraded to cvs. Is it still unusually good at something today?
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.
In other words, a real curiosity – the stuff held in the highest esteem here on HN (according to the guidelines).
Someone didn't read the part about wanting a humane interface
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.
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.
Persistent undo is useful, but when it's unavailable or corrupted for me it's like "oh too bad", because it's just a convenience. And then I read things like this I get horrified by the workflows people adapt in order to avoid learning how to use the available tools properly. Seriously, it's just vim, borg and git...
> I'm surprised to hear that people rely on it being persistent.
The feature's name has "persistent" in it.
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.
they use "autoread" to work around that (but it requires vim to be running and the given file open if I understand correctly)
https://infosec.exchange/@david_chisnall/117172481079439378
it doesn't have "durable" though :)
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.
Yeah, they could have done better, but to say they "had no concept of a duty of care to their users"... Isn't it a bit much?
The entire story is a setup for a remark about a Neovim maintainer's refusal to remove a David Heinemeier Hansson quote from the Neovim homepage [0]. So with that in mind the rhetoric makes sense.
[0]: In spite of the author at Unsung saying that Neovim is "in news" for other reasons. Chisnall's account is being given in the immediate context of that news.
So you say the authors accusing neovim of being careless are themselves careless with the readers when they lure us into reading a piece that has second political intentions?
Good question...
Maybe the author of the actual blog post had different intentions in sharing the Mastodon post than the author of the Mastodon post did. But the Mastodon post was made in response to the event that the blog post attempts to separate itself from. It's a reasonable thing to do if you're more interested in the technical issue and not the political one that the technical issue is being compared to.
But the context of the original post is meant to respond to a (techno-)political issue. This can explain why the post's rhetoric comes across as hyperbolic.
It doesn't help that UX seems to be talked about in ways that borrow the rhetoric of ethics from other disciplines like law and healthcare.
the quote was removed in ~2 days.
https://github.com/neovim/neovim.github.io/pull/504 of course with sweet sweet drama!
https://infosec.exchange/@david_chisnall/117172601365228235
https://xkcd.com/1172/
Seems so. As smart as keeping tabs open in browser instead of using bookmarks, but "workflow".
Btw zen browser's folders are many streets ahead of Firefox's traditional bookmarking.
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.
Keep in mind NeoVim forked in 2014, too.
Type A. Type B. Save. Type C. Save. How do you get back to state “A” using git?
You do not have all your states available.
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.
Is 16+ not almost 20?
I was also a very early user of Neovim.
The way I personally remember it being positioned was “Vim, but with breaking changes.”
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.
The “drama” was linked in TFA:
https://github.com/neovim/neovim.github.io/issues/501
Gotta be honest, this seems like making a mountain out of a molehill. Yeah, DHH is an awful person. His endorsement was removed from the page pretty quickly, but of course not fast enough to avoid the social media mob handing down their verdict upon the thankless maintainers. I sympathize with the Neovim developer in that thread, the driveby Github commenters with seemingly no other involvement in the project are some of the least well-socialized people alive.
The social media mob descended because one of the neovim maintainers was immediately actively hostile and defensive in the github issue, accusing the person who opened the issue to be making "demands" and "threats" (when there were no such demands or threats).
If the first reply on that issue was, "sure, you're right, could you submit a PR to remove it from the website", or even "this isn't important to me but I can see why this might turn people away, let's remove it", then there wouldn't have been any kind of drama.
Actually calling someone a nazi for opposing mass immigration is certainly a choice, but it's not one we should be rewarding with deference. It carried an implicit threat, and the github issue was a form of triangulation intended to force others to take a position on something they're not party to.
I've never liked DHH, but as far as I can tell, he's neither a white supremacist or a nazi. I'm also not the viewpoint police, and I have zero trust or patience for anyone that tries to be.
To be fair, it’s not hard to say “white supremacy is bad and I’m not cool with it”
It took me only 10 seconds to write.
It's also hard to stay cool and agree with the mob dogpiling you over (tbh) a triviality. Anyone who's had to have difficult conversations in the real world knows that. I'm not going to expect people to respond in the best way to such things (easy to project this expectation when you're an anonymous name in the crowd, though).
There wasn't dogpiling at first. The maintainer was the first person to reply to the initial issue report, and they were dismissive, defensive, and accused the person who opened the issue of bad faith.
All of that was uncalled-for and unnecessary, and then the dogpiling started.
> only 10 seconds to write
I'm White (99.44% pure Celtic-British Isles), and I type 100wpm. Isn't it ironic.
[flagged]
I still don’t understand how quoting something that someone said about Neovim means that you support Nazism, just because said person happened to be a Nazi.
To be fair, it’s not hard to say “grooming children is bad and I’m not cool with it”
It took me only 10 seconds to write.
In this case, all evidence points to the lead maintainer sympathizing with DHH's views. If his immediate hostility towards someone politely suggesting the removal of DHH's endorsement didn't make his stance clear enough, here's an archive of his previously public YouTube playlist titled "history," full of talks from far right ideologues like Peter Thiel and Curtis Yarvin.
https://archive.is/3cNBr
The relatively small core team has a member giving talks about Neovim at DHH's conference and another one prominently displaying Palantir as their employer in their GitHub profile.
It's clear where their sympathies lie, and that GitHub issue wasn't a one-off coming from a stressful online interaction.
I'm not gonna gather 'evidence' for or against what some guy who happens to maintain a text editor I use thinks about the issues of the day. It's just creepy behavior, and a huge violation of personal boundaries. Why do you think this is an acceptable thing to do? Go outside.
Regardless, the material you've posted doesn't indicate much about him to me beyond that we have political differences, which is okay. That's literally fine. It's definitely not enough to condemn someone as a Nazi sympathizer.
Before telling someone to "go outside," it's a good idea to make sure that you haven't written an entire paragraph filled with personal attacks using fresh throwaway accounts.
The things I listed are very public, each of which has raised very public concern. I didn't have to "collect" anything because the Neovim team already had a reputation for such things.
You may think the issues being raised are just "political differences." Enough people clearly see it differently. For many, the things DHH, Yarvin, and Thiel stand for crosses many lines. White supremacy, mass surveillance, or the destruction of democratic institutions aren't "fine." There's nothing more "creepier" than the ethnic targeting of people that Palantir enables.
Sorry, no, stalking people online is downright off-putting to anyone from the real world. Having non-political endorsements from people you (and, if you believe it, I) deeply dislike doesn't warrant this kind of treatment. You've simply worked yourself into a froth to justify doing it to someone you really don't know. What right have you to be 'concerned' about the Youtube videos someone watches in their private life? This is normal only to the social-media-mob-socialized.
This sort of runaway justification is a very common pattern from the self-righteous, across the political spectrum. It's why I need to use a throwaway to talk about these issues, even with people I ultimately agree with. Consider carefully how few hearts you've changed with this strategy.
So, yeah, I reiterate: go outside! Smell the roses! I'll follow my own advice, at this point.
What's off-putting is publishing a white suprematist course compilation on social media. Calling backlash against that "stalking" is utterly bizarre and detached from any actual meaning of the word.
Way back in junior high school our teacher showed us Adolf Hitler's speeches. Do you think she was actually a secret nazi preying on impressionable youths?
[flagged]
> programmer with political views
It's dishonest to downplay what his "political views" entail. He compared the removal of minorities to pest extermination.
> When wolves get out of control, you shoot them. When gypsies take over public spaces, you deport them.
In my view the core of the "drama" is about whether quoting an unpolitical statement of a person endorses the person as a whole, including their political views.
The maintainer who originally responded to the github issue clearly thinks that it does not. The reporter and Twitter mob think that it does
Whether we disagree with his political views (I hope so) and how political a project like neovim is would be questions to answer once agreement on the first question is reached
When you put an endorsement quote on your project page, you're addressing it to a large range of unrelated people who majoritarly won't even be users of your project (yet).
It's basically advertisement, we won't ever reach some universal conclusion on what any specific aspect of it means for your project, it's all in the eye of the beholder.
It's also all social norms, the maintainer doesn't get a choice on how it will be taken.
Accepting a PR from a racist is a very different thing to using a quote from a racist as advertising for your product.
If you don't want reactions to your advertising, don't advertise.
I would be very mindful about advertising endorsements from anyone at all myself.
Would you put up a quite from Hitler on your website endorsing your product, even if the quote wasn't about his views about anyone who is not a part of his "master race"? How about Pol Pot? Maybe Stalin?
If the answer is "yes", I think maybe you're a little out of touch with how people tend to view stuff like that.
Sure, DHH is not literally any of those people, but he certainly seems to really like Hitler. I just don't get why someone would want a quote on their website from someone who thinks minorities are pests to be exterminated, regardless of the content of their quote. Like, seriously, this is the hill you want to die on?
It doesn’t matter what his political views are, as they’re totally unrelated to what he said about Neovim. Quoting what he said about Neovim does not in any way indicate support of his political views.
[flagged]
[flagged]
[flagged]
[flagged]
Vim undofile "data loss" happens because Vim (VIM!) will reset the undofile will reset the undofile if an external tool (git, nano) changed the file while Vim is not running.
Go ahead, try it:
This is documented at `:help undo-persistence`.Spot on. It genuinely surprises me how many people don't realize that vim's persistent undo feature resets if the file is modified by anything outside of vim itself.
For example, a common scenario is rolling back a file via git, which triggers this reset. However, considering they treated it as a reliable version control system without actually reading the documentation, they probably aren't using git anyway.
The good news for them, however, is that they actually can bypass this limitation and treat their undo history like version control—by using nvim-fundo [1]. The catch is that they'll have to switch to nvim, as there isn't a direct equivalent for vim.
1. [nvim-fundo](https://github.com/kevinhwang91/nvim-fundo)
it seems they are using 'autoread' (but I guess this only works if vim is running while the modification happens)
https://infosec.exchange/@david_chisnall/117172481079439378
https://www.vim.org/scripts/script.php?script_id=5206
And vim will also reset it while "recover"ing the last unsaved changes. I believe no user relies on it to actually persist the history of a file. If someone is doing that whether in nvim or vim I'd seriously advise you to use a real VCS repo instead.
> 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.
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://news.ycombinator.com/item?id=49867678
* https://bastian.rieck.me/blog/2015/persistent_undo_vim/
Stop looking for post-hoc justifications for behavior that is clearly wrong.
Second time in this thread you’re telling other people how to think and behave because they aren’t acting like you
OK and you are doing the dril wise man tweet sincerely
How would you know?
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'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.
The user data in question lies in ~/.cache, which is a directory for files that aren’t meant to last long.
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.
https://news.ycombinator.com/item?id=49869740
> It's a feature most software doesn't even have
"All software should be shit because most software is shit"
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.
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.
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.
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.
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.
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.
Unless something changed very recently neither vim nor neovim defaults to storing persistent undo files in ~/.cache. It's application state, not cached data.
The undodir option in vim defaults to the directory of the file, and in neovim it defaults to ~/.local/state/nvim/undo/.
What did OP misunderstand? I am not sure how and where their understanding of "persistent undo" is different from "persistent across process restarts"?
In what way is it not a process restart if I stop the process, install/upgrade NeoVim and start a new process?
It's the part where you upgraded and apparently failed to read the release notes.
Or in the OPs case, installed a totally different application and was surprised by an incompatibility.
Nobody should have to read release notes to avoid data loss; there should never be a change such that someone who hasn't read the release notes (or missed a detail in reading them) to avoid such a problem.
You're holding others to a standard that you yourself haven't adhered to. Please go read the release notes. No mention anywhere that old undo data will be deleted.
https://neovim.io/news/2021/07/
Differences from Vim are also documented, but this issue isn't mentioned there either.
https://neovim.io/doc/user/vim_diff/
Also, what's up with people claiming that the undo files are stored under ~/.cache? That's completely made up. Or that persistent undo doesn't persist edit history, against what the docs say. Utter nonsense.
https://neovim.io/doc/user/undo/#_5.-undo-persistence
Users don't expect their editor to cause data loss after a routine `brew update`. Blaming users for that is unreasonable.
The lifetime of files in ~/.cache/ is the same as what the FHS documents for /var/cache [0]:
> Application cache data. Such data are locally generated as a result of time-consuming I/O or calculation. The application must be able to regenerate or restore the data. The cached files can be deleted without loss of data.
Meaning: the persistence of such files is not guaranteed across application restarts. If vim (and also neovim) had intended for the undo files to outlive the program, the files should have been put in ~/.local/state instead -- as also explicitly documented by the XDG [1]:
> [XDG_STATE_HOME] may contain: [..] current state of the application that can be reused on a restart (view, layout, open files, undo history, …)
[0] https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard#...
[1] https://specifications.freedesktop.org/basedir/latest/#varia...
That doesn't work here because the data was not wiped by a generic cache flush from a third party script or whatever, but a targeted hit from the application itself on files known to be persistent undo.
You just can't point the finger at file system standards, or shoulda-read-release notes or whatever.
There is no such thing as "by mistake, we historically stored persistent files in a directory with 'cache' in its name, contrary to a popular standard, so that makes it okay to trash them now".
> That doesn't work here because the data was not wiped by a generic cache flush from a third party script or whatever
But it was, it was program other than vim (neovim) that did it. It deleted a file in a space that is meant for transient files that may be deleted at any time for any given reason and should not cause data loss, and yet it did because vim, in the first place, broke the file system’s contract.
Neovim shouldn’t have been messing there but at the same time there’s a much bigger culprit here in that vim shouldn’t have been storing this kind of data there in the first place. It was a broken system that broke even further. Simple as that.
NeoVim is a forked continuation of Vim.
Blaming Vim is like politicians blaming the previous administration.
> The application must be able to restore or regenerate the data
That's a break of the contract then, right? The application was not able to regenerate or restore.
Cache is the wrong place for a persistent undo file.
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.)
As a vim user, I feel neovim was useful for one thing: it shaked regular vim development a bit. That said, I see no reason to switch. Good old vim is rock solid and featureful. I hope it doesn't die due to neovim's competition.
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.
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.
It's worth pointing out that vim is not "another program" as far as Neovim is concerned. It's an earlier version of the same program. Neovim is a fork of vim, not a totally different editor that happens to share part of a name.
Forking creates new programs.
If I fork chromium, I do not get to claim that I am a chromium maintainer.
Vim and Neovim are two seperate programs.
So maybe it should have two different undo files so both can be run side by side?
I am fairly certain that is the argument of the article.
It absolutely is another program, I can tell this because it has a different name. To run it I type "nvim" instead of "vim". I use different config files to control its behavior. I install a different package on my system when I want to use it on a new computer.
If it really is another program with reference to vim, it should leave undo files made by vim alone.
If it's going to nuke vim's undo files, it can't hide behind "another program".
That is the point.
I don't understand. Are you saying neovim does not nuke vim's undo files? The whole point of the article is that it does.
If that's not your point, then I have no idea what you're trying to say.
> I use different config files to control its behavior.
From what I can gather, you can use the same vimrc file to control both vim and neovim.
> giving away free software as a gift
Even a gift comes with an implicit promise that it will do no harm. Deleting important data of yours without warning is harm.
If you’re storing your important data in ~/.cache, you’re eventually going to suffer even if you don’t install Neovim.
This gift comes with the following clauses listed plainly in the license file:
It's genuinely mind-blowing to me that software can do something obviously bad, someone can point it out, and then someone will link to the license file to say they have the right to do it.
That's such an obvious category mistake that I'm not sure how to respond. It almost feels like a bad-faith interpretation of Wichary's original point.
Right. It is weird that this has to be explained, but let's make it clear: in the Before Times, probably anytime up to at least the late '00s, probably approximately no-one in or around free or open source software would have endorsed the idea that the legal disclaimers completely free even the most mainstream, self-publicising, broad-userbase open source projects from any moral or ethical obligation to have even the slightest concern to ensure that their software doesn't hurt or betray its non-paying users, even in the most harmful ways. And if one of the many and often vocal FOSS opponents of the time had started claiming that this is what open-source developers really believe they'd have rightly been seen as having veered off into the lunatic fringe. And that's because it's a, frankly, bonkers idea which is radically detached from normal human understanding of the social and moral role and obligations of volunteers, voluntary organisations, charitable givers or gift-givers. And also because it's a wildly counterproductive idea to put out there if you're hoping to increase FOSS adoption.
That does leave the question of why this idea has started to take off more recently. Part of the answer is certainly that Rich Hickey, disgracefully, set the ball rolling in this direction, and that many others have welcomed it as one weird trick and one pat answer for all the worsening problems of developer burnout. Unfortunately it seems hard to dismiss the idea that it's also social breakdown driven by a broader trend, as over time we move further and further from the pre-'60s "neurotic society" of people obsessed with duty and social conformity (often with oppressive or destructive results, to be sure) into the "psychopathic society" in which even people who don't themselves merit a Cluster B diagnosis have internalised narcissistic and psychopathic attitudes.
Equally mindblowing that folks feel someone hacking on open source software has an obligation to do anything the way they feel it needs to be done when the whole point is that anyone gets to do more or less what they want with the code.
You can't have both.
They get to do more or less what they want with the software, and others get to say more or less what they want about that. What's wrong with deciding they've crossed a line, being bothered by that, and warning others? Nobody's trying to get the law involved, or maliciously retaliate against them, or anything like that.
I published my comment for free, and yet you are criticizing it.
I think you are objecting to OP’s “duty of care” wording which could be interpreted as suggesting a legal obligation. Nobody in this thread is really arguing that open source developers have a legal obligation to do this and to not do that. We are just saying they should do this and should not do that.
> has an obligation to do anything the way they feel it needs to be done
> anyone gets to do more or less what they want with the code
so if the software had explicitly installed a root kit, you'd say the same?
If you give out free soup, you get to poison it too?
"My software ran rm -rf / but it's GPL so sucks to be you"
I don't think anyone is looking for legal remedies, this is not the right layer.
Is some part of:
"Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE."
Unclear? The fact that it's part of a license does not make it a legal-system-only warning.
The software might eat your dog, and feed your homework. Run it at your own risk, and be prepared to submit patches or fork it to make it behave the way one prefers.
This is one of the most exhausting (and frankly, exhausted) recurring arguments that comes up over and over again on HN.
Some bit of open source software does something bad or unwanted which causes people point out that it shouldn't do that bad thing. In this case, not even "the authors of this software should be held liable for the software doing the bad thing", just, "Hey, the right thing to do would be to update the software to not do the bad thing."
Why does this always lead a zillion people to come out of the woodwork to point at licenses and warnings or whatever? Like, yes, there's a warning. Your software having a warning doesn't mean people can't criticize you and your software for doing bad thing. Your software license does not give you immunity from criticism or from people saying you should change your software.
No, you don't have to change the software. Yes, other people are within their rights to fork the software themselves. But they can also point out that they told you that your software was doing the bad thing and you didn't fix it or change it, and that as a result they don't like you or your software or both — whatever. Nothing at all wrong with that.
I actually think you framed it really well. No parties involved have any particular obligations to each other. Nor should there be expectations otherwise without support. It sucks to lose data, everyone knows that, and no one wants it. And identifying things which can be improved is important. I stop at expecting someone else to do something because I want them to. I might hope they would, and try to convince them.
Such a disclaimer does not even remove all legal liability, it just reduces it.
Is the fact that we are not discussing legal remedies in this thread unclear?
The software might eat your dog, and feed your homework
Sure, and when it does we can say “this piece of shit ate my dog, and the authors of the software have no concept of a duty of care to their users”. And no amount of “well, axually…” is going to make any difference. I have a hard believing someone is copy-pasting a license file in good faith in response.
Most open source software is written by individuals who aren't paid for the effort, and are solving their own problems. Presuming that they feel an obligation to the folks who download and use their work for free seems... bold.
If my neighbor mows my lawn for free, I'm not going to complain about his workmanship. If I want the job done a particular way, the solution is to do it myself, or pay someone to do it the way I like.
> If my neighbor mows my lawn for free, I'm not going to complain about his workmanship. If I want the job done a particular way, the solution is to do it myself, or pay someone to do it the way I like.
I think this is a decent analogy, but it works better the other way. If my neighbour offers to mow my lawn, I accept, and then he destroys the flower bed adjacent to the lawn, I will be upset, and I will have every right to complain about what he did. If he reacts by blithely dismissing my concern, then I certainly have the right (and arguably the obligation) to warn others that they should think twice about accepting his offers of gardening assistance.
Some expectations reasonably go without saying; "don't destroy my flower bed when mowing my lawn" is one, and IMO "don't destroy my data without a clear warning and a chance to back out" is another, though of course we might disagree about exactly where this does and doesn't apply.
Suppose that you build a childrens' slide in your front garden. You put up a big sign saying "Consider using my slide! https://neovim.io/ Here are several wonderful things about it. It's free for everyone!" in your yard. Underneath in smaller letters you add "[No liability]". You also put up noticeboard ads for your free kids' slide in neighbourhood shopping malls https://launchpad.net/ubuntu/+source/neovim https://wiki.archlinux.org/title/Neovim . Unfortunately, when you built the slide, you left sharp metal edges and corners sticking far up on the inside, reaching into the path of the user. No reasonably competent and diligent metalworker or slide-maker would have failed to notice these major flaws or failed to understand the serious danger they represented. Several neighbourhood children use the slide and receive serious gashes to the legs, arms or face, and have to go to the hospital. Even assuming that your no-liability small print somehow had you free and clear legally, do you believe that your behaviour would have been ethically and morally above all criticism? Do you think that "should have read the small print!" or "can't I build what I like in my own front yard?!" would have you covered? Do you think that your family and friends would agree?
If my neighbor mows my lawn and ruins my whole garden, I'd definitely complain. (And if I were in the neighbor's shoes, I'd feel awful about it and try to fix things.)
If my neighbor mows my lawn for free, and in the process mows my flower garden down, things change a bit though don't they. That is a closer analogy. In that case I am going to complain, and maybe also tell everybody he's careless and not to let him near their lawns.
There's a long literary tradition of representing contracts as a tool of villainy. Signing them is generally treated as a Faustian bargain.
This is a great example of why. Most humans have a sense, deep down, that contracts often exist to bridge the gulf between the ethically defensible and the legally defensible.
It's hard to imagine that any sane person who is just looking to use a popular editor would read some broad limitation of liability language like the above, and interpret it to mean, "By the way, we intend to quietly delete certain files created by a competing fork of this project whenever we find them."
It's true that contracts with liability limitation clauses like this are an absolute necessity in this day and age. But there's also a non-legal principle of mutual respect that is absolutely necessary to a healthy open source community.
> It's hard to imagine that any sane person who is just looking to use a popular editor would read some broad limitation of liability language like the above, and interpret it to mean, "By the way, we intend to quietly delete certain files created by a competing fork of this project whenever we find them."
Forks of projects trodding all over each others files is one of the more common problems that has happened, historically. Prior to the major efforts around freedesktop.org around configuration standardization, it was quite common. It'd be one of the first things I looked for when switching to a fork.
I’m not saying it doesn’t happen. I’m saying it shouldn’t be defended as good. It’s a defect. And in this particular incarnation it’s a defect that directly clashes with fundamental Free Software principles such as personal digital sovereignty.
I also suspect that few people actually believe it’s ok and these legalistic defenses are more about circling the wagons. How many people would defend Microsoft if a new Office version automatically and quietly stripped edit history from documents that were originally created by other versions? Would we be hunting for limited liability clauses in their EULA to defend the design decision?
> I’m saying it shouldn’t be defended as good.
Thankfully, that's not a thing I ever did.
> I also suspect that few people actually believe it’s ok and these legalistic defenses are more about circling the wagons.
For me it's more about healthy boundaries and expectations. If I'm somehow paying for a project's development, I have higher expectations. If I'm not, I understand that I've chosen the dev/test track and there will be bugs and issues. The developer may choose to run off in an odd direction coughGnome3cough and my only recourse is to fork or hope someone else does. Disagreements as to how things should work happen pretty often.
I'm not defending anything or anyone. Just describing the system as it exists.
I am never going to use any software you have written.
“Here, take this car, it’s free!”
“Ow, the gas pedal is actually a bear trap.”
“Why are you complaining? It’s free!”
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."
Then you don't take the car. Why is this confusing?
That's not how liability works, not either morally or (IANAL) legally.
That’s fine, you can leave the car, but you’ve already lost your foot. Why do you find this confusing?
Because you didn't find out it was a bear trap until after you stepped on it?
Ah, yes. The old story of the one-footed man who didn't take the car.
Well I would feel slightly irate if I had to find out about the bear trap before I decide I don’t want the car.
You discover it’s a bear trap not before you try to pull out from the parking lot.
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.
If I give away food I have a duty not to poison you. It doesn’t matter you didn’t pay for it.
Others are eating it and are fine, chances are you’re allergic. Fortunately all ingredients are listed, you can check - or even modify the recipe yourself.
> Fortunately all ingredients are listed
How does this translate to the vim situation?
The point would be that it's open source. And "chances are you're allergic" translates to "your use case / expectations are unusual". But in my opinion the analogy doesn't hold well at all, because destroying a persistent undo file without warning is pretty obviously incorrect and unexpected behavior.
Software isn’t food.
So software that deletes important data of yours without any warning is ok because at least it isn't poisoning you?
If you have to twist things so far that intent doesn’t matter, something’s wrong.
According to TFA, it was completely intentional that they deleted someone’s data that had been created with a different program. Otherwise they would have acknowledged it was a bug. I do not know if this is true, only that it is what TFA claims.
It’s not great that Neovim destroyed/replaced files that aren’t clearly under its purview. They should have probably also made the consideration that a lot of Neovim users are going to be migrating from Vim.
Maybe if they’re making their own persistent undo standard, use different file naming conventions.
That said, as a fork of Vim, maybe the Neovim authors are at least partially reasonable in assuming that you’re not running multiple forks of Vim that could then potentially conflict with each other. It just sucks that they never really thought of a migration path for this particular feature.
Yes, everyone is aware of that. The parent poster was bringing up the example of food to demonstrate that our society does not agree that giving something away for free doesn't mean you have no obligation as to potential adverse effects of the thing.
Analogies like this don’t work when comparing against heavily regulated industry.
Neovim being free software is a lot different than United Airlines giving me a free flight or my doctor giving me a free consultation.
It’s very true that you can go to civil court and make a claim that a business or individual harmed you. If you do that with Neovim the judge is going to pretty quickly read bullet point #7 of the Apache 2.0 license, you’re going to struggle to prove any kind of mal-intent, you’re going to tell the judge that you paid $0 for the software, and you’ll be pretty quickly sent along your way with no damages awarded.
Only in the sense there's no explicit legal responsibility.
Do you really believe developers have exactly zero moral responsibility to their users? None at all?
Really?
Would you still believe that if you found the developers of ssh deliberately included a backdoor for hackers, or neovim was uploading everyone's code to the NSA?
I never said developers have no responsibility. Let’s not escalate. Now we are talking about actively malicious software versus a bug or design flaw.
This issue with Neovim sounds like less than ideal design, or a bug, or both, not some kind of intentional affront to users.
That is why software should have very large liability for anything software they release do? Say your software due to bug destroys some document. Surely you should pay damages caused by such bug even if quite high?
You must feel clever completely missing the point on purpose like that.
This guy you are arguing with is classic troll, he does it on every topic. Just ignore and don't reply.
Yeah, people like him is what the doenvote button is intended for.
"Your analogy is false because the two things you are comparing are not literally the same, dear sir!" is such a classic Internet discussion trope that it must have a name. If it doesn't, can I please name it? Maybe Perfect Analogy Fallacy?
But they couldn’t be further from different. You have to have a health inspector visit your kitchen just to sell food at all. You need affirmative permission from the government to sell food.
The original analogy was not about selling food:
> If I give away food I have a duty not to poison you. It doesn’t matter you didn’t pay for it.
If I invite you to eat at my house, there is no health inspector and no government. I'm just giving you free food. Would you agree that I have a duty not to poison you in that case?
True, yes, I agree.
If we aren’t making the business analogy though, then Neovim has even less obligation to produce a professional quality product. When you come to my cookout the expectations are different than when you go to a restaurant.
What do you mean by "obligation"? Nobody is claiming they have some kind of legal obligation. Nobody is saying anything analogous to your "health department" analogy. I think you're arguing against something people by and large are not claiming.
Okay, apologies in advance for how ridiculous this is getting and a lot of that is my fault, but I do want you to understand what I mean.
At the top of this discussion parent to where I said “software is not food”
> If I give away food I have a duty not to poison you. It doesn’t matter you didn’t pay for it.
First, I’ll start with the loaded language here: “duty not to poison you.” Yes, duh, no matter what, intentional poisoning is a crime. But the phrase is “not to poison you” which I interpreted to mean that we are taking about harm mitigation/prevention rather than intentional crime.
In that context it very much does matter if the relationship is giving away food for free in a private home versus selling or giving away food in public.
If we are to consider Neovim to line up with the “giving away food for free at my backyard cookout” analogy, they have a more relaxed standard of care. We don’t go to a BBQ and expect the hosts to have training from the department of health and signs that say “employees must wash hands before returning to work.” In this sense, Neovim would say, “hey, we did our best, we tried to make good software but this condition caused it to fuck up your files. Sorry.”
If we are considering Neovim to line up with “McDonald’s giving away free hamburgers for national hamburger day,” then now we have to recognize that the software industry does not involve nearly as much regulation as McDonald’s. Neovim’s story doesn’t change: “hey, sorry, we did our best, …” but McDonald’s doesn’t have that same standard of operation. Whether or not the hamburgers are free they have to get all the same licenses, do all the same training, and make their employees keep all the meats to temperature and all of that.
There’s no regulation around the general quality of software. You don’t have a strong claim to damages if your software crashes or causes problems. The remediation for problems like that is accomplished via SLAs in the business world, which obviously nobody has with Neovim. They’re just providing software as-is with no warranty or guarantee of quality or fit for purpose (#7 in the license agreement) and they’ve even been nice enough to provide the code ahead of time so you can audit it.
So unless someone at Neovim is in an evil lair declaring that they want to delete stuff on purpose to fuck up your day, there’s really not much of a logical case for their negligence here. It was provided at no cost, there are no significant legal regulations on software quality, they offered the code so you can inspect it, and they warned you in the license that it is provided with no guarantees or promises.
This concept of “duty of care” doesn’t exist in the software world, as much as we might prefer it to really exist.
The guy you're arguing with made the mistake of switching to metaphors. The result is several back and forth posts, and neither mutual understanding nor useful discussion.
To avoid metaphors: There's an implicit assumption that when you install a piece of software, it will not fuck up your data/system without your consent. No, installing it is not consent, neither is using it. Neovim does exactly that. No amount of food analogies or license quotes will change that fact.
Neovim authors should've just used a separate file, just like they're happy to use separate format and files for the configuration. Instead, they've decided to be dickheads, and interfere with vim's file, even after the issue being pointed out to them.
My guess is that as a fork of Vim they’re intending to replace Vim and therefore see no reason to try and coexist with it. They would probably say something like “why are you trying to use Neovim and vim at the same time?”
Whether or not that’s a good design is definitely discussion-worthy.
I’m not sure I agree about the concept that programs promise not to fuck up your data without your consent. Programs can’t really know what you are consenting to. The authors can’t assume you’ve read the manual or understand what the program was designed to do.
I think there’s a decent argument to be made that persistent undo files are more akin to metadata, similar to Microsoft Word recovery files or search indexes, but I haven’t made that argument because the author’s frustration on the issue seems logical and valid. It seems like it’s still not meant to be a data storage or backup mechanism: you wouldn’t share it in an email or check it into source control.
> and therefore see no reason to try and coexist with it
This is my main point of disagreement. This is not their decision to make.
> The authors can’t assume you’ve read the manual or understand what the program was designed to do
I think this is correct, but, the principle of least surprise should be paramount here. If the program states something like "migrate all vim-related files to neovim(This will lose all metadata when opened by vim)? y/[N]", I'd concede that neovim wiping data if the user chose Y as acceptable. Yet, they neither display the prompt, nor keep existing data.
Food is one of the more heavily regulated industries out there. Most other general business types are less regulated than food.
It's not poison, it's a broken feature. And you have the source code. Fix it if you like.
Sure, and then have it break again the next time upstream pushes a change. Or have something else break because upstream doesn't care about breaking things that I'm relying on.
The only way to "fix" this from a source code perspective would be to fork Neovim.
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.
Is there a good way to avoid programs like this in general?
You buy software that includes a commercial license that guarantees data retention
So that answer us no because such software does virtually not exist.
Can you point me to any such commercial text editor?
You can pay for google docs+ via workspaces and they have an explicit customer data retention guarantee in their license.
> They are open source developers, giving away free software as a gift. There is no duty here.
But actually there is! They didn't start from scratch. They took another very successfull and beloved project with the promise "to make it better". There is some promise here and the duty not to make it worse.
"Better" is subjective. They made it better...for themselves. Then gave it away so people who share their opinion, had the opportunity to choose to use it.
> Then gave it away so people who share their opinion, had the opportunity to choose to use it.
How many neovim users were made aware that the software would proactively delete their decade-long file history?
Probably no more than a rounding error away from zero.
It would be really surprising if they could make it better for literally every user. The perpetual undo is just better handled by git.
And this obligation lasts… for the rest of their lives?
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.
"Behold my glorious generosity, which eclipses your petty meaningless little data!"
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 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 constitutes a professional.
And for what it's worth, I have flagged your comment for the inevitable pointless bickering it has precipitated. While applying reductionist frameworks and seeing where they lead is a necessary part of an individual's path to understanding, please avoid pushing ignorant assertions ("there is no duty here") as if they might constitute well reasoned truths.
Sure. And nobody has a duty to use it. This user states that (s)he doesn't want to use an editor that doesn't care for its users. I don't blame anyone here.
If people can be upset when llms delete a file, we can be upset when an open-source project deletes a file.
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.
Ill remember this when I distribute malware.
To be fair some malware has a better support and care experience than some open source software. The malware actively encourages you to contact them to pay the ransom. The open source software, no such luck.
Oh my. This set of principles is appropriate for malware.
If you don’t like how it works, go build your own.
I already build software where I hold myself to a higher standard than malware, so not sure I get your point. Why not strive for a better world with good software?
Your suggestion that it is malware is misleading. Malware is “any software intentionally designed to harm, disrupt, or steal data from computers”. I sincerely doubt that was the author’s intention.
Everyone in open source is trying to write good software and the definition of good is subjective depending on overall design, features, ease of use, quality, and performance.
If an open source project is missing a feature, go build it. If the project maintainers don’t want it, fork the project. Be the change you want to see in the world. That’s the beauty of open source.
> If an open source project is missing a feature, go build it.
> Be the change you want to see in the world.
The feature being: don't delete my data belonging by another program? It's kind of too late once deleted isn't it? And now even that other program cannot use the data either.
> giving away free software as a gift. There is no duty here.
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?
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.
You spewing bs like the left-pad dev who removed it from NPM a decade ago crashing everything.
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.
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.
Vim does things at least as bad. Here’s something I wrote in 2020 that shows how the default Vim configuration can overwrite files created outside of Vim and cause autobuild systems to fail: https://lee-phillips.org/badvim/
And why my .vimrc starts with this:
>I deleted something from this file, maybe last week
Don't forget time travel: `:earlier 7d`
Neovim is advertised as being a plug in replacement for vim, which is 100% not true. Many things are different, including undo files and :!. I can't remember the feature that made me give up, but at some point the switch became more work than it was worth, considering my vim setup already works. I'm not sure what I would do if I were starting out today.
"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.
> 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.
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.
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.
More like in the LLM era, people are disrespecting the user and not sweating these details with ever increasing velocity. It isn't good.
This story is about software being a slow, deliberate process where a lack of gatekeeping can lead to data loss. This is the type of problem which is getting worse.
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.
We also live in a very different world now compared to 2021 when the problem was reported. A brief Gemini query to translate the old diff format to the new one returned in a few seconds with what appears to me a correct, < 40-line, solution.
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
The simpler and less contentious way to adopt innovations is to make a new tool with the innovation. For example, you might like https://helix-editor.com/
Oh my, I will, thank you.
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. I did feel discouraged to learn it at first because the people introducing it to me were doing pointlessly fancy things in it, some combination of custom keybinds and scripts to mass edit files.
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.
What about ki-editor?
https://ki-editor.org/
The discussion here is going to be hamstrung without direct access to the entire Mastodon post:
https://infosec.exchange/@david_chisnall/117171776562702259
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.
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
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.
How does one use persistent undo in vim?
Talk about poor duty of care to users... been using him for 20 years and I have to enable it in my vimrc to take effect. So stupid. Why would I want this to be off?
Such amazing design...
" Enable persistent undo set undofile
It’s somewhat important for privacy reasons that the feature is opt-in. I don’t know if that’s the reason historically, but I wouldn’t want a text editor to persistently store a copy of everything I type without my consent. It’s almost like a keylogger.
Making privacy-sensitive features opt-in is a form of duty of care as well, to avert harm from the user.
Edit history in JetBrains being on by default saved my bacon a few times over the years.
I prefer persistent undo being off. I like being able to hold down u and revert to exactly how the file was before I opened it. (Maybe there's a better way to do this?) With persistent undo on, it just keeps going and going. And if I need long term source control, that's what git is for. With persistent undo off, it's like opening the file creates a checkpoint that I can get back to easily.
Emacs and Vim are basically like that.
They have very vocal and entrenched users so that practically no defaults can be changed lest the single Amiga user will start a huge uproar.
And since they don't really have a BDFL or commercial pressure, they can be super detached even from standards or expectations that appeared 40 years ago.
Neovim was basically a reaction to that, for Vim, where they updated defaults to stuff basically every Unix editor since 2005 has.
Maybe neovim should advertise like: Your fully configurable vim instance as a full IDE on your developer machine, only.
Driven by <3, passion and bravery.
Anyhow; I switched back to vim after one year of neovim shrugs. Still a Junior, here.
Awkwardly speaking, Microsoft Word is a great example of a program that appreciates backward compatibility.
VIM should be in the title here as well
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.
`:h 'undodir'`. Also undofile is off by default.
That’s why I stopped getting all those swap file messages every time I opened vim…
You need to be carefull with any vim fork
Chisnall needs to start making backups
Disturbing to see justifications for this program behaviour. The only time a program I write explicitly deletes persistent user data is if the user is interacting with a modal that very, very clearly warns them they are taking an intentional action to delete data. Migrations always backup the files being operated on before performing any migration actions. This is surely common sense. It is clear that many of you have absolutely zero regard for anyone who uses your software. Which is, I suppose, not surprising given how much software is absolute unusable dogshit.
[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.
Are you responding to the wrong post? This isn't anywhere in TFA
It's in the first link in the post.
Mastodon? More like mast–
yea i found that a bit odd to throw in right at the end there. i dont really understand what that means
[dead]
TLDR: Neovim did a breaking change to persistent undo
That is not the story here. The story is Neovim deleted data created by another program, on someone else's computer.
I don't know if this story is true, but you can't defend it when taken at face value.
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?
I think this might not be clear on the issue, it broke vim's undo file, as in it deleted it and replaced it with Neovims version.
Just by trying Neovim you can lose your vim undo file.
This is the crux of the matter. I wish a few of the "its OSS" commentators here would read this.
That wasn't the point.
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.
…and even trying Neovim out on a file permanently deletes your undo history for that file, even if you switch back to vim.
[dead]
[flagged]
Right. The point of the article is for the author to tell us neovim doesn’t care about their users and the author recommends us to use something else.
Put another way, why did the author “test in production” on their important work when evaluating a new piece of software they were unfamiliar with?
Vim is a very popular piece of software to the point where there are dozens or perhaps hundreds of forks made by all kinds of people. Many if not most of these forks are probably not very good.
And you can also rant about it so other people are not harmed in the same way without warning
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.
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.
[flagged]
It’s Open source.
Some people just want to keep looking at the gift horse in the mouth.
As an open source developer I hate this attitude. If you do not care about the users why are you even releasing the software?
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...
Because they care about a different subset of the users? You can’t make everybody happy.
It’s a free country.
Which one?
All the ones where you can build open source (excluding the ones where you elected governments that send police to your house for Facebook posts or where governments welcome “asylum seekers” that try to blow up your military bases and never “connect the dots”)
[1] https://x.com/TalkTV/status/2104152494636986371/video/1?s=46