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.

So if a program decided it owned .cache and deleted it every startup you’d be fine with it?

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 have a far less sensationalist headline for this which is:

Two programs that save their cache in the same folder causes issues.

Why not give it a different name, so that it would not break vim?

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.

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?

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.

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.

Nvim's `:!` behaviour was a deliberate design decision, which is one of the reasons I just stick with Vim9.

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 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.

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)

I don't use git. I actually have something still using RCS.

Someone didn't read the part about wanting a humane interface

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.

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?

Btw zen browser's folders are many streets ahead of Firefox's traditional bookmarking.

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.

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.

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/

Insane? Abhorrent?

Relax for a second. Get some perspective.

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?

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.

The “drama” was linked in TFA:

https://github.com/neovim/neovim.github.io/issues/501

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.

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...

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.

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:

   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.

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?

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.

It's not poison, it's a broken feature. And you have the source code. Fix it if you like.

Software isn’t food.

Is there a good way to avoid programs like this in general?

"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.

And this obligation lasts… for the rest of their lives?

It would be really surprising if they could make it better for literally every user. The perpetual undo is just better handled by git.

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.

If you don’t like how it works, go build your own.

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.

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.

Oh my, I will, thank you.

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.

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.

It's in the first link in the post.

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?

This is the crux of the matter. I wish a few of the "its OSS" commentators here would read this.

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.