Thread

1. gavinhoward · 1790522634 · focus · HN ↗

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

   1. cdmckay · 1790526672 · focus · HN ↗

      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.

      1. rcxdude · 1790582432 · focus · HN ↗

         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.

         1. eviks · 1790607165 · focus · HN ↗

            > 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

            1. rcxdude · 1790620684 · focus · HN ↗

               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.

Unofficial Hacker News client; not affiliated with Y Combinator.