vi vs. emacs? vi, of course!

Well, I might as well go ahead and join the Great Unix Editor Wars, vi vs. emacs? vi, of course!

Unix has a very fundamental philosophy: a tool should do one thing and do it well. So we have great utilities like grep. What does grep do? It searches using regular expressions. That’s it. Fat lot of good that does you, right? Wrong. grep is a massively useful tool, precisely because it does that one thing and does it well. Because it doesn’t overextend itself and instead focuses on one excellence, it’s a superb tool for its purpose. Furthermore, because it follows one of the other fundamental Unix rules—it deals in plain text input and output streams, not fancy proprietary binary formats—it can be easily combined with other tools to create incredible flexibility and power.

As an aside, the following examples will repeatedly win the "Useless Use of cat" award; they are useful primarily for exemplary purposes, with cat used purely to add an extra command to the mix without changing our output.

So, for example, let’s say I’ve got an enormous text file I downloaded from Project Gutenberg. Chesterton’s What’s Wrong with the World will be an excellent example. I’m writing an English paper on Chesterton’s allegorical treatment of capitalism and socialism, and I consequently want to learn how many times Chesterton uses the words “Hudge” and “Gudge.” (If you’ve read it, you’ll understand.) So I take the text file and I print it to my screen:

$> cat whatswrong.txt 

I then get an enormous blob of text splattered on my screen as the whole file prints itself, then I’m returned to my command prompt. Not particularly helpful. So what do I do? I can open it in My Favorite Word Processor, hit CTRL-F, and then count the instances as I go through the text. But what if I lose count? (Quite likely, particularly if you’re interrupted.) This could also be very time-consuming, if the number of occurrences is large. So I pipe the text of the file into “grep”:

$> cat whatswrong.txt | grep Hudge

I now get not the whole file, but every line that includes the word “Hudge” in it. This is great, of course, but that could still be a lot of lines. So I just pipe the results into another program, one which does just one thing and does it well: counts things:

$> cat whatswrong.txt | grep Hudge | wc -l

Now I know, in one fell swoop, how many lines in the book contain the word “Hudge.” (It’s 25, by the way. 24 for “Gudge.”) This will be a very close approximation of how many times “Hudge” appears in the text. (Again, "useless use of cat" here (grep Hudge whatswrong.txt | wc -l, or even just grep -c Hudge whatswrong.txt would have been more direct), but this works and it helps for illustrative purposes.)

That’s the Unix way: small tools which are well-focused for particular jobs. And it works; indeed, it works better than anything else that anybody’s ever tried. This is How Computers Are Supposed to Work; even if you disagree, however, it’s how Unix works, and since Unix is our chosen system (most of us, anyway, if you’re in this debate at all), we ought to keep it in mind.

vi works exactly in this way. vi does just one thing: edit text. And it does it well. Editing text is a complex process, and consequently it’s a complex program; it offers myriads of ways of moving around in the file, changing blocks of text of various sizes, and so on. But that’s really all it does: edit text. It doesn’t check your spelling, it doesn’t check your email, it doesn’t read Usenet, and it doesn’t serve as a file manager. It just edits text. Period. And it does a phenomenal job of providing an incredibly powerful tool with very little processing or memory overhead.

emacs, on the other hand, is the exact opposite. It was written by Richard Stallman, which ought to tell us something. Richard Stallman, though I disagree with him fundamentally in many ways, is an admirable man in his strong commitment to software freedom and common goods; however, he’s not fundamentally a Unix man. Unix arose on limited-resource machines, thus producing this marvelously austere paradigm briefly explored above. Stallman, on the other hand, flourished in one of the richest computing environments on the planet in the 1970s, the MIT Artificial Intelligence Labs. They had powerful computers with (for that time) lots of resources. And emacs was originally coded for this environment, for a non-Unix operating system---and it shows.

emacs does everything. Seriously, everything. Critics have often remarked that emacs is a great operating system, it’s just a shame that it doesn’t have a decent text editor---and they’re only mostly joking. emacs will do all the things that I mentioned above that vi does not do, and much more. It’s even got its own built-in programming language, a species of Lisp, which is to emacs almost as C is to Unix (emacs itself is coded in C, not Lisp, which makes the difference). As such, it doesn’t do just one thing and do it well; it does lots of things---and arguably doesn’t do any of them particularly efficiently.

Compared to vi, emacs is incomprehensibly bloated. It’s enormous; one of the many jokes about emacs is that it stands for “Eight Megabytes and Constantly Swapping.” (Understand that eight megabytes was an obscene amount of memory in those days.) It provides its huge amounts of functionality at the expense of comparatively large overhead. This is another reason many vi users dislike it.

So where vi keeps itself busy editing text, allowing other programs to do the rest of the work, emacs does it all itself. So, for example, I tell my mail user client, mutt, that I want to write an email. It calls on vi for me, which is a text editor. I then edit my text, save it, and vi turns the text back over to mutt. mutt then asks me what to do with it; I tell mutt to send the email. mutt then tells msmtp that it has an email to send; msmtp takes the email from mutt and sends it. A long chain of small tools, each of which does just one single job and does it well, each limited in scope, small and focused. If I were an emacs user, though, emacs could do all of that for me, without ever calling on another program. While it was at it, it could make a sandwich, knit me a sweater, and probably program a simple S-orbit for a moonbound spacecraft on its own. Actually, emacs can probably write that email for you without any intervention; you might as well just step back, have a drink, and let emacs do its thing.

emacs’s control paradigm is incredibly irritating; the digital gymnastics required to do comparatively simple things are absurd. For example, to open a new file, in vi one types ":e filename". In emacs, one must hit "CTRL-x CTRL-f", then type the file name. ":w" saves in vi; in emacs one must "CTRL-x CTRL-s". (Also, incidentally, the delete key counterintuitively deletes the previous character, rather than the current character as in every other editor on the planet.) Undo is no longer a simple "u", but "CTRL-x u". Most vi commands don't require the fingers to leave the home row, and are largely single or double keystrokes; emacs, though, requires one to dislocate at least two joints to do anything serious.

(On that note, my favorite emacs pseudo-acronym is “Escape Meta Alt Control Shift.”)

vi’s single-letter, command-mode model is far superior, in my opinion. But I could deal with an editor that requires all ten fingers plus my nose and a couple of toes just to write the working buffer. What I can’t deal with is a program that tries to be all things to all men. It can’t, and won’t, work. It is not the Unix way.

So while emacs is a better operating system than vi, that’s because vi doesn’t propose itself as an operating system. It’s just a text editor---and that’s its strength, not its weakness.

Praise be to Christ the King!

P.S. The emacs people who complain about vi being a "moded" editor are particularly myopic. See, emacs is a moded editor, too; it's just that entering command mode isn't "ESC", it's "CTRL-x", and you're only in command mode until you finish one command. In vi, command mode lasts until you decide to leave it, allowing you to do lots of heavy editing without having to constantly enter command mode (with two keystrokes each time!) and leave it again.