The vim-versus-emacs argument is older than most engineers currently using either editor. It traces to two parallel design decisions made within months of each other at opposite ends of the United States in 1976, and the disagreement under the surface has not really changed since. The argument is sometimes presented as a culture war or a tribal allegiance, which it has periodically been. Underneath, it is a technical disagreement about whether the cost of learning a modal text editor is worth what modal editing gives you. The honest answer in 2026 is it depends on how much time you spend in the tool, which is exactly why the war has not ended.

Line editors before screens were a given

Both lineages descend from ed, the line editor Ken Thompson wrote in 1969 as part of the first Unix. The motivation for a line editor in 1969 looks alien now: most users did not have a screen, they had a paper terminal — a teletype that printed each line of output on a roll of paper. There was no point in showing the user a page of text because there was no way to update it. ed worked the only way that made sense in that environment: you addressed a line, you printed it, you replaced it, you moved on. The interaction was a transcript.

ed is still installed on most Unix-like systems in 2026, mostly unchanged. It is unusable as a daily driver and useful in exactly two situations: scripted text manipulation, and recovery work when nothing else is available.

Bill Joy, ex, and vi

In 1976 at UC Berkeley, Bill Joy wrote ex — extended ed — as a more capable line editor. ex is still alive as a synonym for vi -e. The interesting bit was what Joy added on top: a visual mode — vi, accessed by typing vi at the ex command prompt — that took advantage of the new generation of CRT terminals to show the user a full screenful of text and let the cursor be moved around inside that screen. In 1978, with the release of version 2.0, the visual mode was promoted to a first-class editor and shipped on the Berkeley Software Distribution tape as vi.

The single defining design decision of vi was modal editing. The editor has distinct modes — normal, insert, command, visual — and the keys mean different things in each mode. In normal mode, the home row keys are commands (h j k l move the cursor; dd deletes a line; yy copies one). In insert mode, the same keys insert text. The mode is the context that turns a sparse set of keys into a rich command vocabulary without ever requiring a modifier like Control or Meta.

Joy's framing was simple: a programmer spends more time reading and modifying code than typing it. If most of the time is reading and modifying, then most of the time should be in a mode where the keyboard is dense with commands and editing operations require zero hand motion. Insertion mode is the exception, used only when text is actually being entered.

Vim, Bram Moolenaar, and the second life of vi

vi itself, the original Joy implementation, was tied to the AT&T Unix licence and could not be redistributed in its original form. Through the 1980s a handful of clones emerged — nvi, elvis, stevie — but the one that won was Vim, written by the Dutch developer Bram Moolenaar starting in 1988. Vim originally ran on the Amiga, was open-sourced in 1991, ported to Unix shortly after, and over the following decade picked up every feature that the various vi clones had been competing on: multiple buffers, multiple windows, syntax highlighting (vim 5.0, 1998), scripting via Vimscript, then Python and Lua and Ruby bindings.

Moolenaar shipped Vim under a charityware licence: the software was free but the licence asked users who found it useful to donate to ICCF Holland, a charity supporting Ugandan children. Moolenaar maintained Vim for thirty-two years until his death in August 2023. Maintenance passed to Christian Brabandt and a small core team. The project has continued without him.

The descendant fork most heavily used in 2026 is Neovim, started in 2014 by Thiago de Arruda as a more modular rewrite with embedded Lua scripting and an explicit plugin API. Neovim and Vim coexist; most plugins target both.

Emacs, in parallel

In the same year — 1976 — at the MIT AI Lab, Carl Mikkelsen, Richard Stallman, Guy L. Steele Jr., and David A. Moon were building a set of macros for TECO, an existing editor on the lab's PDP-10. The macros were editor macros — EMACS — and they implemented a higher-level set of editing commands on top of TECO's primitive operations. By 1978 EMACS was a complete editor in its own right, and the TECO foundation became gradually less load-bearing as the macro layer grew.

GNU Emacs is the version of EMACS that most engineers actually use, and it is mostly Stallman's work: a rewrite in C with Emacs Lisp as the scripting layer, first released in 1985 as the founding application of the GNU project. The Emacs Lisp layer is the defining architectural decision — almost every behaviour of the editor is implemented in Lisp, on top of a small C core, and almost any behaviour of the editor can be modified or replaced by writing Lisp. The technical claim is that Emacs is not so much a text editor as a programmable text-processing environment with text-editing as its default mode.

The design decision opposite to vi's modality is Emacs' modifier-based design. The keyboard always inserts text by default; commands are invoked through Control and Meta key combinations (C-x C-s to save, M-x to invoke any command by name). The cost is that the modifier keys are pressed constantly — Emacs pinky is a well-documented repetitive-strain risk — and the benefit is that the editor never enters a state where the next keystroke does something other than what a user uninitiated in modes would expect.

What the editor war was actually about

The disagreement under thirty years of conversation is technical, not cultural:

• Modal editing (vi/vim) puts the editor in a state. The same key has different effects depending on the state. Insert mode is the exception; normal mode is the default. The learning curve is steep because the first hour with vim is unusable until the user internalises the mode model, but the long-term benefit is a dense command vocabulary with zero modifier keys.
• Modeless editing (emacs, nano, every GUI editor) treats the editor as a constant — typing inserts text — and provides commands through modifier-key combinations or menus. The learning curve is shallow because the basic interaction (type to insert) is what a first-time user already expects. The long-term cost is that the editor must use modifier keys for everything that is not insertion, which is heavy on the wrist.

Both choices have merit. The vi argument is that programmers spend most of their time not typing, and the right design optimises for not typing. The emacs argument is that an editor should be programmable from the inside, and modes are a layer of friction between the user and the programmability. Neither side is wrong; they are answering different questions.

The actual day-to-day battles — over indentation, configuration files, plugin systems, the religious significance of one editor or the other — were always proxies for the underlying question. The proxies aged badly. The underlying question is still live.

Nano, the third option

Nano was written by Chris Allegretta in 1999, originally under the name TIP (TIP Isn't Pico), as a free replacement for Pico — the editor bundled with the proprietary Pine email client. TIP was renamed to nano in 2000 and joined the GNU project in February 2001. The design is the opposite of vim and emacs: a small editor with a menu of commands across the bottom of the screen and no need to learn anything beyond what's on the screen.

Nano is the editor most engineers under 30 reach for when SSH'd into a server, which they would prefer not to learn. It is the default editor on Ubuntu Server when git commit opens an editor for the message, and on a handful of other Linux distributions. It is the casual third option that won the casual market by not asking to be learned.

Why vim won the default slot on Linux

Vim, not emacs, is the default editor on most Linux distributions and on macOS, in the sense that command-line tools (crontab, visudo, git commit, kernel build options) open vim when they need an editor for an interactive prompt. The reason is small and operational: vim's binary footprint is around 3 MB, it has no GUI dependency, it ships in BusyBox-style minimal images, and it runs in any terminal with no configuration. Emacs is larger (around 70 MB on a recent distribution), has historically had a heavier startup time, and is more often installed as an opt-in than as a default.

The default-editor question is a separate question from which editor a developer uses daily. Plenty of engineers use VS Code or JetBrains tools or Helix or Zed for everything, and only see vim because the git commit prompt landed in it. The default-editor slot is the floor of the editor war, not the ceiling.

A short close

The editor wars were a thirty-year argument about whether to optimise for the rare case (text insertion) or the common case (text manipulation). vi and emacs both have honest answers; they are different answers. Vim won the default-editor slot on Linux because it is small and runs everywhere. Emacs won the programmability slot because its Lisp layer is more powerful than anything its competitors built. Nano won the casual market by not asking to be learned. The argument continues in 2026 mostly because every position remains technically defensible, which is the rarest property a software argument can have.