Modal editing is a weird historical contingency we have through sheer happenstance
If vi didn't exist, it would not have been invented.
A while back my friend Pablo Meier was reviewing some 2024 videogames and wrote this:
I feel like some artists, if they didn't exist, would have the resulting void filled in by someone similar (e.g. if Katy Perry didn't exist, someone like her would have). But others don't have successful imitators or comparisons (thinking Jackie Chan, or Weird Al): they are irreplaceable.
He was using it to describe auteurs but I see this as a property of opportunity, in that "replaceable" artists are those who work in bigger markets. Katy Perry's market is large, visible and obviously (but not easily) exploitable, so there are a lot of people who'd compete in her niche. Weird Al's market is unclear: while there were successful parody songs in the past, it wasn't clear there was enough opportunity there to support a superstar.
I think that modal editing is in the latter category. Vim is now very popular and has spawned numerous successors. But its key feature, modes, is not obviously-beneficial, to the point that if Bill Joy didn't make vi (vim's direct predecessor) fifty years ago I don't think we'd have any modal editors today.
A quick overview of "modal editing"
In a non-modal editor, pressing the "u" key adds a "u" to your text, as you'd expect. In a modal editor, pressing "u" does something different depending on the "mode" you are in. In Vim's default "normal" mode, "u" undoes the last change to the text, while in the "visual" mode it lowercases all selected text. It only inserts the character in "insert" mode. All other keys, as well as chorded shortcuts (ctrl-x), work the same way.
The clearest benefit to this is you can densely pack the keyboard with advanced commands. The standard US keyboard has 48ish keys dedicated to inserting characters. With the ctrl and shift modifiers that becomes at least ~150 extra shortcuts for each other mode. This is also what IMO "spiritually" distinguishes modal editing from contextual shortcuts. Even if a unimodal editor lets you change a keyboard shortcut's behavior based on languages or focused panel, without global user-controlled modes it simply can't achieve that density of shortcuts.
Now while modal editing today is widely beloved (the Vim plugin for VSCode has at least eight million downloads), I suspect it was "carried" by the popularity of vi, as opposed to driving vi's popularity.
Modal editing is an unusual idea
Pre-vi editors weren't modal. Some, like EDT/KED, used chorded commands, while others like ed or TECO basically REPLs for text-editing DSLs. Both of these ideas widely reappear in modern editors.
As far as I can tell, the first modal editor was Butler Lampson's Bravo in 1974. Bill Joy admits he used it for inspiration:
A lot of the ideas for the screen editing mode were stolen from a Bravo manual I surreptitiously looked at and copied. Dot is really the double-escape from Bravo, the redo command. Most of the stuff was stolen.
Bill Joy probably took the idea because he was working on dumb terminals that were slow to register keystrokes, which put pressure to minimize the number needed for complex operations.
Why did Bravo have modal editing? Looking at the Alto handbook, I get the impression that Xerox was trying to figure out the best mouse and GUI workflows. Bravo was an experiment with modes, one hand on the mouse and one issuing commands on the keyboard. Other experiments included context menus (the Markup program) and toolbars (Draw).
Xerox very quickly decided against modes, as the successors Gypsy and BravoX were modeless. Commands originally assigned to English letters were moved to graphical menus, special keys, and chords.
It seems to me that modes started as an unsuccessful experiment deal with a specific constraint and then later successfully adopted to deal with a different constraint. It was a specialized feature as opposed to a generally useful feature like chords.
Modal editing didn't popularize vi
While vi was popular at Bill Joy's coworkers, he doesn't attribute its success to its features:
I think the wonderful thing about vi is that it has such a good market share because we gave it away. Everybody has it now. So it actually had a chance to become part of what is perceived as basic UNIX. EMACS is a nice editor too, but because it costs hundreds of dollars, there will always be people who won't buy it.
Vi was distributed for free with the popular BSD Unix and was standardized in POSIX Issue 2, meaning all Unix OSes had to have vi. That arguably is what made it popular, and why so many people ended up learning a modal editor.
Modal editing doesn't really spread outside of vim
I think by the 90s, people started believing that modal editing was a Good Idea, if not an obvious one. That's why we see direct descendants of vi, most famously vim. It's also why extensible editors like Emacs and VSCode have vim-mode extensions, but these are but these are always simple emulation layers on top of a unimodal baselines. This was good for getting people used to the vim keybindings (I learned on Kile) but it means people weren't really doing anything with modal editing. It was always "The Vim Gimmick".
Modes also didn't take off anywhere else. There's no modal word processor, spreadsheet editor, or email client.1 Visidata is an extremely cool modal data exploration tool but it's pretty niche. Firefox used to have vimperator (which was inspired by Vim) but that's defunct now. Modal software means modal editing which means vi.
This has been changing a little, though! Nowadays we do see new modal text editors, like kakoune and Helix, that don't just try to emulate vi but do entirely new things. These were made, though, in response to perceived shortcomings in vi's editing model. I think they are still classifiable as descendants. If vi never existed, would the developers of kak and helix have still made modal editors, or would they have explored different ideas?
People aren't clamouring for more experiments
Not too related to the overall picture, but a gripe of mine. Vi and vim have a set of hardcoded modes, and adding an entirely new mode is impossible. Like if a plugin (like vim's default netrw) adds a file explorer it should be able to add a filesystem mode, right? But it can't, so instead it waits for you to open the filesystem and then adds 60 new mappings to normal mode. There's no way to properly add a "filesystem" mode, a "diff" mode, a "git" mode, etc, so plugin developers have to mimic them.
I don't think people see this as a problem, though! Neovim, which aims to fix all of the baggage in vim's legacy, didn't consider creating modes an important feature. Kak and Helix, which reimagine modal editing from from the ground up, don't support creating modes either.2 People aren't clamouring for new modes!
Modes are a niche power user feature
So far I've been trying to show that vi is, in Pablo's words, "irreplaceable". Editors weren't doing modal editing before Bravo, and even after vi became incredibly popular, unrelated editors did not adapt modal editing. At most, they got a vi emulation layer. Kak and helix complicate this story but I don't think they refute it; they appear much later and arguably count as descendants (so are related).
I think the best explanation is that in a vacuum modal editing sounds like a bad idea. The mode is global state that users always have to know, which makes it dangerous. To use new modes well you have to memorize all of the keybindings, which makes it difficult. Modal editing has a brutal skill floor before it becomes more efficient than a unimodal, chorded editor like VSCode.
That's why it originally appears in very specific circumstances, as early experiments in mouse UX and as a way of dealing with modem latencies. The fact we have vim today is a historical accident.
And I'm glad for it! You can pry Neovim from my cold dead hands, you monsters.
P99 talk this Thursday!
My talk, "Designing Low-Latency Systems with TLA+", is happening 10/23 at 11:40 central time. Tickets are free, the conf is online, and the talk's only 16 minutes, so come check it out!
-
I guess if you squint gmail kinda counts but it's basically an antifeature ↩
-
It looks like Helix supports creating minor modes, but these are only active for one keystroke, making them akin to a better, more ergonomic version of vim multikey mappings. ↩
If you're reading this on the web, you can subscribe here. Updates are once a week. My main website is here.
My new book, Logic for Programmers, is now in early access! Get it here.
As someone who used TECO, ed, and vi, I think moral editing was a logical outgrowth of being an extension of ex, which was an extension of ed. I don’t disagree with your assessment of TECO as aDSL for text (old puzzle: what would TECO do if you typed in your name, or for that matter, EMACS began its life as a set of TECO macros).
You know the Charles Simonyi story about Bravo, I assume? To invoke it, you typed “edit” to the command line. One day, he’d forgotten that he had already started the editor, and he typed “edit”, which the editor interpreted as “Everything Delete, Insert ‘t’”. When he left for Microsoft he declared that no editor (e.g., the first version of Word) would have modes.
I don’t remember if Wordperfect has modes, or not.
Also, Emacs has modes which change the keyboard mapping for the kind of editing you’re doing (text, source code (language specific modes, at that), shell commands, debugger commands, etc).
Someday I will dig up and finish my modal window manager project.
I want something keyboard-driven, but with existing WMs (i3, bspwm, etc) I've never been able to get a set of shortcuts I'm happy with. They always seem to require too much awkward finger gymnastics, pressing lots of modifier keys at once. It's uncomfortable for my small hands. A modal system seems like it could have better ergonomics.
It's languishing in my todo pile because I just can't get my head around X11 or Wayland's APIs. Maybe I should give it another go with Claude to help me ...
While I agree with some of this, I also think it misses something. Namely, you imply that modal editing isn't an "interesting" feature on its own, and is only beloved because of vim. An example is the "vim plugins" in many editors.
But I think that proves the opposite point! I used and loved vim for many years, for a number of reasons, but at the end, for me, the modal editing was the killer feature. But it's a portable feature - because of all the vim plugins! So once I was able to get the same thing in a better overall editor, I moved over.
It wasn't vim being so awesome that got me to like modal editing - it was modal editing that got me to put up with vim being not awesome, until I was able to get my modal editing fix elsewhere.
(I exaggerate a bit for effect, though this is mostly true; vim does have a few other cool things like broad availability and wonderful customizability, which I utilized a lot over the years, but after many years, I realized I prefer the same modal editing core in a better overall package.)
I hope I didn't unintentionally convey that modal editing isn't "interesting"! Rather, I think it's "nonobvious", and needed historical contingency to get its foot in the door. Then the question becomes "once it was known and valued, how come people didn't iterate on it in the same way they did chords or editing DSLs or other features?"
Have you looked at Helix at all? I think it has an essentially better editing paradigm than vim does, but I stick with Neovim because I really like writing my own plugins.