What an Editor Owes Your Undo History

Key takeaways

• Vim and Neovim can preserve undo history across editing sessions when persistent undo is enabled.
• Losing that history can remove access to earlier edits even when the current file is intact.
• Reading an old format and preserving its contents are separate design decisions.
• Keeping incompatible history gives users a chance to attempt recovery, without guaranteeing success.

Imagine updating your editor, opening yesterday’s configuration file, and discovering you can no longer undo yesterday’s edits. The file is intact, but the setting you deleted halfway through the afternoon is gone from view. That hypothetical exposes a practical question for Vim and Neovim: what should an editor do with saved undo history it can no longer read?

Your saved file tells only part of the story

Undo is easy to think of as a short-lived convenience: make a mistake, press a key, carry on. Persistent undo extends that convenience across sessions by saving editing history to disk.

When enabled in Vim or Neovim, it lets history survive closing the editor. That history may contain the information needed to restore text that no longer appears in the current file.

Suppose you revise a configuration three times. The final version works, but a week later you need a setting you removed during the second revision. The saved file cannot tell you what it was. Undo history might.

Even with Git, intermediate edits may never make it into a commit. Sometimes the useful version is the one you discarded before deciding anything was worth committing.

Undo history is no substitute for a separate backup. Still, losing a recovery path matters. Checking that the latest file survived answers only part of the question.

Failing to read history is one decision. Replacing it is another.

Suppose a future editor version cannot read an older undo file. Perhaps its internal structure has changed, or the project has retired the code that interprets that format.

That is a backward compatibility problem. What happens to the existing file is a separate design choice.

The editor could leave it untouched and report the problem. It could move the old history aside before starting a new record. Or it could delete or overwrite the old file.

Those choices have very different consequences.

If the original survives, a user may be able to try a compatible editor version or a conversion tool. Recovery is uncertain, but there is still something to work with.

Once the original is deleted or overwritten, that particular route closes. An automatic replacement can be just as destructive as an explicit delete operation. The useful question is whether the earlier history survives.

An unstable format still holds someone’s work

Maintaining compatibility costs time. Supporting old formats means retaining parsing code and testing behavior across versions. That work competes with new features and bug fixes.

A project can reasonably warn that its undo format may change. Users should take that warning seriously: a newer release may be unable to read older history.

But a compatibility warning does not settle how existing records should be handled.

People enable persistent undo because they expect history to remain useful later. Storing it in an auxiliary file does not make the contents unimportant. A deleted paragraph has the same value to its author regardless of which internal file category holds the last recoverable copy.

Maintainers do not need to support every historical format forever. They should explain what ending support means and give users a chance to prepare. That is a product design responsibility, even when the format itself carries no stability promise.

Preserve the original, then start fresh

A practical default would be to keep unreadable history and store new history separately. The editor should tell the user what it could not read and where it preserved the original.

Automatic conversion deserves the same care. Keeping the source until the result has been checked leaves room for another attempt if conversion fails.

Preservation has costs, too. Old records consume disk space, and accumulated files eventually need cleanup. Clear retention settings and user control over deletion would make those tradeoffs visible.

Error messages also need to explain the outcome. “Incompatible undo file” says little about what remains. “Could not read previous undo history; original saved separately” gives the user something actionable.

An editor earns trust by saving today’s work and handling yesterday’s work carefully. When support for a format ends, preserving the original can keep a compatibility problem from becoming an irreversible loss.