There they went, at it again. The president of our local Linux user's group sent out the word
that the week's tutorial would be canceled. That the tutorial was on using the vi text editor was enough to set off a fresh round of sniping.
Greg Menke fired the first salvo. Use vi? How hard could that be? He emailed his own steps for using vi. They were, as follows:
Procure fish, any kind, length > 12 inches
Freeze it overnight
Sit in front of PC, run vi
Holding fish by the tail, smash it repeatedly against your
forehead until you decide to give EMACS a try because the fish scales are
flying around your head and it's starting to ache.
Menke, of course, was implying that not only vi was insanely obstinate but
that vi users were obstinate as well for refusing to admit how they were
inflicting upon themselves frozen-fish-against-the-noggin levels of
It didn't take long for vi lovers return fire. One suggested Menke add this
line to his instructions: "Type 'emacs' before step 1, so that by the time
step 4 is done, it will have finally finished loading."
Now, was he trying to say the EMACS text editor was slow?
Like fight-fatigued battalions who come to a temporary
truce but refuse to give up the war, vi and EMACS users keep an uneasy
standoff in many Linux, SAGE and other computer-related virtual communities. It's the kind of standoff that may remain dormant for months, but it takes only the vaguest slight from one side for the flames to roil across the newsgroups and mailing lists once again. For just beneath their civil demeanors, each camp feels the editor they use is the best of all possible editors and those who use any other editor, particularly that other editor, are fools who would realize the error in their thinking if only pounded with enough mockery.
Now, a rift over which Unix text editor is God's Own Build may not seem
significant given all the troubles of the world, a Coke vs. Pepsi standoff
of no consequence, no motivator beyond simple group bonding ("Go Team!").
But why has this difference of views remained a divisor of programmer culture
for more than two decades now? Why has it remained intact as the PC,
graphical user interfaces, the mouse, the Internet and Open Source each
altered the computation landscape?
"As far back I can remember both, the hacker population has been split 50/50
[between] EMACS [and] vi," emails Eric Raymond, who counts as many of his
roles in the Open Source software and hacker communities as a long-time
observer/participant anthropologist. "Pico, joe, MicroEmacs, and other
editors have basically been down in the statistical noise during the whole
period." Raymond can personally date the vi/EMACS split back to 1985 and
stipulates that, in all likelihood, it went on long before that.
As early as 1991, Raymond recorded the vi vs. EMACS "holy war" in the
Jargon File, perhaps the
ultimate collection of hacker terminology.
When pressed, most people familiar with both editors will say the difference
between the two is one of speed vs. flexibility, with vi users pointing to how darn
quickly they can move around and EMACS lovers touting their immense number of options. Vi users deride EMACS for being unnecessarily ostentatious; EMACS users derided vi for being difficult to learn and limited in scope.
So the great text editor debate of our time comes down to the technical equivalent of "tastes great/less filling?" Well, yes, kind of. But like with all matters of religion -- or war -- the deeper you dig, the murkier the issues get.
But there is significance here. These editors are the tabula rasa
upon which much of cyberspace has been built. That these tools, each
designed to be transparent to the end user, are subject to such fierce and
competing loyalties, reveals something about some primordial assumptions
people have about the best ways of getting things done.
Vi: The editor that time forgot?
At first glance, outsiders might see vi as the editor that time forgot. It's
not just that you have to open up a terminal window just to use the
thing. That's the best way to get to EMACS, too. But even with the VIM, the
updated version most vi users employ these days, one can't help but to marvel
at (or become frustrated over) the sheer lack of intuitiveness of how it works.
Even the webmaster of the
VI Lovers Home Page admits that the learning curve is steep. "Vi
doesn't get fast before you know 25 commands or so," wrote Amsterdam native
Thomer Gil, now working on a computer science Ph.d. at the Massachusetts Institute of Technology.
Gil's been likened by his office-mates to a "caveman wielding ax and club"
for his use of VIM.
Of all vi's perceived shortcomings, perhaps the most noticeable is how you
need to toggle the insert key just to type anything onto the screen. Vi has
two modes: One is the "insert" mode where you can enter text. You get to that
mode by hitting the "insert" key on the keyboard. But there is also the
command mode where you can't enter text, but instead enter relevant commands.
From insert mode, you can get there by hitting the escape key.
So imagine the unsuspecting first-time user typing away who accidentally hits
the escape key, only to find that not only can he longer enter text, but his
keystrokes are sending the program in strange directions.
The Jargon File dryly notes
that this feature of vi "tends to frustrate new users no end, as it will
neither take commands while expecting input text nor vice versa, and the
default setup provides no indication of which mode the editor is in."
"Multiple modes freak people out," Gil admits.
Vi was written by Bill Joy in 1976, who forged it from two even more
primitive editing tools, ed and ex. Vi stood for "visual interface," which in 1976
was in quite the bleeding edge in computing, according to a Joy interview in Linux
"I was trying to make it usable over a 300-baud modem. That's also the
reason you have all these funny commands. It just barely worked to use a
screen editor over a modem, " Joy said "So the editor was optimized so that
you could edit and feel productive when it was painting slower than you could
In that interview, Joy contrasted the development environment of vi to that
of EMACS, which, he said was written for systems with blazing fiber-channel
links and monster PDP-10's.
"So they could have funny commands with the screen shimmering and all that,
and meanwhile, I'm sitting at home in sort of World War II surplus housing at
Berkeley with a modem and a terminal that can just barely get the cursor off
the bottom line," Joy said, perhaps sounding a bit envious. "People don't know that vi was written for a world that doesn't exist anymore."
Yet, while vi should have died out in the early '80s as network and
processor speed increased, instead, it has flourished. The VI Pages lists close to 30 vi
clones from elvis and VIM to such obscurities as WinVi and vigor.
Tim O'Reilly, mastermind behind the O'Reilly & Associates publishing company
noted on the company's Ask Tim column
that his company sells twice as many vi books than EMACS ones. Plus, whenever
O'Reilly sponsors a vi. vs. EMACS paintball game at some convention,
invariably twice as many volunteers sign up to defend the honor of vi than EMACS.
So what is the appeal? That's best described by the
Cult of VI
in which John Arundel writes, "Watching a vi guru doing some heavy editing on
a file, as her fingers fly over the keys and textual transformations sweep
across the screen, one could believe that one is in the presence of
Gil publishes a few examples of this wizardry on his Web site. "A key
concept in vi is combining a certain action (delete, copy to buffer,
capitalize, etc.) with a movement (go to line 25, go to end of document, go
to next occurrence of 'foo,' go to 2nd occurrence of character 'x' in
this line, etc.)."
"Huh?" I email him.
Gil sends back an example: "If, for example, a document contains the lines:
'a b c d e f g h' and the cursor is location on 'b,' then I can type
The first "d" means delete, the "/" is a search function, so what this
command will do is delete from b to f.
"No special circumstances
required to use this . . . Delete words, sentences. Go back to where I was
before. 'Oh no, jump back again. Undo what I did, redo it,' " Gil writes.
Gil stipulates you can do tricks like this one on EMACS, too. However, he says
it requires memorization of unwieldy "funky Ctrl-X Ctrl-c Alt-F4 key
combinations" to execute.
Another trick Gil reveals is how VI allows users move around in files. "The
stupid way is using arrow keys; there are many other, more advanced, ways to
move around," Gil writes. Among the advanced forms of carriage vi offers is
the option to jet to the last or last few cursor jumps, or to the next
occurrence of a particular word, or to the next sentence or paragraph.
Even the dual mode "feature" becomes transparent to users. About a year ago,
A while back I interviewed Jon Lasser to write about his then-recently published book Think Unix, (the
manuscript of which, he told me, was composed entirely in vi). The
conversation eventually came around to vi, and I complained about the two
Lasser explained that he saw no difference between working in vi and in word
processors like StarOffice or Microsoft Word. In Word, when you move your
pointer out of the screen area, you can't type in text. You have, in effect,
moved from insert mode to command mode. "It's the same thing," he
As O'Reilly wrote about vi: "Like a lot of things about UNIX, it only *seems*
More is more with EMACS?
When vi loyalist O'Reilly wrote in Ask Tim that he first shifted from
EMACS to vi only after his customized EMACS profile was trashed, it was one
of those subtle jabs vi users like to use against EMACS.
EMACS stands in sharp contrast to vi's pristine limitation of commands, with
its almost infinite customizability. Given human nature being what it is,
however, such power in the hands of users may not always be a best thing.
As the Emacs-Beginner-HOWTO
puts it, EMACS can be a text editor, mail client, news reader, word
processor, script editor, and integrated development environment for
The key to this is the multiple modes, each with a unique command set, that
EMACS offers. Want to check email? Just flip over to the email mode. Want
to writing a program in C++? Use the C++ mode. Need to author some Web pages?
Flip into the html-helper mode.
And on top of all this, you can also customize EMACS and even add new
functions, usually through modifying the Lisp code.
All of which many vi users see as terribly presumptuous for what is
supposed to be a simple text editor, not to mention distracting for the user.
The ongoing joke about EMACS is that it is an operating system with a text
"EMACS as such actually started out as a standards project," emails Guy
Steele, one of the originators of EMACS, along with Richard Stallman, who
later founded the Free Software Foundation.
The way Steele recalls, Stallman maintained an early editor for
PDP-10 called TECO, which stood for "Text Editor and COrrector."Although
certain keystrokes would perform editing commands, Stallman created a
user-programmable table "such that each keystroke
performed a lookup in the table describing what to do for that keystroke," according to Steele. "One option was to execute a user-specified TECO macro."
Using this macro functionality, users were programming custom sets of
macros to be attached to various keystrokes, but this became
problematic when programmers started collaborating on programs and found
out they had few common keystrokes between them.
"The user community had become fragmented with respect to the skills of
text (and program) editing," Steele writes. So Steele, along with David Moon
and Stallman, took on the project of integrating all the ideas into a
unified command set.
"I made up a matrix on paper and did a lot of running back and forth
among the implementers and users of the various macro packages," Steele
"I remember this very well," recalls Dan Weinreb, who was one of the
first alpha testers of EMACS. "Guy had a clipboard with a piece of paper
showing all the key bindings, and he carefully and diplomatically collected
input and comments from everyone to put together the
unified, standard key bindings."
After a few months, Steele, busy trying to finish his master's
dissertation, handed the work over to Stallman. And the rest is history.
That the flexibility was baked in from the start gives EMACS its edge,
say hardcore users.
"I think of EMACS as the Swiss Army Knife of editors," emails Debra
Cameron, co-author of Learning GNU Emacs
and president of Cameron
Consulting. "It is a complete work environment, a microcosm. If you think
of something you wish it did, you will probably find out (after looking
around) that it already does it. If it doesn't, you can extend it and make it
do what you wish it did."
Can't we all just get along?
So how does EMACS contrast to vi?
"I have seen very adept vi users do some pretty neat tricks, but I still
think vi is (just) an editor, even if for some it is a great editor,"
emails Cameron. "[It] always, always works the same way. In this sense, vi
is like McDonald's; no matter where you go, it is exactly the same."
"Do you want an editor that can be modified to your needs and quirks and
which does many, many things or do you just want to be able to quickly edit files
on any machine?" she asks. "For people who have to move around from one
computer to another constantly, this consistency can be a real advantage."
In other words, EMACS = flexibility, whereas vi = uniformity?
Here's where things get murky.
"EMACS is certainly more complex than vi, but I don't believe it's more
powerful in any sort of useful way, because vi was designed to be part of a
UNIX system and to interact with those tools," counters Jon Lasser.
Mind you, for Lasser, "useful" means the way that vi allows you to read
documents directly from a UNIX pipe from another process, "like you would in
any other UNIX application," he explains. So, the arcane string of keystrokes "<esc> :r !ls<enter>" entered into vi (in command mode, remember) reads into
the buffer the output from the "ls" program, or a listing of files from the
current directory. And a pipe from any other UNIX program would work as well.
As for editing a large number of files automatically in vi, Lasser says
that's why we have "sed, awk, and all of the other UNIX text-processing
"Text processing is what UNIX was designed for, and vi was designed to be
part of such a system," Lasser writes.
Maybe the underlying issue between EMACS and vi isn't one of uniformity
versus flexibility at all. After all, both editors offer flexibility, its just
that with vi, it's through UNIX itself, whereas EMACS achieves it by building on
top of the system.
And, for that matter, the only point of flexibility anyway is to make the
job go faster. If you wanted straightforward no-frills text processing, you
could go with Pico, which offers just a blank screen and none of the
newbie-confusing features of either vi or EMACS. What both of these editors
offer are advanced ways of narrowing the gap between the speed of the fingers
on the keyboard and the speed of the programmer's brain.
In other words, could it be that these editors offer the same thing, but demand different ways of thinking from their users? Vi requires the
patience to learn its quirky ways, though once you master them, you're free
to take your act to any UNIX system. EMACS endows you with mad freedoms in
customizing your setup as you see fit, though if you're not careful, you'll
become prisoner to your own configuration.
Sometime during the great hike of improving self-efficiency that all good
programmers take, vi and EMACS users cross paths, each coming from a different
direction. And when they meet, they usually throw stones at one another.
But it's all good.
"I don't think there is a strong difference in functionality. Both
editors do a fine job and it just comes down to what people learn first," Gil
writes. "Since most people know EMACS, they will teach others EMACS. Hence,
most people use EMACS, etc."
And so the feud will continue ...
(Note: Capitalization of EMACS, UNIX and vi may have been changed in
quotes to their original forms, except in direct titles of books and Web