Comment by kazinator
6 hours ago
In what way is it not a process restart if I stop the process, install/upgrade NeoVim and start a new process?
6 hours ago
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.
1 reply →
> 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.