The author frames this as a cultural failure, not a technical one — NeoVim silently overwrote Vim undo files it didn't recognize instead of prompting, backing up, or logging. They emphasize that persistent undo exists precisely to protect rarely-touched files, and destroying it without warning betrays the decade-long trust users place in stable tooling.
The submitter surfaced this story to a 371-point front-page ranking, signaling strong community agreement that silently clobbering unrecognized undo files is unacceptable behavior for a serious editor. The framing of the submission title itself asserts that NeoVim caused the deletion, placing responsibility squarely on the installer's defaults.
A 2017 NeoVim issue flagging this exact hazard was closed as 'working as intended,' with the official guidance being that users should set a distinct undodir per editor. This position treats the overlap as user misconfiguration rather than a defect in NeoVim's write path, arguing the format divergence is documented and the fix is trivial for anyone paying attention.
The author acknowledges the maintainers' advice to use separate undodirs is technically correct but argues it 'completely misses the point.' The deeper failure is that any tool encountering an unrecognized file format in a user-data directory should refuse to overwrite, prompt, or back up — silent destruction is never an acceptable default, regardless of whose config is 'wrong.'
The author points out that the top Google result for 'vim persistent undo' recommends exactly the shared-directory configuration that triggers the bug. This implicates the wider ecosystem of copy-pasted dotfiles and tutorials as an amplifier — NeoVim's defaults may be safe in isolation, but they interact catastrophically with the config patterns users actually encounter online.
A post on unsung.aresluna.org titled *'They had no concept of a duty of care to their users'* hit the Hacker News front page with 371 points, recounting a small disaster that will feel familiar to anyone who has ever trusted a config default. The author installed NeoVim alongside their existing Vim setup. NeoVim, out of the box, writes its persistent undo files to `~/.local/state/nvim/undo` on modern Linux, but a common shared configuration — the kind you find in every third dotfiles repo — points both editors at the same directory. When NeoVim opened files that Vim had previously edited, it saw undo files it did not recognize, treated them as stale, and overwrote them. Years of undo history, gone. No prompt. No backup. No log line.
The technical mechanism is boring; the cultural mechanism is the story. Vim's `undofile` format has evolved. NeoVim reads Vim's older undo format but writes its own. If you configure both editors to use the same `undodir` — which is exactly what the top Google result for 'vim persistent undo' tells you to do — the first NeoVim write silently invalidates the Vim history for that file. The author lost undo state going back to files they hadn't touched in years but occasionally reopened, which is precisely the use case persistent undo exists to serve.
The HN thread is unusually pointed. Commenters unearthed a NeoVim issue from 2017 flagging the exact hazard, closed as 'working as intended.' The current advice from maintainers is to set a distinct `undodir` for each editor — which is correct, and also completely misses the point.
Persistent undo is one of those quiet features that only reveals its value in hindsight. You never notice it working. You notice it, once, when it saves you from a catastrophic edit six months ago. Anything that silently destroys it is destroying a specific kind of user trust — the kind built up by tools that behave the same way for a decade.
The defense here is that the behavior is documented. That defense doesn't survive contact with how software actually gets installed. Nobody re-reads the `:help undo-persistence` page when they `brew install neovim`. They inherit a config from a coworker, from a YouTube video, from a GitHub dotfiles repo with 12,000 stars. The default posture of every modern package manager is 'install this and it will do the right thing.' When 'the right thing' includes 'silently discard on-disk state written by a sibling tool,' the documentation is not the mitigation. The mitigation is either (a) don't do that, (b) detect it and refuse, or (c) migrate the state.
The deeper issue is the fork math. NeoVim forked Vim in 2014. Eleven years later, most of the ecosystem — dotfiles, tutorials, StackOverflow answers, plugin READMEs — still treats them as interchangeable enough to share configuration. The maintainers of both projects benefit from that ambiguity: NeoVim gets Vim's mindshare, Vim gets NeoVim's momentum. But every shared file path is a boundary neither side has agreed to police. Undo files are the visible failure. Swap files, viminfo, and shada have similar seams.
Compare the response here to how Postgres handles on-disk format changes: `pg_upgrade` exists, the release notes scream about it, and if you try to start a server on an incompatible cluster it refuses with a specific error. That's what a duty of care looks like on disk. NeoVim's equivalent would be: on first launch, if `undodir` contains files written by Vim's older format, either migrate them, back them up, or refuse to write. Instead: silence, then overwrite.
The response from maintainers — some version of 'it's your config, read the docs' — is technically defensible and culturally corrosive. It's the same posture that gave us `rm -rf ~/.$UNSET_VAR/` in Steam's uninstaller, `npm` deleting node_modules with symlinks, and every 'the user was holding it wrong' post-mortem for the last twenty years. The pattern is: a tool encounters ambiguous on-disk state, picks the destructive interpretation, and the maintainer response is that the interpretation was, in fact, correct.
Audit your `undodir`, `backupdir`, `directory`, and `viminfo`/`shada` paths right now. If Vim and NeoVim point at the same directory, split them — `~/.vim/undo` and `~/.local/state/nvim/undo` are the sane defaults. If you inherited a dotfiles repo, check whether that repo was written pre-2020; a lot of them predate the divergence and still assume one editor.
More broadly: anywhere two tools share on-disk state — Docker and Podman on `/var/lib/containers`, `pip` and `uv` on `site-packages`, `node_modules` between pnpm and npm — assume the first one to write wins and the second one is a data-loss risk until proven otherwise. The ergonomic pitch of drop-in replacements is 'you don't need to change anything.' The operational reality is that state written by tool A is a lie to tool B unless tool B has been explicitly built to read it. Persistent undo is small stakes. Container storage layers and package manager lockfiles are not.
If you're a maintainer, the lesson is even simpler: when your tool encounters on-disk state it didn't create, the default should be 'preserve or refuse,' never 'overwrite.' The cost of a refusal is a one-line error message the user Googles. The cost of an overwrite is user trust you don't get back.
NeoVim will not fix this. The issue has been open in various forms since 2017 and the maintainers have signaled they consider it out of scope. What will happen instead is that dotfiles authors will slowly, individually, split their `undodir` config — a distributed workaround for a problem the tool refuses to own. That's the modal outcome for issues like this in successful OSS: the community routes around the maintainer position. It works, eventually. It also costs every new user who hasn't updated their config yet a chunk of undo history they'll never know they lost.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.