Using Emacs - the good and the bad

Introduction

Emacs, for those who are not familiar with it, is a text editor. At
least that is true at the very simplest level. It is actually much
more than that. But most commonly it is used as a text editor. It
supports modes for a great variety of programming languages, and has
an awesome number of editing features. Beyond text editing it also
incorporates an email client, web browser, calendar, a number of
games, and a host of other miscellaneous features.

It can be found most commonly on Unix and Linux, but there are
implementations for Windows and more recently, for Mac OS. It has its
advocates, and its detractors and having been in both camps it
occurred to me to examine why emacs is popular, and why it is so hard
to learn, (which is primarily why it has its detractors). Having
looked at that I want to see if it is possible to keep the good
features while making it simpler to learn, and thereby getting the
best of both worlds. At this point I should probably admit that I’m
writing this using Emacs on Linux, and by any measure I qualify as a
power user. I’ve been using emacs now for about 18 months and so have
a grasp of its basic use, though I use it exclusively as a text
editor and steer clear of its other functionalities. I should probably
also point out that I’m writing the raw HTML by hand so I’m hardly Joe
Public.

Firstly, perhaps a bit of history. Emacs was written, and is still
maintained by Richard Stallman, founder of the Free Software
Foundation. At the time it was written, many users of Unix were still
using the command line as their dominant interface, over telnet and
the like. For this reason emacs works without any difficulty in a
purely character based environment. Because of this heritage emacs
works excellently without a mouse, and makes brilliant use of the
keyboard. It also does not use pop-up dialogs, or other GUI features
simply because, in the world in which it grew up, these things
did not exist. The strange thing about this is, that as a day to day
user this actually makes usability better once you’ve been through the
pain of learning how to use it.

More recently though Emacs has gained support for X, and does now
sport a menu bar at the top of its window. It supports use of the
mouse for moving the cursor, and selection. It also supports (at least
on Unix and Linux) the rather unusual copy and paste mechanisms common
on those platforms which are worthy of a separate discussion in
another essay.

Emacs then owes much to its limited environment. As a daily user I
feel it is much better for it. But that is also part of its
problem. Because it has such a different heritage from text editors on
Windows and Mac OS it has used some very different idioms for things
like searching (or “Find” if you prefer), and cut and paste. Emacs’
solutions are, I feel, superior for the frequent user but make the
transition from other platforms much harder. Once you understand those
idioms emacs is excellent but learning them is a painful process. It
is this, primarily I believe, that gets emacs its
detractors. Especially when used outside the windowing environment,
via telnet for example, emacs is frightening to the uninitiated
user. The first few times I used it getting out and back to the
command line was a major undertaking. As it happens holding down
Control and typing XC will do this, but how was I to know. Emacs does
actually tell you this when it starts up, but the message disappears
after a little while, and will go away as soon as you hit a key. It
naively expects people will read its helpful mini-intro. Back in the
real world people don’t do this. This instantly makes it unpopular
since the user gets a feeling of impotence, not knowing how to do the
simplest operation.

Emacs Idioms

Buffers

In emacs text is loaded from a file into what emacs calls a
buffer. Emacs can work on many files simultaneously, each file loaded
into its own buffer. The user can switch between buffers, copy text
from one to another, compare buffers with each other, or with files
and so forth. Emacs also supports what it calls windows (to most other
people they’d be called frames I guess). It can split its display so
that it shows one buffer in each window, or simply different parts of
the same buffer. This allows for similar functionality to using
multiple windows or MDI under Windows. I’m constantly using multiple
buffers, and generally keep a copy of emacs open all the
time. Clearly, the way in which emacs handles multiple buffers is
harder to use than most Windows editors (those than can!), but it does
have the advantage of being very lean on display space. For an
experienced user, this is an advantage. The other advantage is that
there is no need to use the mouse. Many Windows users will claim that
is no advantage, but when it comes to making editing text a fast and
fluid process keeping your hands on the keyboard is the trick.

There is a very nice feature of emacs concerning buffers. If you try
to open a file that does not exist, it lets you. It just displays a
little message at the bottom of the screen saying “(New File)”. No
hassle, no “File not found”, it just gets on with it. If you were
expecting there to be a file and there wasn’t, you get to create it
instantly. This is subtle, unobtrusive, but helpful. It’s pretty
obvious that the file does not exist because you get an empty file,
and that encourages you to quickly look to see why. This sort of zero
aggression interface is typical of emacs.

Another nice feature is auto-saving. This might seem a pretty run of
the mill feature, but, as is typical of emacs there are understated
subtleties waiting to be discovered. Recently I was editing a web page
and I killed (roughly speaking, emacs’ equivalent of cut) a large
fraction of the document. Emacs displayed a brief message saying
something to the effect that I’d just deleted a large piece of text
and because of that it had disabled auto-save. It did this to make
sure that should I want that piece of text back I had the option. This
was in addition to the standard undo facility. The reasoning being
that should emacs or the operating system crash, it would do least
harm that way. Now that is considerate software! That is looking out
for me. It’s little touches like that that make emacs a joy to use. Of
course if emacs had crashed and I’d not seen the message I’d just have
noticed that I’d got a big chunk of deleted text back, but it’s very
easy to delete it again, it’s hard to retype. For anyone who’s had to
retype any quantity of anything this is a great way to win friends.

Key-bindings

Once a file has been loaded into a buffer editing can begin. Because
emacs can be driven wholly by the keyboard learning the keyboard
commands is essential. Most commands are introduced by control key
combinations. The commonly used ones are simple patterns, and have
simple mnemonics. More obscure commands have appropriately more
obscure key strokes. Emacs uses the word key-bindings because the
connection between a key combination and a specific command is simply
a configuration option. Key-bindings can be changed. I don’t actually
know of anyone who does this, but in principle it’s possible. I have
heard that the Windows version of emacs does have an alternate
Key-bindings set that are more “PC like” though.

What is more important though is it means that new modules (or modes
in emacs parlance) can bind keys to their functions very easily, and
this is very common. For example I use a version control system CVS,
and emacs has a mode or module so I can control this without leaving
emacs. To do this it adds a few commands into the vocabulary and
“binds” some keystrokes to those commands.

The problem with key combinations though is how do you learn them. The
mini-intro that emacs shows when it starts does tell you how to launch
help and get the tutorial. But who reads the mini-intro? If you do
then you can find the tutorial which will get you started, but
learning emacs is not easy. There is no simple “pedagogic command
vector”, to steal a phrase from Alan Cooper. I’ll return to this point
shortly.

First though I’d like to go through a few of the simpler key-bindings
that emacs uses. On some early command line systems the cursor keys
are not present and so control key combinations echo these
functions. Here it’s worth explaining emacs’ own notation for
commands. C- means hold down Control while pressing a key, so C-x
means Control X. C-x C-c for example means Control X followed by
Control C and is the command to quit emacs. M- is the same for the
Meta key (on PCs this is typically the Alt key, many Unix
workstations have a dedicated meta key).

The simplest key-bindings then are the ones to move around the
document. (Strictly the simplest ones are actually the ones
that insert characters into your file, but let’s not quibble!)

Key-binding

Function

Key-binding

Function

C-f

move forward one character

M-f

move forward one word

C-b

move backwards one character

M-b

move backwards one word

C-n

move down one line (next line)

C-v

move down one screenful

C-p

move up one line (previous line)

M-v

move up one screenful

Backspace

delete to the left

M-Backspace

delete word to the left

C-d

delete to the right

M-d

delete word to the right

C-e

move to end of line

M-e

move to end of paragraph

C-a

move to start of line

M-a

move to start of paragraph

I’ve put two Key-bindings on each row to highlight the similarity (or
lack of) in the key-bindings for similar commands. In emacs this sort
of logic is very common (programmers find this sort of thing elegant,
and I agree with them). Note that moving forward one character is C-f
while forward one word is M-f. The Meta key is doing the same, only
more so! This is true for C-b/M-b, C-d/M-d as well. It’s a shame that
M-p and M-n aren’t used instead of C-v and M-v for moving up and down
one screenful. As it happens these combinations are unbound (ie do
nothing). That’s just bad, but of course, you can always rebind them!
The other one to notice though is Backspace. It does what you’d
expect. But to delete a word you would use M-Backspace, even though
you don’t use C-Backspace to delete a single character. This is as it
should be. If you had to use C-Backspace for one character life would
be infuriating, it’s such a common thing to do it deserves a single
keystroke, but maintaining the consistency of using a Meta key
combination to do the delete-word is simple and guess-able (in fact I
guessed it while writing this paragraph!). Consistency in this case
would be overbearing. Inconsistency is a neat breaking of the rules.
The last two lines of the table show C-e and C-a and their meta
variants. These meta variants might not be obvious from what’s gone
before, but they are not exactly a surprise either.

There are a couple of criticisms worth mentioning at this point. One,
is the keys used for forwards, backwards, next line, and previous
line. While these are easy to remember, f for forwards, b for back and
so on, they are not convenient to use. It would be better if the keys
used were arranged in some pattern on the keyboard, say, I, J, K and
M. Once these keys are used often, and navigation is a common
activity, remembering is not a problem. It’s worth making a sacrifice
in learning here for the sake of improved long term comfort of use
(I’m deliberately avoiding the term “ease of use” since it is somewhat
overloaded).

The other point is the exact action of the next
word/previous word movements. A friend pointed out that forward word
actually moves the cursor to the character after the current
word. This is rarely what you want. It means that you have to jump a
few words forwards and then move a character or two to get to exactly
where you want. In my experience this is very common. Forward word
should place the cursor at the beginning of the next word. This would
leave the cursor in the right place for operations on that word, say
deleting it using M-d (delete word to the right). Because the
implementation of this is not like this the users’ confidence in using
the forward/backwards word movements is reduced because it never quite
does what they want.

Now that cursor keys are common there are some new bindings

Key-binding

Function

C-right or M-right

move forward one word

C-left or M-left

move backwards one word

C-up

move up one paragraph

C-down

move down one paragraph

M-up

--Unbound--

M-down

--Unbound--

M-left and M-right behave in a reasonable fashion, though it’s a
little strange that C-left and C-right do the same thing. That’s not a
bad thing though. C-up as up one paragraph is reasonable, but it’s
still a shame that M-up is unbound, I feel a little cheated there!

The beauty of the default emacs keystrokes is in their logic, with a
few notable exceptions. Many other key strokes also have their own
little logics that help in remembering them. I suspect, though I have
no proof, that these were not all original parts of emacs, but have
been added, rebound, moved, and generally fiddled with over time to
make something that is comfortable to use. It’s like a building that’s
been lovingly altered by a DIY expert. It fits well. I’m sorely
tempted to make my own little changes to fix those “defects” mentioned
above with respect to the M-p and M-up not being bound for
example. That’s exactly what has made it good I suspect. This follows
a philosophy I discovered in Stewart Brand’s book How Buildings Learn,
which talks about how buildings are often best improved by the people
who live in them, and therefore really understand them. There is
naturally a large scope here for individual preference as well, but
that is a complex subject in its own right and is probably better
dealt with in an essay of its own. Of course this evolution and
constant improvement would not be possible outside the free software
or open-source communities, which is a loss to everyone. How do we
make this possible in commercial software? I leave that as an exercise
for the reader.

Something that’s worth adding, is why, now that emacs can reliably
expect to find cursor keys available, should it still support the old
key-bindings to move around documents? There are two main reasons for
this. Firstly, what is the point in removing the old ones? People know
them, so why hurt those people. The second though, and more important
reason for new users is it’s faster to use the C-n and C-p on
occasion. That’s not to say that the cursor keys are not useful, I use
them for most of my moving round the document. However, I find that
when doing repetitive edits to a document it’s quicker to use C-n
rather than the down cursor simply because it means that I don’t have
to move my fingers from the home keys. I can work about 3-4 times
faster that way, and I don’t really touch type, for touch typists I
suspect the improvement is even greater. What this suggests of course
is that the keyboard is badly designed for computer use, but then
given it was designed for mechanical typewriters before the concept of
cursor keys was even thought of this is hardly a surprise. But emacs
counters the deficiency of the keyboard admirably. Once day I’ll treat
myself to a Maltron keyboard
and maybe then I’ll stop using C-n! The nice thing about supporting
both cursors and the other key-bindings though is that it costs
nothing in the interface. If you don’t want to know, you never have
to, and it never bothers you. But if you do know you can work more
effectively.

The minibuffer

The last major idiom I want to talk about is the minibuffer. At the
bottom of the emacs window is a reverse-video (ie inverted colour),
line known as the mode-line, and directly below that is a blank line,
which apparently serves no purpose. In fact it is a very important
part of the interface. This is the minibuffer. Earlier I mentioned
that when you try to load a non-existent file it will create a file
and put up a little message “(New File)”. That message goes in the
minibuffer. But there’s more to it than that. The minibuffer does
not only give the user feedback on what emacs is doing, though it is
commonly used for that. It also acts as a scratch area for interactive
commands. The best example is the “search” command, which is
brilliantly elegant.

C-s starts a forwards search. On pressing it the minibuffer displays
a prompt “I-search:” (interactive search). Now you can start to type
what it is you want to search for in the buffer. This appears after
the prompt. But the great feature is that as you type the first letter
emacs jumps to the next occurrence of that letter it can find. As you
type a second letter it jumps to find those two letters, and so
on. This way you can easily get away with typing the shortest search
string possible to find your quarry. Having found the string you can
search for later occurrence by simply typing C-s again. Pressing
backspace reverses back through the various matches the search
found. If however there are no instances of the word you’re looking
for the minibuffer shows “Failing I-search: foo” where foo is the
word you’ve searched for. There are no error messages, no
interference, and in fact no need to look at the minibuffer at all. A
simple beep tells you if the search fails (I’d prefer something a
little less grating, but some things aren’t too important!). Pressing
return finishes the search leaving the cursor wherever it’s got to,
and a “mark” where the search started. The mark allows you to return
to the start of the search with another key combination C-x C-x. The
I-search, once learnt is a very simple and flexible tool. While it is
very different from normal find methods found in most tools it is a
very valid approach, sadly underused. It is the minibuffer that makes
this possible.

A simpler example of the minibuffer, this time just as a
informational area is saving a file. C-x C-s saves the current
buffer. Since buffers are always associated with filenames there is no
need to ask for a filename. Emacs saves the file and displays “Wrote
foo.html” in the minibuffer. A variant allow you to save with a
different filename (like Save As...), C-x C-w, this time the filename
is asked for in the minibuffer. Once saved acknowledgement is given
in the minibuffer. This sort of assurance is excellent. What makes it
vastly better than a dialog box is that it does need to be
dismissed. It simply gets displayed. If you want to read it you can,
if not, just ignore it. It won’t bother you. This low overhead
interaction is exactly what is required in more applications, and
emacs wins again by making it serve double duty as an input and an output
field. [ Incidentally, if you think C-x C-w is a strange key-binding
for Save As, remember that C-x C-s is save, and then look at your
keyboard and note where the X, S and W keys are. Pretty isn’t it! ]

The down-side

Learning emacs is painful

So far I’ve been pretty positive about emacs, and not really said
anything of substance against it. I find it an excellent tool, but it
wasn’t always thus. Emacs is hard work to learn. In
title Alan Cooper
introduces the idea of Pedagogic Command Vectors. Simply put, a
pedagogic vector is a part of the interface which helps teach new
users what functionality is available and introduces them gently to
some of the other command vectors. In typical Windows programs the
menu is a classic example. You can scan the menus to see what the
program does, and many menu items tell you what the keyboard shortcut
is (in fact all those where such shortcuts exist). Emacs is very poor
at this.

If you run emacs under X you do at least get a menu bar, but it is by
no means complete. This is no great surprise since emacs has roughly
650 functions in the version I’m using now. That many functions don’t
sit neatly on menus. However, the menus don’t even include a
reasonable working set. What’s worse, they don’t always have the
keyboard equivalent marked. On the Files menu there is an entry for
killing the current buffer (there’s a buffer menu too, so why is this
entry not on that?). However, I have never seen, on any version of
emacs I’ve ever used, that entry have its key-binding displayed. The
Key binding is “C-x k”, but you’d never know. As a teacher the menus
are not very helpful.

The closest emacs gets to a pedagogic command vector is its command
set. By typing M-x you can enter emacs commands directly by
name. Everything emacs can do is implemented by a command, so this is
a powerful way of doing things. For example, if you want to run the
tetris game (believe me, there is one!), you type M-x. The minibuffer
shows the prompt “M-x ” (a little unhelpful compared to the nice
I-search prompt you get when you type C-s). You now type “tetris” and
press return. Hey presto, you can now play tetris.

But how would you know that there was such a command without me
telling you? There is no simple way for the beginner. There are lists
of commands available, but with 650 entries these hardly invite casual
learning. It’s easy to get very discouraged when you start learning
emacs since you can be forgiven for feeling a little irritated that
even the simplest things are impossible to find (and yet more advanced
features leap out at you).

The closest emacs comes to a simple pedagogic vector is “C-h a”, the
apropos command. This lets you type a search word, and it will find
all the commands that include that word. The problem with this is you
have to guess the terminology correctly. When I was looking for word
wrap this feature was useless because that’s not what emacs calls it.
There is one other small assistance, when using M-x you have the help
of “auto-completion”. Pressing tab in the minibuffer will make emacs
attempt to complete whatever you’ve typed. For example, if you type
“M-x tet” and then press tab, it will finish the word “tetris”. If
however you type “M-x te” and then press tab, it displays all the
commands available that start with “te”. That’s a small help, but it’s
really more useful when you know exactly what the command is since it
saves some typing. If you don’t know how the command’s name starts
you’re stuck. Emacs badly needs a much more obvious way of discovering
new features.

The problem is that the functions are not grouped into
any sort of structure other than a big list of command names. A
hierarchical menu would be a massive improvement despite hierarchies
being poorly understood by many people. At the end of the day, emacs
has been developed by programmers for programmers and so more complex
interfaces using schemes like deep hierarchies would have been
acceptable. In practice however emacs just never bothered. In my
experience the way you discover its features is by asking a local
guru. How did they find out? Either by accident or by asking someone
else. The other option is of course to RTFM (Read The F*ine Manual),
but frankly that’s just an admission of defeat announcing that the
interface lacks teaching capability. It doesn’t get much better as you
learn more of it, emacs needs a pedagogic vector very badly.

It’s easy to forget

The obvious knock-on from being hard to learn is that it’s hard to
re-learn. While nice logic in the key-bindings helps, (can you remember
what they were from the start of this essay?) it’s not enough. It is
easy to forget. Once upon a time I learnt how to switch on automatic
text wrapping. For ages I forgot how again, and the lack of a
pedagogic vector meant that I knew I could do it, but I couldn’t
remember how. The ultimate frustration. Of course it’s easy, “M-x
auto-fill-mode”. I’d just forgotten that emacs called it filling, and
that I needed the auto up front. Emacs is not a good tool unless you
keep in practice. And even then, those features that you rarely use
are all too easily forgotten. Once I learnt how to record macros. Now
I’ve forgotten, it’s too much effort to re-learn. I use it every day,
but should I ever leave it for a few months my disloyalty would be
severely punished. Of course programmers never leave such a basic tool
for such a huge length of time so the problem doesn’t arise for them
that often, and programmers like torturing themselves that way
anyhow. “I can use emacs” can be said with a swagger.

It fails to use more modern idioms

Emacs is stuck in the 80’s. At the end of the day it’s a terminal
based tool. Many of its best features have been provoked by this
austerity but it fails to take advantage of the later developments in
interface design. There are no button bars, no tooltips, very few
dialog boxes. Some of these functions are better implemented in the
minibuffer (a true work of genius, a vast improvement on many dialog
boxes), but button bars would not be a bad addition. When you type a
command using M-x after emacs often tells you what the key-binding for
that command is (if it has one) when the command is completed. That’s
great, couldn’t we do that with buttons too? You would admittedly lose
some screen real estate, but emacs has been so cautious with that up
till now, and screens are much bigger than they were, we can afford to
use some of it. I wouldn’t put the absolutely basic stuff there,
because people will learn those quickly, and the keyboard is faster,
but those less frequent functions would be nice. It would be great to
have button bars for various groups of functionality. I’d like one for
version control for example. Being able to arrange these as I wanted
would be a bonus. Netscape’s collapsing button bars might be one
solution, except I don’t like the way you can’t tell which bar is
which when they’re closed.

As emacs stands the M-x command is used as a general way of accessing
all the power of emacs. However, since this involves typing in the
command you need, you need to know what that command is. I have said
before that M-x should be obsoleted, but this is probably
overkill. Rather there should be another way of accessing the whole of
emacs’ functionality. This is a serious challenge given the number of
commands emacs supports. Menus break down well before being able to
hold 650 functions so we are left looking for a new idiom. This can in
part be solved because not all functions are always relevant in all
contexts. For example, if you are writing code you don’t need spell
checking in all likelihood (although some may disagree). More
helpful perhaps is the fact that many of emacs' functions are
obscure. That is to say that they are rarely used. It would be
reasonable to divide the functions into everyday, frequent, occasional
and never sets. Clearly users would have their own views and this
would need to be configurable, but there is almost certainly good
agreement on many functions. Everyday, frequent and some occasional
functions should be on the menu-bar, but this probably only counts for
a small proportion of the functionality. The rest should be relegated
to a hierarchical function browser. Emacs does have hierarchical
browsers of this kind but generally the hierarchies are very poorly
designed which renders them virtually useless.

Configuration of emacs is another sore point. Customization is based
around a large number of variables arranged in a hierarchy which even
as a programmer, with a solid understanding of such structures I find
daunting. The arrangement is poor and unclear and without mentioning
that the way the values are edited is all based in a text editing
frame. I never use this feature, it’s simply too painful. It pays much
more attention to making it easy to code than it does to being easy to
use. A few dialog boxes here would have made life much easier.

And then there’s the .emacs file. When emacs loads it examines a file
called .emacs (filenames starting with a dot in Unix are hidden). This
file can be used to set variables. Mine for example switches on syntax
highlighting (which if you program you’ll appreciate), and makes a
couple of other tweaks. This is hardly a pleasant way of changing the
behaviour. What’s worse is that to change the text colour and the
background colour it seems that I have to edit another configuration
file that is not owned by emacs at all (the .Xdefaults file as it
happens). There is probably a way of getting the .emacs file to do it
but I’ve never worked out how. And that’s the killer. Whenever someone
asks me “can emacs do ...” I always answer yes. Can I do
... with emacs. Often, no, but you can bet emacs can do it. And that
is a sign that a powerful piece of software is being let down by an
insufficient user interface.

The Verdict

There are many features, and several idioms I’ve not touched on in
this essay, but I hope I’ve made the main point I wanted to clearly
enough. Emacs is popular because once learnt, it allows the user to
work with incredibly little interference or intrusion. Very low
friction if you will. Emacs’ use of the keyboard is excellent. A
skilled typist can make text flow and work incredibly fast. Even
though I don’t touch type (although I get close) I can work very
rapidly, faster with the keyboard than with the mouse. That is the
reward for learning and putting up with emacs’ failings. Emacs is one
of those applications that I use almost entirely unconsciously and that is what makes it
good.

But it’s unpopular with others because it is simply very hard to
learn. You can’t use emacs occasionally and expect to be
effective. You either live emacs, or you leave it well alone. To use a
phrase from Donald Norman’s book The Design of Everyday Things,
emacs relies heavily on information in your head, rather
than information in the world, by which I mean that you have to know
how to use emacs, you can’t rely on its interface to help you out. While
this was very common in the world of command line software it has been
improved on in the GUI world. Emacs has failed to keep up. If you want
to learn to use emacs you’d better make some space in your calendar.

So, how could we combine emacs with more Windows or Mac like editors
to make a best of breed? Emacs would offer the minibuffer, and its
interactive search, both of which are excellent features. It would
offer its incredible customizability and extensibility by third
parties (and ten thousandth parties for that matter). It would offer
many of its simple key-bindings for text manipulation. In fact many
editors I’ve used on other platforms mimic some of emacs’ key-bindings
because once you’ve learnt to use them you never want to go back!

More conventional editors would offer toolbars and dialog boxes for
configuration. They would offer drag and drop editing, inline spell
checking (one great word processor I used once would beep quietly when
it saw you type a misspelt word, you could then decide to carry on and
correct it later, or quickly cast an eye over it). They would offer
Recently Used Lists for the more obscure commands.

The fact that emacs can be used unconsciously is a major boon. That
fact that other editors can be learnt and used in minutes (rather than
months), is massively important. Emacs lacks ways of browsing through
its functions in a structured manner. There is a command, accessed by
the key sequence “C-h i m emacs”, but if you knew that, you probably
didn’t need it. Some other editors rely on the mouse for use, (a bad
idea when the main point of an editor requires your hands on the
keyboard, moving from there to the mouse and back the whole time is
very wasteful of time).

Some say what emacs really needs is a decent help system. But look at
the paperclip in Word. The first thing I ever asked that was “how do I
get rid of you?”, which incidentally, it couldn’t answer! Word’s help
was overbearing and intrusive, which is why I really like emacs, it
keeps out of your way. I got this email from a friend when he read the
first version of this essay.

>I’ve still got about 90% of emacs left to learn (i.e. I need to learn
>lisp) but I find it an incredibly powerful tool even though I know
>relatively little about it. and here’s a good point - all that extra
>functionality is totally hidden from me until I decide I want to find
>out how to use it. It doesn’t get in my way. I like that.

Emacs does not interfere with you. The paperclip in Word on the other
hand nags. I’ve yet to meet someone who likes being nagged.

But I think emacs goes too far the other way. I don’t want help if I
don’t ask for it, but when I do ask for it I want it to be at hand and
well arranged. I think though that it comes back to the function
browser point. I want a decent function browser, with meaningful clear
descriptions of the functions, preferably reasonably concise. My
analogy would be with the index of a reference book. Without a good
index the book is worthless regardless of the information inside
simply cause you can’t find what you’re looking for in a reasonable
time.

Emacs desperately needs to simplify configuration. With emacs almost
anything can be achieved. Ultimately you can write text processing
macros in lisp if you really need a feature. In fact that’s precisely
how many of the add-on modes have appeared. So it’s not that emacs
can’t be configured, far from it. It’s just that making simple
configuration changes like a key-binding or the colour scheme is
non-trivial. There is a customization menu structure, but it sheds
more heat than light. I’ve played with it a few times, but I can never
find the option I want to change. I’ve given up.

So overall, do I think that emacs can evolve to become the perfect
editor? Probably not. There’s simply too much work to do to remold all
that functionality into a new shape. But I do think that many of the
features of emacs will appear in the next greatest editor. I like
emacs, I use it every day. I’m highly productive with it and that’s
something I can’t get with any other editor, but it still irritates me
when I step out of the bounds of what I’ve learnt. With the massive
functionality emacs supports it’s hard to see how an interface could
be made to support it but perhaps there are some hints appearing...

It’s interesting to note that on Unix and Linux many applications use
emacs key-bindings for entering text in dialog boxes and the like. And
that’s an excellent thing. So perhaps rather than emacs containing
everything, everything should contain emacs. Because of the
unconscious nature of its interface it should be used everywhere text
is entered, those simple key-bindings (and many others I’ve not
mentioned) should be used everywhere. So perhaps emacs’ legacy will
reappear in editing components, but I’ll say much more about that in a
future essay on the effects of componentization in user interface design.

Finally I should point out, in case it’s not obvious, that I don’t
know everything about emacs, the human brain is simply not that big,
so it’s entirely possible that I’ve missed features that other people
think I should have included. Likewise it’s entirely possible that
I’ve made some mistakes. Please feel free to point these things out
and I’ll try to take note. It should also be pointed out that a great
many people have been involved in developing and improving emacs over
the years, most famously of course Richard Stallman. If you were one
of emacs’ contributors then you should feel a warm glow of pride, you
have my thanks for such an excellent tool despite any criticism I may
make. But next time you make an editor be a little more generous to
the casual user.

Emacs can be obtained from the GNU Emacs website or you’ll find it
included in almost every Linux distribution known to man!
Incidentally, if you wondered, emacs stands for Editing MACroS or
Extensible MACro System depending who you ask, you can find that a few
other morsels at the Free On-Line
Dictionary of Computing (FOLDOC).