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!)

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

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).

References

• title - Stewart Brand
• The emacs tutorial - run emacs and try “C-h t”
• title - Alan Cooper
• title - Donald Norman
• http://www.gnu.org/software/emacs/ - The home of emacs on the Internet.
• Free On-Line Dictionary of Computing (FOLDOC)
• Maltron Keyboards - Ergonomic keyboards of a significantly different design to the norm. Definitely worth considering for RSI sufferers, but also good for normal use.

Acknowledgements

Thanks are due to the following people:

Graham Ashton for reviewing an early version of this essay and pointing out many places where things could be made clearer, and telling me of a number of his own observations while using emacs.

Ian Fairman for early proof reading and telling me about the alternate key-bindings available in the Windows version.