upvote

points

by kazinator5 hours ago |
comments
upvoteby RVuRnvbM2e4 hours ago|
next
[-]
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.

reply
upvoteby soraminazuki21 minutes ago|
parent|
next
[-]
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.

reply
upvoteby kazinator2 hours ago|
parent|
prev|
[-]
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.
reply
upvoteby tremon5 hours ago|
prev|
[-]
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...

reply
upvoteby kazinator3 hours ago|
parent|
next
[-]
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".

reply
upvoteby iifisnfiejf49 minutes ago|
parent|
[-]
> 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.

reply
upvoteby kazinator31 minutes ago|
parent|
[-]
NeoVim is a forked continuation of Vim.

Blaming Vim is like politicians blaming the previous administration.

reply
upvoteby maxnoe2 hours ago|
parent|
prev|
[-]
> 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.

reply
upvoteby 35 minutes ago|
parent|
[-]
deleted
reply