Installing NeoVim Deleted Original Vim Undo Files: Who Is Responsible for User Data?

A Data Accident Triggered by a Single Install

A user who installed NeoVim encountered an unexpected consequence: the undo history files belonging to the classic Vim editor were quietly deleted. What might seem like a minor technical footnote sparked over 200 comments on Hacker News (the post received 253 points), and the core debate wasn't about a specific bug — it was about what responsibility software developers owe their users.

The original post's title said it all: They had no concept of a duty of care to their users. That phrase cuts to the heart of what truly unsettled the community: when a tool silently touches data that doesn't belong to it, the issue stops being a matter of "feature design" and becomes one of trust and ethics.

Why Undo Files Matter So Much

For developers who have long relied on Vim, undo files are anything but disposable temporary caches. Vim's persistent undo feature allows users to roll back edits even after closing and reopening a file. These histories often preserve the evolution of a piece of code, content that was temporarily deleted but might need to be recovered, and intermediate changes that were never committed to version control.

In other words, undo files carry a user's editing memory. Once deleted, what's lost isn't just a few files — it's an operational history that cannot be recovered through Git or any other conventional means. This is precisely why an "install side effect" provoked such a strong emotional response: it violated the most basic expectation users have of their tools — don't break my stuff without telling me.

Vim's persistent undo feature is enabled via set undofile, and by default stores undo history in separate .un~ files (or a user-specified undodir). These files record every insert, delete, and replace operation in binary format, theoretically allowing unlimited rollback beyond the boundaries of a single process session. In practice, developers frequently rely on this mechanism to recover code that was "half-deleted before realizing it was a mistake," or to trace how a function looked across different drafting stages. Unlike Git, undo history is continuous and fine-grained — it captures intermediate states that were never committed, which is exactly what makes it irreplaceable.

"Duty of Care": From Legal Concept to Software Ethics

"Duty of care" is originally a legal term, referring to the reasonable obligation one party has to exercise caution when their actions may affect others. The original post brought this concept into the software domain, raising a question every developer should consider: should software default to treating user data with care and caution?

In this incident, NeoVim — as a fork of Vim — shares overlapping file paths and configuration directories with its predecessor. When NeoVim's installation or initialization logic touched directories used by the original Vim and performed cleanup or overwrite operations, it caused cross-software data destruction. The key question is: was this kind of operation subject to adequate risk assessment? Were users given clear warnings or a choice?

Based on community reactions, most people believe that "do not destroy existing user data by default" should be an inviolable baseline. Any default action involving deletion or overwriting should be extremely conservative — ideally requiring explicit user consent, or at minimum providing a reversible backup mechanism.

The Shared-Path Dilemma of Forked Software

This incident also exposed a pervasive technical challenge in the open-source ecosystem: when a project forks from another, the two often share the same configuration conventions, directory structures, and even file naming rules. This compatibility brings convenience, but also plants the seeds of mutual interference.

The relationship between NeoVim and Vim is a textbook example. To ease migration for existing users, a fork has every incentive to read, reuse, or even clean up the original configuration — but if handled carelessly, it will overstep and operate on files that are "nominally shared but still actively used by another piece of software." The ideal solution is for the forked project to use a completely independent namespace and data directory, eliminating the possibility of accidentally harming the original software's data at the design level.

In its early versions, NeoVim actively read Vim's ~/.vim directory and related config files to lower the barrier for migrating users. However, as NeoVim gradually introduced its own configuration standards (such as ~/.config/nvim), two sets of path logic coexisted, blurring the boundaries. The XDG Base Directory Specification (a Linux application data storage standard proposed by freedesktop.org) could serve as a natural anchor for forks to achieve data isolation — and NeoVim did adopt it — but legacy compatibility logic, if not rigorously cleaned up, can still reach Vim's traditional paths under certain conditions. This highlights that when a fork claims "compatibility," it must make an equally explicit commitment to the boundaries of that compatibility logic.

Lessons for Developers

Beyond the specific technical details, the real value of this discussion lies in the engineering principles it distills. Any operation that deletes or modifies user files should be treated as high-risk behavior, requiring explicit confirmation rather than silent execution. Software should exercise extra restraint when handling data it doesn't fully own. When a project forks from an existing tool, data isolation should be a default design decision — not an afterthought.

The combination of 253 points and 202 comments shows that the developer community remains acutely sensitive to the topic of user data safety. Whether a tool deserves trust often has nothing to do with how powerful its features are — it comes down to whether it will hurt users in the worst case. That, in the end, is what "duty of care" truly means.

Note: This article is based on the Hacker News discussion thread and the original post title. For specific technical reproduction details, please refer to the original post and official repository documentation.