It took a little longer to prepare for this
month's column:
Nomex suit? ...Check!
Kevlar vest? ...Check!
Elbow pads? ...Check!
Helmet? ...Check!
Ready? ...Ready!
OK. Here is the entire column, in a nutshell:
Emacs rules.
vi drools.
Right about now, all the Emacs users are surfing off to other parts of
the magazine, wondering why I'm restating the obvious. All the vi users
are angrily sending e-mail that reads something like this:
You are a blithering idiot! Emacs is the worst editor ever
invented! I learned vi and I've never needed anything else!
:wq!
^[kdd:w!q!ZZ
^C^D.exit
quit
logout
The rest of you are probably wondering what on Earth I'm talking about.
Back to basics
When developing software, the most important tool at your disposal is
your text editor. It must be robust, extensible, easily learned, and
productive. You will probably spend more time using your text editor
than any other tool. It should fit like a glove and be as comfortable
as an old shoe.
Within the world of Unix software development, there are two principal
choices for editors: Emacs and vi. Invariably, the people who choose
Emacs loathe vi, and those who choose vi are appalled by Emacs. In case
you hadn't figured it out by now, I'm in the former camp. In spite of
my obvious bias, I'll still try to give a brief overview of each tool,
expanding on the virtues and drawbacks of each.
Emacs: the tool of tools
Emacs is a freely available editor originally written by Richard
Stallman and since enhanced by thousands of enterprising contributors.
It is distributed by the Free Software Foundation and is available in
both source code and precompiled forms. (You can ftp a copy from the
/pub/gnu directory at prep.ai.mit.edu or one of numerous mirror ftp
sites. ) It supports both
character-based and X Window environments and runs under a wide variety
of operating systems, including Unix, DOS, and Windows.
Emacs has been written by programmers for programmers. Its single best
feature is that it is infinitely extensible by means of a built-in LISP
interpreter. Almost every command in Emacs is actually a tiny little
LISP program that acts upon your text files. To extend Emacs, you
simply modify the existing programs or add a few of your own.
Emacs is known as a "modeless" editor, meaning that it is always ready to
both accept text as input and act upon that text via user commands.
You never switch between "command" and "input" modes in Emacs.
In Emacs, modes exist for just about
every conceivable programming language
-- even languages like HTML.
New users are sometimes confused by the fact that Emacs does have
various operating modes that determine how text in a particular buffer
will be handled. For example, Emacs has a "C" mode that understands how
C programs are formatted. As you type your source code, Emacs
automatically indents and formats your code. In the X version, it will
even render function names and other language elements in various colors
and fonts to make them more readable. Other modes exist for just about
every conceivable programming language, even languages like HTML.
There are even some word processing modes that indent, flow, wrap, and
format your text automatically.
Emacs was popular well before window systems came into vogue.
Programmers who were editing code disliked having to exit the editor to
perform other tasks like reading mail or running the compiler. As a
result, they added features to Emacs that let you read your mail, run
the compiler, invoke the shell, and even browse the web all without
leaving the comfy world of Emacs. Since Emacs sports a complete
programming environment, enhancements like these can be made relatively
easily.
Emacs deals with text as collections of lines within a buffer. Usually,
a buffer corresponds to a single text file. You can have any number of
buffers loaded into Emacs, making it easy to edit programs broken into
many separate modules. Emacs lets you split the screen any number of
ways so you can view multiple files simultaneously, and it's easy to
move text between buffers.
In general, the alphanumeric keys on the keyboard, when pressed, insert
the corresponding character into the current buffer. Editing commands
are invoked by holding down combinations of the control, shift, and
meta (diamond) keys while pressing an alphanumeric key. Often, the
shift keys control the target of the key being pressed. For example,
control-B moves back a character; meta-B moves back a word. Control-T
transposes adjacent characters, Meta-T transposes adjacent words,
Control-X Control-T transposes adjacent lines.
Basic editing in Emacs is easy.
If you don't like the way the commands are mapped to the keys,
you can rebind any command to any key. (You can even make Emacs look
just like vi -- but why?)
The biggest drawback to Emacs
is that the executable is enormous.
In general, Emacs is the perfect programmer's tool, infinitely
extensible and customizable, readily available, and easily learned.
Its many modes, perfected over the years by thousands of users, make
editing almost any language a breeze. Emacs's idea that an editor is a
complete environment, not just a simple tool, makes every programmer
more productive.
But on the other hand...
While Emacs users gloat about the power of Emacs, vi users are quick to
point out that all that power carries a price.
The biggest drawback to Emacs is that the executable program is
enormous. A bare-bones copy of character-based Emacs might consume three or four
megabytes of swap space on a Unix machine; the fully equipped model with
several modes loaded running under X Window can easily burn ten
megabytes or more, even before you load any files for editing. vi,
in contrast, consumes about a megabyte before loading files.
While those who know Emacs LISP (or elisp) can easily extend Emacs, it
is almost incomprehensible to everyone else. In reality, every site
seems to have a few Emacs gurus that can work all sorts of magic with
elisp and they are called upon to perform all but the most rudimentary
enhancements.
Although you can buy commercial versions of Emacs, most everyone gets a
copy off the net. This means you'll need someone who can build the
editor and configure it to your local site. This also means that until
you get Emacs up and running, you'll need to use some other editor to
bootstrap yourself. This is the vi user's biggest complaint about Emacs:
why spend so much time learning Emacs when you may often find yourself on a
system where Emacs isn't available?
vi: the editor for everyone else
vi offers up the standard editing fare: full screen display
(character-based only), cursor motion (but no mouse support), and a
range of text entry and modification commands. Multiple buffers are
supported, but in a rudimentary way. vi is barely extensible via a
simple macro mechanism.
vi offers two modes, input and command. (Emacs users call these input
and beep mode, since all vi does is beep when you hit the wrong key in
command mode). While in input mode, all characters are inserted into
the buffer until you press the escape key. While in command mode, all
characters are interpreted as editing commands. While some control and
shifted characters are used as vi commands, there is no general use of
control and shift keys as command modifiers. vi has no concept of a
meta key.
To make sure I wasn't missing some fundamental feature of vi, I queried
several long-time vi users in regards to vi's best feature. They all
gave the same answer: consistency and availability.
What are vi's best features?
Consistency and availability.
Written originally at Berkeley in the early days of the BSD Unix
development effort (purportedly by Bill Joy in one weekend to prove
the worthiness of the curses full-screen driver routines), vi has become
a standard tool in every distribution of Unix. There's even a version
of vi for the DOS world, although giving some poor DOS user a copy of vi is
like throwing an extra pair of handcuffs on an already-shackled
prisoner.
Because of its standardization through Unix, the vi command
set is pretty much identical among all versions of vi. This means that
a vi user can walk up to any Unix machine and immediately begin editing
files. This is particularly important for systems administrators who
often find themselves on disabled machines with most of the tools,
including big ones like Emacs, inaccessible.
Touch typists like the fact that the vi cursor motion keys are mapped to
the H, J, K, and L keys. This means you never have to move your right
hand off home row while moving about in a file. Other users like the
fact that vi is actually a superset of the ex and ed line editors, so
that even if you lose full-screen capabilities, you can still use most
vi commands to edit a file.
vi is frugal with resources. It's small footprint, both on disk and in
memory, make it a great editor for systems with many users working
simultaneously. Fifty simultaneous Emacs users would slow most systems
to a crawl, but fifty simultaneous vi users is a common and relatively
painless occurrence on many shared systems.
Most vi users are comfortable with vi and consider it a perfectly
adequate tool. They'll concede that Emacs has far more bells and
whistles, but they don't think the effort to make the switch is worth
it. That familiarity, coupled with vi's ready availability, make it a
popular tool among many users.
vi: what's to like?
To an Emacs user, the most aggravating aspect of vi is the constant
switching between input and beep modes. You can't freely intermix
text and commands; you must constantly hit the escape key or an
input mode key to get to the other mode.
The command keyboard mappings make no sense, and even worse, you can't
modify the basic keyboard maps. Buffer management is barely capable of
editing multiple files, and viewing multiple buffers is impossible.
There is little support for language-based editing and the lack of
general extensibility makes it impossible to extend vi to handle other
languages.
What to do?
I often tell people that you only need to know one vi command:
:q!. This way, if you ever accidentally start up vi, you
can get right back out. You might want to follow that up with rm
/bin/vi to keep it from happening again. In reality, I know just
enough vi to get the system up and running and to get Emacs installed;
I'll then leave vi behind and never look back.
Truth be told, vi can be handy for quick little editing jobs when Emacs
is not available. You can learn enough of vi in 20 minutes to get
things done, although you'll be nowhere near the power-user category.
If you are faced with editing any large file or collections of files,
especially source code, there is no better tool than Emacs. It is worth
every moment you'll spend learning the various command sequences. When
you get proficient enough, you'll find yourself starting to write little
elisp routines, and suddenly you'll find that you are an Emacs guru,
too. If you use vi, you owe it to yourself to learn Emacs; if you use
Emacs, it won't hurt to learn a little about vi, too.
