The vim undo history NeoVim deleted, and the duty of care to users

On August 28, Marcin Wichary's blog Unsung published a post built almost entirely around a Mastodon message from computer scientist David Chisnall. The subject is vim's persistent undo and, more broadly, what software owes the data of its users; the title comes from his own line: “They had no concept of a duty of care to their users.”

Chisnall has used vim since around 2000, writing five books, a PhD thesis, a few dozen papers and more than 150 articles with it. Its commands now run without conscious thought, and documents written in other tools end up with stray vim commands in the middle.

What persistent undo protects

Persistent undo is one of his favourite vim features. He rarely needs it, but when he does it is invaluable: recovering something deleted “maybe last week and one reboot ago”, or finding what an edit broke before a commit. vim has kept this working across major version upgrades for about 20 years: even after a crash or half a year later, the undo history is still there. Chisnall calls this part of Raskin's First Law.

What happened with NeoVim

NeoVim is a fork of vim. Chisnall tried it when it was quite new; the first thing he noticed was that undo did not work, and opening the file in vim did not help either. NeoVim had changed the format of undo files: it had not upgraded the old file or renamed its own, but deleted the existing vim undo file with all its data and replaced it with one vim could not read.

He raised an issue and was told the persistent undo format was unstable: users should not rely on data being preserved in a feature explicitly called persistent undo, and it had changed once and would probably change again. That ended his experience with NeoVim. “The authors showed immediately that they absolutely could not be trusted with any of my data,” he wrote, adding that he could forgive broken undo as a bug, but not an attitude in which a file on a user's disk is no reason for a program not to delete it.

Raskin's laws, and why the story resonates

Wichary quotes the message almost in full and draws several lessons: people do remember when software loses their hard work or disrespects them, and “it had changed once and would probably change again” explains why broken trust is so hard to rebuild. It also brings in the three laws from Jef Raskin's 2000 book The Humane Interface: a computer shall not harm your work or, through inaction, allow your work to come to harm; it shall not waste your time or require more work than is strictly necessary; and an interface is humane if it is responsive to human needs and considerate of human frailties. Wichary calls the book formative for him as a young designer.