From QED to Neovim

Using a *nix sys­tem's ter­minal can feel dan­gerous. If you don't know what you're doing, you may ac­tu­ally leave your system in a state of dis­re­pair. Si­mul­ta­ne­ously, the ter­minal can feel in­cred­ibly em­pow­ering. It peels back a layer of ab­strac­tion, of­fering a di­rect way to dis­cover and ma­nip­u­late a system. Since *nix is ubiq­ui­tous, learning it once lets you use it prac­ti­cally any­where.

The Modern Text Ed­itor

Most modern pro­gram­ming re­quires a method to pre­cisely se­lect, input, and arrange text. Nat­u­rally, this tool should be­come an in­dis­pens­able piece of soft­ware in the pro­gram­mer's broader suite of au­thoring and de­bug­ging tools.

Ac­cording to Stack Over­flow's 2024 de­vel­oper survey , Mi­crosoft's Vi­sual Studio Code is the pre­ferred IDE (in­te­grated de­vel­op­ment en­vi­ron­ment)— used by 73.6% of re­spon­dents. It was also the "most de­sired"— by 58.7% of re­spon­dents. How­ever, Neovim — a modern text-based ed­itor— was ranked "most-ad­mired" (ad­mired by 82.7% of re­spon­dents).

Ter­minal-Based Ed­i­tors

An im­mense ben­efit of text-based ed­i­tors is their ability to run within a sys­tem's ter­minal em­u­lator. Every modern system should be ac­ces­sible via a ter­minal, so a text ed­itor that's ren­dered with UTF-8 char­ac­ters can run on vir­tu­ally any system.

A ter­minal em­u­lator can pro­vide di­rect ac­cess even to head­less en­vi­ron­ments— on a com­puter or vir­tual ma­chine (VM) without a dis­play. Some sys­tems, like a cloud-hosted web­site, may not be con­nected to a dis­play; or, it may lack the com­pute power needed to run a full graph­ical user in­ter­face (GUI).

Without a GUI, editing with VS­Code isn't a vi­able op­tion.

nvim

Neovim (a char­acter-based text ed­itor) is ca­pable of run­ning di­rectly in­side a ter­minal. It was forked from Vim in 2014 but still re­tains com­pat­i­bility with Vim's editing model (com­mands, short­cuts, and editing "modes").

Since that orig­inal fork, how­ever, Neovim has also ag­gres­sively refac­tored much of Vim— evolving into a pow­erful and highly con­fig­urable al­ter­na­tive. It is avail­able across any *nix host (and, yes, Win­dows ), and it pro­vides modern fea­tures com­pa­rable to VS­Code—

• lan­guage server in­te­gra­tion
• an ab­stract syntax tree (AST) parsing en­gine for pre­cise syntax high­lighting and mo­tions
• straight-for­ward plugin sup­port
• Lua con­fig­u­ra­tion and scripting

Over the past decade, Neovim has at­tracted wide­spread ad­mi­ra­tion within the de­vel­oper com­mu­nity— even spurring the same cult-like ob­ses­sion as its im­mor­tal­ized pre­de­cessor, Vim.

Human-Com­puter In­ter­ac­tion

The text ed­i­tor's con­tem­po­ra­neous tech­nology has al­ways set rea­son­able lim­i­ta­tions on human-com­puter in­ter­ac­tion (HCI). Be­fore more wide­spread adop­tion of in­ter­ac­tive dis­plays, com­puters would mark their output on a con­tin­uous feed of paper. Be­fore the ad­vent of in­ter­ac­tive input de­vices, a pro­grammer would te­diously pre­pare a stack of sorted punch cards as a means of pro­viding in­struc­tions to a ma­chine.

It was during the 1950s and 1960s that "com­puter sci­ence" was es­tab­lished as a formal dis­ci­pline— with Purdue Uni­ver­sity ac­tu­ally es­tab­lishing the first com­puter sci­ence de­part­ment in 1962. In­ter­ac­tive text-editing— pressing a key and im­me­di­ately seeing it ap­pear on a screen— wasn't a preva­lent HCI until 1976 . For the sake of reigning in the con­ver­sa­tion, I'll focus on Unix-based text ed­i­tors that co­in­cide with the his­tory of the Unix op­er­ating system— be­gin­ning in 1969.

Tur­tles All the Way Down

There have been many in­flu­en­tial ed­i­tors to shape the field of soft­ware en­gi­neering. Can­didly, I am an in­doc­trinee of the Neovim cult. As its de­vout acolyte, this ar­ticle serves as a med­i­ta­tion on the ori­gins of the ed­itor for cu­rious and rev­erent readers.

In order to build con­text and pro­vide some cul­tural in­sight, I've at­tempted to cat­alog some of the people and con­ver­sa­tions (and even old man­uals) sur­rounding the cre­ation of the most in­flu­en­tial ter­minal ed­i­tors.

You might see a piece of soft­ware at­trib­uted to a single con­trib­utor, but it's rare that an in­di­vidual makes some­thing en­tirely in iso­la­tion— without building on the foun­da­tion of others. In my ex­pe­ri­ence (and his­tor­i­cally), soft­ware is de­riv­a­tive, it­er­a­tive, and col­lab­o­ra­tive.

Like­wise, Neovim was not pulled from thin air— it is a fork of Vim (specif­i­cally, ver­sion 7). Vim it­self was an evo­lu­tion— of the vi text ed­itor. The vi ed­itor emerged from ex. And there is a clear evo­lu­tion which un­ravels back to the first Unix graph­ical ter­minal ed­itor— ed.

qed

Be­fore ed, we'll take one step fur­ther back— to qed (or QED— for "quick ed­itor"). QED was con­cep­tu­al­ized in the late 1960s (circa 1967) by L. Peter Deutsch and Butler Lampson at Berkley. Dana An­gluin , who's work on com­pu­ta­tional learning theory is cred­ited as foun­da­tional to modern ma­chine learning, also con­tributed to an ini­tial im­ple­men­ta­tion .

QED was used on the Berkeley Time Sharing system— on an SDS-940 . It was run mainly on Tele­type in­puts— CRT dis­plays were not con­sid­ered in its de­sign.

The ori­gins of Unix date back to the mid-1960s when the Mass­a­chu­setts In­sti­tute of Tech­nology, Bell Labs, and Gen­eral Elec­tric were de­vel­oping Mul­tics, a time-sharing op­er­ating system for the GE 645 main­frame com­puter¹

The name "Unics" was ac­tu­ally a pun on the "Mul­tics" name . QED would con­tinue to be used in Mul­tics— I even found a manual from 1983 of the later qedx im­ple­men­ta­tion written by Bob Daley .

• source code
• manual

ed

Ken Thompson used QED at Berkeley be­fore he came to AT&T Bell Labs . Upon ar­riving at Bell Labs, Ken Thompson wrote an im­proved ver­sion of QED— with reg­ular ex­pres­sion pat­tern matching— for the MIT CTSS (Com­pat­ible Time-Sharing System) in the As­sembly lan­guage. CTSS was used at Bell Labs as part of their par­tic­i­pa­tion in the Mul­tics pro­ject— which it dropped out of in 1969.

Ken's CTSS qed adopted (from the Berkeley one) the no­tion of mul­tiple buffers to edit sev­eral files si­mul­ta­ne­ously and to move and copy text among them... also the idea of ex­e­cuting a given buffer as ed­itor com­mands, thus pro­viding pro­gram­ma­bility. (TECO, which grew into Emacs, was ap­prox­i­mately con­tem­po­ra­neous or just a bit later, and elab­o­rated these ideas in­de­pen­dently).²

At Bell Labs, Ken and Dennis Ritchie (cre­ator of the C pro­gram­ming lan­guage ) con­cep­tu­al­ized a sim­pli­fied op­er­ating system— con­vinced that the cur­rent models were overly com­plex. Con­cisely, they de­ter­mined that three es­sen­tial el­e­ments were nec­es­sary for the new system:

1. An as­sem­bler
2. A shell
3. An ed­itor

Short for ed­itor, but pro­nounced as dis­tinct char­ac­ters (ee dee), the ed text ed­itor be­came the ded­i­cated (line-mode) text ed­itor for the Unix system. The ed text ed­itor would later be in­cluded in the POSIX stan­dard and, in fact, re­mains there today. If you're on an Apple com­puter, try opening the ter­minal and typing man ed.

• source code (GNU)
• manual (GNU)

em

In London, in the fall of 1975, Peter Salus de­vel­oped em ("ed­itor for mor­tals") at Queen Mary Col­lege (now, Queen Mary Uni­ver­sity— the first UK site to get Unix). It was an ex­ten­sion/​up­grade of ed which set the ter­minal mode "raw"— en­abling single char­ac­ters to be read as they were typed. This al­lowed vi­sual editing within a single line by sending a RETURN char­acter fol­lowed by a new ver­sion of the line after each al­ter­ation.³

• source code
• manual

en

Bill Joy — co-founder of Sun Mi­crosys­tems and au­thor of the vi ed­itor— de­scribed yet an­other or­phaned ed­itor in the arc of Unix his­tory. In an in­ter­view for the Au­gust 1984 issue of Unix Re­view:

So Chuck (Charles Haley ) and I looked at that and we hacked on em for a while, and even­tu­ally we ripped the stuff out of em and put some of it into what was then called en, which was re­ally ed with some em fea­tures... I'd break the ed­itor and he'd fix it and then he'd break it and I'd fix it. I got re­ally big into writing manual pages, so I wrote manual pages for all the great fea­tures we were going to do but never im­ple­mented.⁴

ex

Peter Salus had in­tro­duced his em pro­gram to Bill Joy in 1976— spending the summer at U.C. Berkley's com­puter sci­ence de­part­ment.

Bill had taken my code as a starting point and had got a long way to­wards what was to be­come 'ex' and sub­se­quently 'vi'...

• manual

vi

Vi was orig­i­nally cre­ated for the Unix op­er­ating system by Bill Joy in 1976 as a "vi­sual" mode to the ear­lier text ed­itor— ex (short for ex­tended). "Vi­sual" meant that it could be used across mul­tiple lines com­pared to the line-ori­ented editing ca­pa­bil­i­ties of ex. Though, at the be­gin­ning, vi and ex were in­ter­faces to the same pro­gram, and it was even pos­sible to switch back and forth during an editing ses­sion.

• In 1987, Tim Thompson cre­ated an­other vi clone for the Atari ST— without copying any source code from the OG vi. He called it STEVIE (ST Ed­itor for VI En­thu­si­asts).⁵
• In 1988, STEVIE was ported to OS/​2, Amiga, and Unix by Tony An­drews and G. R. (Fred) Walter.⁶⁷

Using the Stevie source code al­lowed the pro­gram to be dis­trib­uted. Pre­vi­ously, the vi source code would have to be li­censed by AT&T. The open source port that An­drews im­ple­mented was mod­i­fied by Bram Moole­naar — even­tu­ally be­coming Vim (or "Vi IM­i­ta­tion").

• source code
• manual

vim

Moole­naar would con­tinue to work on Vim for the next few years (on the Amiga )— making the first public re­lease in 1991. The VIM acronym would be de­rived as "Vi IM­proved" (rather than IM­i­ta­tion) as it started to add fea­tures atop the base vi im­ple­men­ta­tion. In 1992, Vim was ported to Unix and in­tro­duced mul­tiple win­dows, syntax high­lighting, folding, and a GUI.⁸

Like vi, vim sup­ports mul­tiple editing modes. De­pending on the mode, typed char­ac­ters are in­ter­preted ei­ther as se­quences of com­mands or are in­serted as text. In Vim there are 14 editing modes, 7 basic modes and 7 vari­ants

Normal mode gives you nav­i­ga­tional ac­cess to the working doc­u­ment— or "buffer" in Vim-lingo. In­sert mode lets you type like you would in common GUI text ed­i­tors (think Google Docs, MS Word, or Notepad). Com­mand mode lets you run reg­ular ex­pres­sions, shell com­mands, or Vim-spe­cific com­mands. Vi­sual mode is a vi­sual se­lec­tion mode— sim­ilar to high­lighting text on a GUI but giving you the ability to also se­lect ver­tical columns. To be honest, I rarely use the other 10 modes.⁹

Vi (and by ex­ten­sion Vim) tends to allow a typist to keep their fin­gers on the home row, which can be an ad­van­tage for a touch typist.

It's in­ter­esting to note that vi was mainly im­ple­mented on an ADM-3A . This ter­minal didn't have ded­i­cated arrow keys. In­stead, it used the h j k l keys for nav­i­ga­tion (left, down, up, right, re­spec­tively).¹⁰

A common al­lure of Vi/​Vim/​Neovim is the ability to seam­lessly nav­i­gate without a mouse— and without having to reach out for the arrow keys. In the light­hearted cul­ture-war be­tween Vi and Emacs users, a common theme is that Emacs users suffer from carpal tunnel be­cause of all the mod­i­fier key com­bi­na­tions they're forced to use to com­plete var­ious editing ac­tions. Vi's multi-modal switching does allow for rel­a­tively straight­for­ward short­cuts— pro­viding com­pletely dif­ferent ef­fects de­pending on its ac­tive mode.

Bram's Death

Vim is eter­nally teth­ered to its cre­ator, Bram. Bram was the benev­o­lent dic­tator of all things Vim. He had a rep­u­ta­tion for not al­lowing many re­quested changes to be merged into the repo— which can some­times be a sign of thoughtful code man­age­ment. Though, it was this strin­gency (as well as a gen­eral dis­like for Vim­Script— the Vim scripting lan­guage) which ul­ti­mately in­cited the cre­ation of Neovim.

Bram was also a phil­an­thropist. He es­tab­lished Vim with a char­i­ty­ware li­cense— ded­i­cating it to or­phans of AIDS in Uganda through ICCF Hol­land (which he founded and served on as trea­surer). A re­port, shared by Bram in 2020, showed that be­tween 2011-2019 Vim had an­nu­ally made over €50k. In 2019, it had made nearly €80k for the charity!¹¹

It was deeply sad­dening to many pro­gram­mers when news of Bram's passing spread in Au­gust of 2023. The new Vim main­tainer, Chris­tian Bra­bandt, has written about his ex­pe­ri­ence with Vim after Bram — and of the lo­gis­tics of taking over the code.

As of writing, the Hacker News ar­ticle of Bram's passing ranked #7 in all-time up­votes. The top-ranking all-time post is an obit­uary for Stephen Hawking, and #6 is for Steve Jobs. I don't mean to be in­sen­si­tive by using a so­cial media metric to com­pare peo­ples' worth— but Bram (and Vim) clearly stands among gi­ants in the hearts and minds of the tech com­mu­nity at large.

The Legacy of Text Editing

Though I at­tempted to pro­vide a de­tailed his­tory of Unix text editing— this is re­ally the tip of the ice­berg. In the early days of com­puting, there was an en­tan­gle­ment of a di­verse number of tal­ented com­puter sci­en­tists, main­frame ma­chines, and by­gone ter­mi­nals.

I hope readers will spend some time ex­ploring the re­sources that I've col­lected and can cor­rect any mis­takes I might have made during my re­search.

Hon­or­able Men­tions

These are other no­table text ed­i­tors that were de­vel­oped in tandem with the time­line as those which were dis­cussed in the above ar­ticle. They might not have had the same bearing on the Neovim lin­eage— but in­ter­esting to read about nonethe­less.

• Nano
• Pico
• Sam
• TECO

Other Modern Ed­i­tors

Kak­oune

Kak­oune is a code ed­itor that im­ple­ments Vi’s "key­strokes as a text editing lan­guage" model. As it is also a modal ed­itor, it is some­what sim­ilar to the Vim ed­itor (after which Kak­oune was orig­i­nally in­spired).

Helix

By starting from scratch we were able to learn from our ex­pe­ri­ence with Vim and make some breaking changes. The re­sult is a much smaller code­base and a modern set of de­faults. It's easier to get started if you've never used a modal ed­itor be­fore, and there's much less fid­dling with config files.