Recently, I was editing some Perl on a Windows box for Nyder, and ran into some irritating line ending issues. Since the office had broadband, I started downloading text editors, because Notepad was really starting to annoy me. She seemed rather taken with XEmacs, and so to prevent my friend's imminent consumption by the Dark Side, I've decided to finally set down a few things I've been thinking about vi and Emacs, and why techies get so het up about the issue of text editors.
That question at least is easy to answer: virtually everything geeks do with a computer comes down to bashing about files full of plain text at some point - coding, writing email, editing configuration files, writing pointless screeds like this - and so we spend a huge amount of our computer time (and thus a huge amount of our waking lives) using text editors. We invest a lot of time learning to use our tools efficiently, and getting to know their idiosyncrasies, which after a while start to take on great significance. So it's hardly surprising that we get attached to them. I believe chefs form similar attachments to knives, and if you remember that geeks and chefs are both groups of very busy, highly stressed creative people, it's not so surprising that they behave in similar ways.
Now, on to the next few questions: what is vi, what is Emacs, what are the differences between the two, and, assuming you want to learn one, which one should you learn?
vi and Emacs are the two most powerful programs in the world for editing plain text files, which as I've previously mentioned encompasses 80% of what hackers want to do with computers. You may think that this is a pretty simple task, but that's because you've only used bad text editors like notepad, and you don't know how much more pleasant a good text editor can make your life. At this stage Emacs users are probably already screaming at my reducing Emacs to a mere text editor: don't worry, I'll get to that. vi and Emacs have both been ported to every operating system in existence, but they're usually encountered on Unix-like systems like Linux and FreeBSD, so they're often thought of as Unix programs. In fact, only vi is native to Unix: Emacs comes out of a very different engineering tradition, and this explains a lot about it.
vi is the younger of the two by a few months: it dates from a 1975 release of the Berkeley Standard Distribution of Unix, and was the first screen-oriented editor for Unix, which is to say that it took advantage of the new video terminals by showing you a portion of your document as you edited it, and not requiring you to edit essentially blind. vi was built on top of a line-oriented editor called ed, and inherited a lot of its command syntax from it: more importantly, it was designed to work under the restrictions imposed by early Unix versions. Early versions of Unix couldn't cope with programs over 64K in size, and since users usually dialled in to the computer, it was essential that the program could work over a 3600 baud modem (approximately 24 times slower than the slowest modem you can get today). However, it was no problem to start a lot of different programs at once, as long as each one was below the 64K limit, and several brilliantly simple ploys were invented to let programs talk to each other. Hence, each program was written to do exactly one thing, but to do it really well. My favourite example of this is the "cal" command, which displays a calendar of the form
However, such care has been taken with this that it includes the ten-day discontinuity in September 1752 when the Gregorian calendar was adopted. The manual used to have in its list of "known bugs" the sentence "The program assumes that the year always begins in January, which is historically naive".December 2002
Su Mo Tu We Th Fr Sa
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31
As Steve Bourne notes in his book The Unix System, "This has had a generally positive effect on software": it was found that by making programs small and isolated it was possible to achieve great reliability. If a program dies, the operating system kills it quietly and every other program gets on with its own small task (the fact that programs were small and easily-understood meant that each program was more reliable, too). Since it was developed under these conditions, vi does not attempt to be a mailreader, or a debugger, or an adventure game, or a version control system, or a Rogerian psychotherapist. If you have a program to do one of these things and it needs you to edit some text, it can call vi for you, and when you're finished editing text vi closes and returns the result to the other program. For instance, I use the mailreader Mutt, and if I want to compose an email, I press the "m" key and Mutt opens a new vi instance for me, with settings appropriate for editing email. Though vi implementations long ago exceeded 64K (the one I use, vim, is about 2MB), it's small and quick enough for this to be feasible. Equally, if you have a program that (say) performs spell-checking or indents C code nicely, you can call that from within vi without the need to re-write it as a part of the editor. That way the program can be used both interactively and non-interactively.
vi was written by and for touch-typists for whom RSI is a given, and so commands are extremely terse. It was also written before the advent of mice, so everything can be done via the keyboard. This is a Good Thing. The editor commands themselves also reflect the Unix philosophy - each command is pretty simple, but they can be combined in straightforward ways to produce some powerful effects. For instance, there's a command "Move the cursor to the next occurrence of the character x" (which in true vi fashion is just fx), and to delete between the current position and the next x you type dfx. To copy the text between the cursor and the next x, you type yfx. (To delete until the third occurrence of x, type d3fx). Emacs has an equivalent to dfx, but none of the others, because its commands aren't designed to be composed in this way - which I think makes it much more ad-hoc and confusing.
You may be thinking "If typing 'dfx' deletes until the next x, how do I insert the string 'dfx' into my text file?" The answer is that vi is a moded editor: at any time, you're either in insert mode (and any text you type goes into the current buffer), or in command mode. This means your commands can be a lot terser, and it makes sense if you tend to do long blocks of typing followed by long blocks of bashing text around. It's an idea which people tend to react strongly to - I thought "What a fantastic idea!" and fell in love with vi on the spot, but a lot of people think it's a crazy idea, and many of them are forever lost to the False Editor.
Emacs, as I've mentioned, comes out of a different tradition - that of the MIT AI lab, where the Knights of the Lambda Calculus did battle with mighty problems, and where the First Hackers created the legendary ITS. There's a certain amount of mysticism about those days, mainly spread by the people who were there. Anyway, we should be grateful to them, because one of them (Richard Stallman) started the Free Software movement, which gave us the GNU tools, and thence Linux and much of the lovely open-source software we enjoy today.
Not entirely coincidentally, Richard Stallman (hereinafter RMS) was also the author of the original Emacs, and the history of Emacs is basically the history of one group of Emacs hackers after another falling out with RMS and leaving to do their own thing - XEmacs is just the most recent and most successful of these "forked" versions. But I digress. Whereas the Unix authors at Bell Labs attempted to solve problems by cutting them up into the smallest bits possible, the first instinct of the hackers at MIT was to generalise problems as much as possible, solve the new problem in total generality, and if possible to do so using Lisp. Hence, Emacs - a text editor with an entire programming language hidden inside it. In fact, that's putting the cart before the horse somewhat - Emacs can be better understood as a Lisp interpreter with a few extra commands that are useful for implementing text editors.
Emacs is vast - about 100MB for a full download of XEmacs, and that's not including most of the source code (the executable alone is about 9MB). Unlike vi, Emacs is a debugger, an adventure game, a calendar, a mailreader, a web browser, a calculator, a psychotherapist and a tool for inserting random seditious phrases like "kill the president" into outgoing mail to annoy the NSA. It has its own screensavers, for goodness' sake (see M-x zone if you don't believe me).
The advantage of building an editor this way is that your users can extend it to handle whatever their specific needs and tastes happen to be - for example, there are Emacs modes to make editing of various programming languages easier by binding keys to "move to next function" and so on - modern versions of vi have similar features, but they're much less intelligent and rely on fairly shallow parsing of the text. The disadvantage of building an editor this way is that it soon becomes a vast unknowable mass of thousands of different features built up over years by hundreds of different contributors, and finding the feature you need (or even discovering that it exists) becomes a massively hard problem. And since there can be no standard keybindings, the user interface becomes a nightmare - the equivalent to vi's dfx is Alt-z x for "zap-to-char". There appears to be no equivalent of fx, but hey, you can write your own, right? "Move to next compilation error" is Ctrl-x `. I mean, what?
Naturally, Emacs has a help browser built in. Unfortunately, it sucks. There have been various attempts to start from scratch and do something cleaner this time around - Efuns (which uses the rather nifty-looking Objective Caml as its extension language) looks particularly interesting, but I haven't tried it.
The other problem with building your editor on top of Lisp is that Lisp is a very weird language and not many people speak it these days. This may change - Paul Graham has argued that as time goes on, all languages are evolving away from Fortran and towards Lisp (dynamic typing, garbage collection, first-class functions, etc). His book On Lisp and his pages on Lisp are highly recommended if you want to know more.
I said I was going to try to be balanced, and I haven't done a very good job so far. So, here are some really cool features of Emacs that can't be easily duplicated with vi and a shell prompt: