A computer scientist named David Chisnall has posted a vivid account of how a fork of his favorite text editor treated his saved work with astonishing disregard. The story, titled “They Had No Concept of a Duty of Care to Their Users,” is a reminder that software developers sometimes forget that their code lives inside other people’s lives.
Chisnall’s post opens with a confession about his long relationship with the editor vim, which he has used since around 2000. He has written five books, a PhD thesis, dozens of papers, and over 150 articles with it. His hands move through its commands without thinking, and documents he wrote elsewhere carry stray references to vim’s internal commands because his fingers have forgotten how to type normally.
The Undo That Never Dies
One feature stands at the center of the story: persistent undo. Vim keeps a record of every edit, stretching across sessions and reboots, so a file’s history survives crashes and restarts. Chisnall calls it one of his favorite features. It shows up rarely, but when it does, it saves the day.
He describes the moment he needs it most: a typo from last week, buried under a reboot, a file he deleted by accident weeks earlier. The undo history lets him step backward, find the lost text, copy it, and paste it back. Or the simpler case: a working script he cleaned up before committing, which suddenly stops working afterward. Undo reveals the change that broke it.
Chisnall frames this reliability as a matter of principle. He cites Raskin’s First Law, a rule from the design of the Macintosh and the Canon Cat that states a computer shall not harm a user’s work or let it come to harm through inaction. Vim, in his telling, obeys that law automatically. If the computer crashes, if he closes a file and returns to it months later, his undo history is still there.
NeoVim’s Undo Failure
Then came NeoVim, a fork of vim that promised improvements. Chisnall tried it when it was new. Vim he knew; NeoVim should have been better. Great!
Instead, he found a problem on his first try. The undo did not work. He opened a file, pressed the command, and nothing happened. He tried again in the original vim. Same result.
The problem was not a bug. NeoVim had changed the format of the undo files. It had not upgraded the old ones. It had not given the new files a different name. It had simply noticed the existence of a vim undo file, deleted it, and replaced it with one that vim could not read. All the data inside was lost.
Chisnall raised an issue about this. The response he received was blunt: the persistent undo format was unstable, and users should not rely on data being preserved in a feature explicitly called persistent undo. It had changed once and would probably change again.
That ended his experience with NeoVim. The authors had shown, immediately, that they could not be trusted with any of his data. Breaking undo as a bug he could forgive. Treating a persistent file on his filesystem as fair game for deletion because it contained data he might want was another matter entirely.
Why This Story Resonates
The post has resonated because it names a specific failure that feels universal. Software loses people’s work all the time. Most of those stories end with a shrug: it happens, reinstall, move on. This one ends with a refusal to accept that outcome.
Chisnall’s story is about trust. A tool that respects your history earns your loyalty. A tool that deletes it without warning earns your contempt. The difference between a bug and a betrayal is intent, and NeoVim’s intent, as Chisnall reads it, was indifference.
The story also introduces Raskin’s First Law, a rule from Jef Raskin, who is of Macintosh and Canon Cat fame. Raskin published the three laws in his 2000 book The Humane Interface. They are:
- A computer shall not harm your work or let it come to harm through inaction.
- A computer shall not waste your time or require you to do more work than is strictly necessary.
- An interface is humane if it is responsive to human needs and considerate of human frailties.
Chisnall liked the post because it covered several important things. He had never heard of persistent undo described that way, and it seemed amazing. People do remember when software loses their hard work or disrespects them. And the feeling of being told a feature is unstable and will probably break again is a powerful one.
The Duty of Care
The title of Chisnall’s post is the verdict. “They had no concept of a duty of care to their users.” That is a strong charge, and it sticks because the evidence is specific. A file format change that erases history is not a feature update. It is a decision to discard information that belongs to the person holding the keyboard.
The story has a practical lesson too. Persistent undo is a small thing, but it is a signal. A project that preserves your edits across sessions and crashes is a project that treats your work as valuable. A project that deletes your undo files without warning is a project that treats your work as disposable.
Chisnall’s post speaks to a shared frustration. Software eats our lives, and it should not eat our history. The undo key is not a luxury. It is a right.
Key Facts Box
– Chisnall has used vim since around 2000
– He has written five books, a PhD thesis, a few dozen papers, and over 150 articles with it
– NeoVim deleted undo files without warning
– The response was that the format was unstable and would probably change again
Source material: “"They had no concept of a duty of care to their users.",” aresluna.org.
Get the Notebook.
The day's best stories and every fresh verdict, in plain English, in your inbox by seven. One email a day, no more.