Why Developers Are So Attached to Their Text Editors

Nobody starts out attached to their editor. You install whatever a tutorial or a coworker recommends, and for the first few months it is exactly what it looks like: software for editing text.

The shift happens quietly. Somewhere around the thousandth time you save a file, jump to a definition, or rename a variable, the keystrokes stop being a decision. Your fingers move before you consciously choose the command. At that point the editor has left the category of "tool I use" and entered the category of "thing I think with."

A tool you have to think about using is still in your way. A tool you no longer notice has become part of how you work.

This is not unique to software. Musicians describe their instrument the same way, and drivers describe a manual transmission the same way. What makes editors different is how much time developers spend inside them — often more hours per day than any other single application — which gives the automation more time to set in.

Once editing is automatic, switching editors doesn't just mean learning new menus. It means routing something that used to be reflexive back through conscious attention — for weeks. That reopened loop, not the feature list, is most of what a "just switch, it's better" suggestion is asking someone to pay.

The vi/Emacs split goes back to 1976, and it never really resolved — it just gained new participants as IDEs, then VS Code, then Neovim showed up with their own answers to the same question. The question underneath all of it is simple: how much should the editor already know, versus how much should you be able to teach it?

• vi and its descendants bet on a small, composable command language that is available on nearly every Unix system by default. Learning it once pays off everywhere.
• Emacs bet on being a Lisp interpreter with a text editor built on top, so that almost nothing about it is fixed — including, eventually, what counts as "editing."
• IDEs bet on deep, language-specific understanding of your code, at the cost of being heavier and less general.
• VS Code bet on a large extension ecosystem around a fast, approachable core, which is why it became the default for people who don't want to assemble their own setup.
• Neovim bet on modernizing the vi model — Lua configuration, a built-in language server client — without discarding decades of muscle memory.

None of these bets are wrong. They optimize for different things, and the "war" is really several separate, unresolved arguments about trade-offs that don't have a universal right answer.

Configurability and out-of-the-box competence pull against each other. Emacs sits far toward "reshapable" and asks you to build competence yourself; a full IDE sits far toward "already competent" and asks you to accept its opinions. VS Code and Neovim both try to sit further along both axes than their ancestors did, which is a large part of why they picked up so many users who had previously assumed they had to choose one side.

A stranger's init.lua or .emacs.d can look like decoration — colors, fonts, a status bar. Read one closely and it's closer to a diary. Every keybinding remaps a friction the author actually hit. Every plugin exists because some real task, repeated often enough, was worth automating.

;; Jump straight to the test file for the current buffer.
;; Added after the third time I searched for it by hand in one afternoon.
(defun my/find-test-file ()
  (interactive)
  (find-file (my/test-path-for (buffer-file-name))))

(global-set-key (kbd "C-c t") #'my/find-test-file)

That's why dotfiles repositories are shared and forked so freely: they're not templates so much as records of what a particular person found annoying, over years, and decided to fix. Borrowing someone else's configuration wholesale rarely feels right for long, for the same reason wearing someone else's broken-in shoes doesn't — the shape was fitted to different feet.

Over a career, almost everything else changes. Languages fall in and out of fashion. Frameworks get rewritten. Companies get acquired, codebases get replaced, teams reorganize. A developer who stays in the field for fifteen years will likely work in five or six different primary languages and far more employers than that.

The editor is frequently the one thing that survives all of it. The same keybindings, the same navigation habits, the same mental model for moving through a file — carried from a first internship into a tenth year, across languages the developer hadn't even heard of when they set up their config. That kind of continuity is rare in a career this volatile, which is part of why people defend it more fiercely than the software itself would seem to justify. It isn't really about the software. It's about not having to relearn the one thing that stayed the same.

Editor debates online tend to get framed as feature comparisons — startup time, plugin counts, LSP support — because those are the parts that are easy to put in a table. The real disagreement sits underneath that: how much time you're willing to spend building a tool versus how much time you want the tool to save you immediately, and how much you value being able to reshape your own workflow versus trusting someone else's defaults.

Neither answer is wrong. A developer who wants to open an editor and be productive in five minutes is making a reasonable trade against one who wants to spend a weekend teaching their editor to do something no one else has ever needed. What makes the conversation feel personal is that it usually isn't really about which editor is objectively better — it's two people who have each spent years automating the same friction in different directions, each convinced the other's daily annoyance is optional.

So the next time someone gets unexpectedly defensive about :wq versus Ctrl+S, it's worth remembering what's actually being defended: not the software, but the years of small, invisible fixes layered underneath it, and the fact that the software has quietly become part of how they think.