Vim must die and Emacs must not take its place

July 2018

My preferred text editor is Sublime. Atom is pretty good too, and I hear good things about VS Code. They’re all proper, modern applications with tabs, menus, and so forth. They’re powerful but accessible, making the common things easy and the rare things possible, like all good software should.

Sometimes, though, I have to SSH into a remote machine and quickly edit the crontab file. Or I have to plug a keyboard and screen into a Raspberry Pi and edit the Wifi settings file. Or I make a Git commit and have to enter a commit messge. And in those cases, I need a terminal-based text editor. And they’re all awful.

It’s easy to see how that works with a physical object: I know I can pour tea into a mug and hold the handle because it’s container-shaped, with a reverse-hand-shaped handle, and it’s clearly made from heat-resistant material. But with software? Turns out it’s much the same. Some applications are skeuomorphic, meaning they resemble physical objects, such as how the tabs in Sublime Text mirror the tabs in a physical filing cabinet or ringbinder; other apps mimic apps users are already familiar with, such as Sublime’s directory tree sidebar which we recognise from whatever file browser our OS ships with; and sometimes people manage to make functionality just feel obvious and natural, say by having something cut off, partway though, at the bottom of the screen — you don’t need a scrollbar to know there’s more to come.

The first terminal-based text editor I ever used was Nano. It’s OK, but it’s not very powerful. It’s fine for quickly bashing out a Git commit message, but pretty rubbish for anything more than that. It does, however, show you all the available commands in a persistent footer. It’s very much the ‘writing instructions for a door’ school of signifier, but it’s a start.

Nano makes the common things easy and leaves the rare things as an exercise for the reader.

Eventually, I needed to go straight to line 274, or delete a whole file and paste in something else. Nano won’t do that. Nano is your entry level editor, built on simplicity. No, if you want power, you need Vim.

A screengrab of what Vim is pleased to call its user interface. Vim makes the rare things just about possible and the common things exactly as possible.

Vim’s UI is a bit more bare-bones, but that’s OK, right? You only really want to see the file you’re editing. Anything else is just visual clutter. You just want the absolute essentials on-screen: the content, and apparently the total numbers of characters in the file for some reason. You know, because apparently it’s still 1976 and we can only fit so much on the screen at once.

This should not be a hard thing to get right. We all know what a good text editor looks like because we have Sublime and Atom — and even Notepad and gedit. There are established UI patterns for this. To move the cursor, click where you want the cursor to be, or use the arrow keys to move it. To insert text, just type it. To select, either drag with the mouse or hold shift and move the cursor as before. Cut, copy and paste are control- (or command-) X, C and V respectively, or they’re on the ‘Edit’ menu if you don’t know that. Menus are accessed with the mouse or using shortcuts bound to the ‘alt’ key. We all know all that, which is why all GUI-based text editors stick to these conventions like a forgotten Chewit to the inside of a jeans back pocket. Anything else feels — and arguably is — broken.

Terminal editors do not follow these conventions. They have no skeuomorphs and their idiosyncratic rules can’t be guessed without reading a manual.

In Vim, the copy command is named ‘yank’ and mapped to Y. In Emacs, it’s called ‘Kill Ring Save’ and mapped to control-W, while paste, somewhat incredibly, is named ‘yank’ and mapped to control-Y. In Nano, cut and ‘uncut’ are on control-K and -U, which suddenly looks comparatively merciful. This Stack Overflow question asking simply “how do I quit Vim” has 1.5 million views, 671 stars and 2,600 upvotes. The accepted answer, with 3,600 upvotes, offers ten different escape routes for the trapped user. Typing isn’t easier — you have to move the cursor around by typing numbers into an invisible buffer then pressing one of the direction keys which are H, J, K and L (in some order, who even knows), then press I or A to enter one of the two presumably different ‘actually typing things in’ modes. To be clear: Vim is a text editor that launches into a mode where you can’t type anything, and has the sheer balls-out audacity to call this mode ‘Normal’. Here are just some of the more common commands Vim expects you to memorise. This is a control system that was annoying when Street Fighter II did it.

They are nasty, Norman-door software that has no place in a modern OS. Do not tell me “you have to learn a text editor”. Nobody should have to learn a text editor any more than they have to learn lightswitches.

At this stage there are a lot of Linux users desperately scrolling to find the comments section, to tell me that I “can’t reasonably expect mouse input” in the terminal or that menus and toolbars “can’t exist in the terminal” or that “most stuff requires” “you to read the manual”. (Honestly, what was the last app you lauched that came with a manual?) To those people I present the greatest terminal-based text editor ever written:

Let me be absolutely clear on this point. I am unironically and non-sarcastically claiming that, while flawed, basic and limited, the QuickBASIC editor released by Microsoft, on MS-DOS, in 1988 is by any reasonable metric a superior software package to the versions of Vim or Emacs released 30 years later.

Microsoft’s QuickBASIC editor, released in 1988, running in DOSBox. It went on to become QBasic and then DOS' trusty edit command.

It has it all: mouse-based menu navigation with alt-key shortcuts, mouse-based cursor movement and selection, arrow navigation, standard clipboard shortcuts, you name it.

It even has a GUI for find and replace. Vim handles this by expecting the user to type out regex patterns, although in a 'grateful for small mercies' way, the text box you type them into does at least exist on the screen.

So how is it possible that Linux doesn’t have anything like this?

Honestly, I think the issue is just that Linux users don’t want it. There is a certain class of person who would rather spend two hours reading documentation than two seconds using a mouse. (They seldom write any documentation.) Real Developers™ do not use the mouse. They like IRC and illegible dark themes, black PCs full of coloured lights, inscrutible command-line apps and unreadably long lines of tiny text because surely more text is better, and if any of that makes Linux less usable then so much the better — the last thing they need is a bunch of n00bs showing up expecting to be able to check their email without even generating an SSH keypair or customising their .bash_profiles.

In short: this kind of person does not want easy-to-use software, because then how would they tell the Real Developers™ from, say, women?

Using regular expressions as your find-and-replace syntax makes sense as an option for power users, or as a quick hack for version 1, but Vi has been in continuous development for 42 years and still hasn’t got a find and replace syntax that 191,000 people aren’t confused by. At that point one is forced to suspect that casual users don’t find themselves stuck in an unquittable text editor by mistake. That perhaps Vim is a trap, laid throughout Linux for them to fall into, where they will languish, feeling increasingly stupid for not being able to program their way out of what they suppose must be a text editor, until they boot back into Windows and stay there forever.

And whether that’s true or not, the effect is the same: as far as the average person is concerned, Vim is less a text editor than a gatekeeper. Does anyone honestly believe the time they save not having to press control in Vim adds up to anything like as long as it took them to learn Vim? Bollocks is it about saving time, it’s about proving your hacker creds.

Now I will grant you that many of the conventions we take for granted in modern editors did not exist in 1976, and Vim is to some extent simply a continuation of the philosophy set out before anyone knew better. But that’s not an excuse when it’s the default editor in your Linux distribution in 2018.

QuickBASIC’s editor is not perfect. How could it be, it’s 30 years old. (By contrast, the latest versions of Vim and Emacs were released in May.)

This is my quick-and-dirty concept for what I think a terminal-based text editor should look like in 2018 — at least, at this window size. Make it wider and you might get a sidebar. Narrower and the menu will vanish leaving only the search. Shorter and the toolbar and statusbar can be jettisonned; taller and perhaps it can grow an Office-style ribbon control.

This is a genuine screengrab from an Ubuntu terminal window. Nothing here is beyond what a terminal app can do.

Even this is a little unimaginative — ‘new’ and ‘open’ are useful in a GUI but probably less so in the terminal. ‘Save with sudo’ would be more useful, though perhaps not something that should be on a toolbar. This is the sort of thing that will likely become apparent after version 1 is in active use.

But that, roughtly, is what a good text-editor looks like. You know that because you use them already. The terminal is not a foreign country and we should not do things differenty there. DOS knew that, which is why Windows exists and ultimately why Linux is still a sideshow on desktop. Vim is a bad habit, and it shouldn’t be regular users Googling “how do I quit vim”; it should be the addicts who won’t respect you unless you can speed-run through software like it’s Sonic the Hedgehog.

And yes, you can usually muddle through in Vim or Nano, or use sshfs to mount the remote folder and edit the files in Atom, but software is write once run many times — the time it would take us to write my fantasy terminal editor is surely orders of magnitude less time than people will instead waste learning Vim’s nonsense, and if we honestly care about making great software then the main thing we need is accessible tools — we can’t expect the best product without the maximum possible number of brains working on it, and that emphatically must include people who think Vim and Emacs are bullshit. Because those people probably know how to design friendly software.

Perhaps after all this there will always a place for Vim and Emacs. It’s good to have options, after all. Nano will always be handy for those days when you have seven bytes of memory and just need to bash out a line of crontab, and maybe Vim should stick around for those days when you really need to zip through files at the speed of thought. Perhaps there is a baby in all this bathwater somewhere.

But I doubt it. Because the speed of thought is a much smaller quantity than people imagine. There is very little that can be done in a text editor and ought be rushed. Both writers and developers might do well to slow down occasionally and give themselves time to think. And we’re in a real pickle if Linux’s preoccupation with saving experienced users every halfway-redundant keystroke is both the cause and result of thoughtlessness.