David Chisnall has used vim since 2000. Five books, a PhD thesis, dozens of papers, 150-plus articles. At that level of muscle memory, the editor disappears — your fingers think in commands while your brain thinks in prose. Random :w keystrokes appearing in documents written with other tools is the signature of someone whose vim reflexes have fused with cognition itself. The feature at the center of this story is persistent undo — vim's ability to maintain a complete undo history across sessions, reboots, and months of inactivity. You close a file in March, open it in September, and your entire edit history is intact. You can rewind to last Tuesday's version of paragraph three. It is, as Chisnall frames it, the embodiment of Jef Raskin's First Law: a program may not harm a user's data or, through inaction, allow a user's data to come to harm. NeoVim, a fork of vim pitched as the familiar tool made better, broke this contract on first contact. It changed the persistent undo file format, did not migrate existing files, did not use a different filename, and — critically — silently deleted the old vim undo files and replaced them with its own incompatible format. Chisnall's entire undo history, across every file NeoVim touched, was gone. Vim couldn't read the new files either. The damage was bilateral and irreversible. The technical failure is forgivable. Format changes happen. What Chisnall found unforgivable was the response: NeoVim maintainers told him the persistent undo format was unstable and users should not rely on data being preserved in it. A feature explicitly named "persistent undo" — persistence being the entire point — came with an implicit disclaimer that persistence was not guaranteed. This is the moment the story stops being about vim and starts being about something larger. Raskin's three laws, published in The Humane Interface in 2000, read like Asimov's Laws of Robotics applied to software design. Don't harm user data. Don't waste user time. Be responsive to human needs and frailties. They are so simple they feel obvious, yet most software violates all three routinely. The laws haven't penetrated mainstream development culture the way they should have, and Chisnall's post is a reminder of what happens when developers treat user data as an implementation detail rather than a sacred trust. The deeper pattern here is attitudinal, not technical. NeoVim's response revealed a mental model where the tool's internal convenience outranks the user's accumulated work. "It had changed once and would probably change again" is a statement about priorities: the developers' freedom to iterate matters more than the user's right to rely on the system's promises. Every user who has lost work to a cavalier software update recognizes this feeling instantly. Chinall's post also surfaces something underappreciated about long-lived tools: the longer you use them, the more invisible value accumulates in their state. Twenty years of persistent undo history is not a feature — it's a safety net woven from thousands of hours of work. Destroying it silently is not a bug. It's a breach of the relationship between tool and user that Raskin spent his career trying to articulate.
