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.
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
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.
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.
I would consider deleting my persistent undo state, which would be something that I would have specifically enabled, to be "severely impacting".
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).
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.
So the case is, you really need you undo history and want to try out neovim so you just copy paste you vimrc to the new place and accidentally delete your data? I don’t think it’s that bad personally. It’s bound to happen but it’s not automatic.
Two programs that save their cache in the same folder causes issues.
Unlike Dr. Chisnall, I started my editor journey on Neovim, so it wasn't a transition that bit me. However, if the format of the persistent undo file is unstable, and Neovim just deletes it when it doesn't recognize the previous format, then it seems conceivable (to me) that an upgrade after changing the format would delete the file too.
Ouch. This is making me think about getting off of Neovim. Yes, FOSS comes as-is, but if there's an alternative...
I could see ignoring the old undo data or warning before discarding it but just silently wiping it is so user hostile it’s hard to comprehend.
If not, I wonder how Google justifies it.
Google is abysmal. In every sense of the word and in every product they touch.
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.
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.
Second (for servers), etckeeper
> 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
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).
Moreover, the vim history tracking is amazingly advanced. It's almost like a mini version control system. I highly recommend getting to know it.
Bare vi does not have windows, visual selection mode, multiple level undo, color schemes, etc.
NVim wants to improve some defaults, which cannot be done if it is beholden to all legacy code. That being said, I still think this specific undo example is insane.
Vanilla Vim added it in 2016 I think, but by that time I had already fully switched to NeoVim and it didn't seem worth it to me to switch.
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.
Just run make from another terminal...
I often use vim or nvim on disposable machines, so persistent undo is something very low on my list of things I want.
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 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.
But it is a nice feature.
I do that by using version control. I have it hooked to my editor so that "save" is "check in". Now I have persistent, versioned, copies of all my states independent of whatever tools I happen to be using.
You do not have all your states available.
I just tried it in Nextcloud Notes on Android (FlorisBoard has undo/redo buttons), and it seems to work this way. If I type a bunch of words quickly and hit undo, it removes all of them. If I stop for a couple seconds between each word, it undos them one-by-one.
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.
The feature's name has "persistent" in it.
For example applying the recover file (well it's a huge pitfall in vim on its own) resets not only the current undo history but also the "persistent" one.
They don't get a pass because you disagree with an imagined use case.
[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.
https://github.com/neovim/neovim.github.io/pull/504 of course with sweet sweet drama!
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.
Seems so. As smart as keeping tabs open in browser instead of using bookmarks, but "workflow".
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
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)
The way I personally remember it being positioned was “Vim, but with breaking changes.”
The original author of this post (on Mastodon) appears to have a bone to pick with Neovim since it's "platforming white supremacists"? I couldn't figure out what this meant. Some sort of internet drama I guess.
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.
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.
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.
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.
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.
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.
It took me only 10 seconds to write.
All of that was uncalled-for and unnecessary, and then the dogpiling started.
It took me only 10 seconds to write.
I'm White (99.44% pure Celtic-British Isles), and I type 100wpm. Isn't it ironic.
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.
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
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.
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?
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.
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.
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.
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.
"All software should be shit because most software is shit"
Relax for a second. Get some perspective.
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.
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.
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.
```markdown
abhorrent
/əbˈhɒr(ə)nt/
Abhorrent is an adjective that means morally very bad, hateful, or causing strong disgust and loathing.
```
I realise that this causes strong disgust and loathing in you, but can you please expand upon how it's morally very bad to prioritise speed and ease of use over undelete capability in Neovim? Are you unable to make backups or use Git?
> Are you unable to make backups or use Git?
Ah yes, the old perty theft justification as applied to intentionally-inflicted data loss; "They won't mind if I take/delete this, they (should) have insurance".
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.
https://github.com/neovim/neovim/pull/13973#issuecomment-789...
If it's really just a toy with no expectation of not unexpectedly destroying user data then they ought to make that more clear.
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.
The undodir option in vim defaults to the directory of the file, and in neovim it defaults to ~/.local/state/nvim/undo/.
Or in the OPs case, installed a totally different application and was surprised by an incompatibility.
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.
> 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...
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".
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.
Blaming Vim is like politicians blaming the previous administration.
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.
(Or rather, you can, but you will likely be disappointed.)
We can speak, respectfully, of how important backwards compatibility is to us, and ask nicely for them to give more of their time to support it when their free sodftware isn't backwards compatible. Perhaps we can even offer to help implement it.
But they have no duty to do so or to "care" for their users. (They have already demonstrated they care for their users, btw, by giving them free software.)
EDIT: I missed an important part of the story, which is that they mutated existing files in a non-backwards compatible manner. That should have been avoided, I understand where the (secondary) author is coming from now.
I 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.
If I fork chromium, I do not get to claim that I am a chromium maintainer.
Vim and Neovim are two seperate programs.
If it's going to nuke vim's undo files, it can't hide behind "another program".
If that's not your point, then I have no idea what you're trying to say.
From what I can gather, you can use the same vimrc file to control both vim and neovim.
Even a gift comes with an implicit promise that it will do no harm. Deleting important data of yours without warning is harm.
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.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.
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.
You can't have both.
> 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?
"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.
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.
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.
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.
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.
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 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?
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.
“Ow, the gas pedal is actually a bear trap.”
“Why are you complaining? It’s free!”
How does this translate to the vim situation?
The only way to "fix" this from a source code perspective would be to fork Neovim.
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.
> 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.
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.
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.
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.
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?
This issue with Neovim sounds like less than ideal design, or a bug, or both, not some kind of intentional affront to users.
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.
How many neovim users were made aware that the software would proactively delete their decade-long file history?
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.
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.
> 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.
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.
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.
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.
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?
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.
Don't forget time travel: `:earlier 7d`
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.
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.
And look at this article’s HN discussion. Many people indignantly defending it. “It’s open source. If you don’t like it deleting your data, don’t use it!”
Maybe we aren’t so rare. I can think of another group that values enduring hardship over progress making things easier for everyone.
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.
Of the over a hundred students I taught when I helped out in uni, basically no one wanted to learn it, despite my enthusiasm.
And I sympathise. As I get older, I slowly grow more and more distaste for software that does not respect my time enough to give me properly-crafted defaults. Vim, in the age of modern editors, cannot compete. Not without 20 plugins with conflicting shortcuts and its self-imposed cliff of a learning curve.
And I’m saying this from a place of love; I’ve been using Vim (at least as a VSCode extension) every day for the last 10 years. But it never really grew up to the promise that the “Vim Creep” essay [1] gave me.
[1]: https://web.archive.org/web/20190227031109/https://www.norfo...
:wq
As for default plugins, it'd be neat if they curated a set of optional ones, but nothing should be preinstalled.
I dream of a Vim that wóuld guide and teach me how to use it, so that it does not scare away people because they can’t close it.
I dream of a Vim that embraces the needs of editing contemporary programming languages and fills in its UX gaps correspondingly (changes single to double quotes, anyone? Function argument order?).
I dream of a Vim with native Git gutters.
I dream of a Vim with sane default leader commands.
I dream of a Vim where I see line numbers by default.
I dream of a Vim where “Y” is consistent with other commands.
I dream of a Vim that detects correct indentation by default. And that can visualise whitespace.
I dream of a Vim where Ctrl+V does not have an assigned action that looks like it blocks input.
I dream of a Vim that experiments with keyboard ergonomics, not just mnemonics.
I dream of a Vim where quintuple-tapping Escape is not a habit I subconsciously form why learning it.
I dream of a Vim I stumble on people discovering and exploring, and not have to persuade people for months just to try it.
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.
Such amazing design...
" Enable persistent undo set undofile
Making privacy-sensitive features opt-in is a form of duty of care as well, to avert harm from the user.
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.
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.
I don't know if this story is true, but you can't defend it when taken at face value.
The point was they did it in a completely stupid way and responded to a bug report about it in a way that suggested this might not be just the occasional stupid that we've all had slip into our code.
Just by trying Neovim you can lose your vim undo file.
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.
Hell I can and have contributed and have been told to fuck off and fork it or entirely ignored.
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.
Some people just want to keep looking at the gift horse in the mouth.
[1] https://x.com/TalkTV/status/2104152494636986371/video/1?s=46
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.