The Modernization of Emacs

Just about anything, once it is exposed to human animals, a significant number will find it useful. This is a matter of habit and conditioning and applies to all aspects of human habit or behavior, as you'll find people in cultures into things you couldn't dream of. (such as body modification as flattening their breasts, widening a hole in lower lips... to lesser degree tattoo, muscle bulking... or sexual preferences and fetishes such as shit-eating... , or food intake habits (eating/drinking/diet habits) ...)

Suppose you have random features in a software, and give this software to a large number of people to use for few decades. Chances are, every feature will be useful to a good sized number of people. People, in a sense, adapt their work habits to the features.

The issue about emacs's “*scratch*” “buffer” is that:

• It is not useful by 99% of letter writers. If they wanted a scratch pad, they can open a new document and not save it. This way is familiar to all software users.
• The “*scratch*” “buffer” is primarily designed for elisp programers. (it defaults to lisp mode) Majority of people who use emacs are not lisp coders. For lisp coders, they can easily customize their emacs to have a “*scratch*” “buffer”.
• The “*scratch*” “buffer” is a intrusive idiosyncrasy. It is persistent, cannot be closed (it regenerates). It is foreign to all programers. This idiosyncrasy is the first thing presented to users, and it persists.

Most computer geekers think that the so-called “Meta” key of emacs is a more general and logical naming, so that the term “Meta key” should not be called the “Alt key” to fit Microsoft's keyboard.

above: The Space-cadet keyboard (Source↗, 2007-07) .

Emacs's naming of Meta key isn't actually a general naming scheme. It is simply the name of a special modifier key on a particular keyboard popularly used with emacs in the 1980s. (see Space-cadet keyboard↗) On this keyboard, it has several modifier keys, including Ctrl, Meta, Super, Hyper. The emacs's use of the term “Meta key” simply referred to that key on that keyboard. Emacs actually also support the other modifier keys Super and Hyper to this day. The Space-cadet keyboard fell out of use along with Lisp machine↗. The IBM PC keyboard↗ (and its decendent the Microsoft Keyboards) becomes the most popular since the 1990s and is practically the standard keyboard used today. The IBM PC keyboard does not have Super and Hyper keys, so emacs's support for them becomes little known, but Ctrl remains Ctrl, while Meta is mapped to the Alt key.

In emacs's documentation, the term Meta key should be replaced with the Alt key, to reflect current usage, since that is the keyboard 99% of personal computer users know. The “Meta key” name is a major point of confusion for getting people to learn emacs. The notation C-‹key› and M-‹key› for representing keyboard shortcuts in emacs's manual and menu, should similarly be updated to the more easy-to-understand and universal notation Ctrl+‹key› and Alt+‹key›.

The terminology “buffer” or “keybinding”, are technical terms having to do with software programing. The term “keybinding” refers to the association of a keystroke with a command in a technical, software application programing context. That is to say, a programer “bind” a keystroke event to a command in a software application. The term “buffer” refers to a abstract, temporary area for storing data, in the context of programing or computer science.

These terms are irrelevant to the users of a software application.

As a user of a text editor, he works with files. The terms “opened file” or “untitled file” are more appropriate than “buffer”. Since emacs is also used for many things beside reading files or writing to files, for example, file management, ftp/sftp, shell, email, irc etc., the proper term can be “panel”, “window”, or “work area”. (All modern editors and IDEs use these terms, even though they are all buffers too)

And, the term “keyboard shortcut” refers to typing of a key-combination to activate a command. It is also more appropriate than “binding” or “keybinding”.

Although concepts like “buffer” and “keybinding” are seemingly interchangeable with “panel” or “keyboard shortcut”, but their contexts set them apart. This is why in all modern software application's user documentations, terms like “buffer” or “keybinding” are not to be seen but “windows, panes, tabs, workspace, and keyboard shortcuts”.

The reason emacs uses the technical terminologies throughout is because when emacs started in the 1980s, there really isn't any other text editors or even software applications. And, emacs users are all computer scientists and programers.

Changes in society are always resisted by old timers, but it is also a main element behind progress. This terminology issue may seem trivial, but its importance lies in making emacs palpable to the vast number of people who ever need to use a computer to write.

Note that Emacs does officially recognize the term Keyboard Shortcut. The following is a excerpt from glossary section of the official emacs manual from emacs 22:

Keyboard Shortcut
     A keyboard shortcut is a key sequence (q.v.) which invokes a
     command.  What some programs call "assigning a keyboard shortcut,"
     Emacs calls "binding a key sequence."  See `binding.'

Emac's undo is very confusing and does not have a Redo command. To redo after a undo, people are told to type something then do a undo. Long time emacs user argue that it is technically superior because it lets user to revert to any possible state of the past.

A practical problem with the way of emacs undo is that it repeats the states in the action record. In the prevalent undo model, the action record is linear, and each entry is unique. A user can easily arrive at a desired previous state using undo and redo. Think of it as a time-line with a needle. “Undo” is like moving the needle backward, and “redo” moves the needle forward. A user does a sequence of undos and redos to move the needle to where he wants, then he starts there fresh.

Emacs's undo is not based on simple time-line. In emacs, every undo pushes a state to a stack. If we think in terms of a time-line of unique states, then each emacs's “undo” may move the needle backward or it may move it forward. If a user ever did a redo (by typing something then undo), then a series of undos will traverse the time-line back and forth. It is hard for a user to know when to do undo or do “some random typing followed by undo” to get to the state he wants. In particular, once a person did more than once of “some random typing followed by undo”, the undo record becomes too convoluted for a person to keep in mind and the benefit of undo facility is ruined at that point.

If you take a survey among programers who use emacs for at least 1 year, perhaps more than 90% will report it confusing and not productive. If you take a survey of software users other than emacs, i do not think anyone will complain that they are unable undo their undos.

It is reasonable to argue, that people work better with a simple undo/redo model. Undo is practically used to erase a mistake or doing a simple one-time revision. Once a user did a sequence of undos and redos, we can assume that he arrived at a satisfactory point and intends to start fresh from that point. If he needs extra revision control, a more proper mechanism, one that people actually use, is to revert to the saved version.

Emac's user interface, when compared to modern software application's user interface, is complex and unusual, however, there's no basis whatsoever of it being actually a superior design with regards to any sensible metrics. (in fact, much of emacs's user interface are due to historical reasons. That is, how computers are in 1980s.)

For example, let's consider emacs's system of keyboard shortcuts. For a keyboard shortcut system, we might judge its quality based on several aspects. Here are some examples of consideration:

• Is it easy to learn? (is it familiar to most people? Is it easy to remember?)
• Is it ergonomic? (Are most frequently used commands's keyboard shortcuts easy to type? Are more frequently used commands have easier to type shortcuts than less frequently used commands?)
• Are most frequently used commands all have a keyboard shortcut?
• Is the shortcut system somehow consistent and extensible?

Emacs's keyboard shortcuts system, is good only with respect to the last item. Emacs keyboard shortcuts are perhaps one of the most difficult to learn among software, and is also one of the most difficult to remember. The worst aspect of emacs's keyboard shortcuts, is that it is ergonomically painful. (Many emacs-using programer celebrities have injured their hands with emacs. (e.g. Richard Stallman↗, Jamie Zawinski↗, Ben Wing↗), and emacs's Ctrl and Meta combinations are most cited as the major turn-off to potential users among programers)

Computer keyboard is a hardware interface, and the mapping of commands to the key press combinations can be considered from a Operation Research (ergonomic) point of view. The keyboard hardware itself can be designed with consideration of ergonomics (that's why we have split and curved keyboards), but consideration of what functions to map to what key presses is also non-trivial if the software has large number of functions, or if the software is mission critical, or the software is used for repetitive, long durations of human-machine interaction (such as data-entry, programing, writing). Think of it this way: consider a airplane cockpit, filled with knobs, dials, buttons, and switches. Now, if your job is to map the airplane control functions to these switches, what are the issues to consider?

If we take careful consideration on creating a keyboard shortcut system for emacs, it is not difficult to create a system that is superior in some pure technical sense than the emacs's shortcut system.

For a full discourse, see: Why Emacs's Keyboard Shortcuts Are Painful.

Aside from keyboard shortcuts system, other user interface aspects of emacs are also questionable. For example, one major aspect of emacs operation is that it uses a single window for multiple purposes and files. Emacs is this way not because of a design decision, but rather due to historical reasons. Computer resources in the 1980s are very limited. When emacs is around, graphical system of showing “windows” is not practically available, and the emacs's method of using the screen (the monochrome text-only monitor) for presenting multiple tasks (“buffers”) is actually a very advanced user interface design not available in software of that era. When graphical systems becomes practical in the 1990s, drawing a window still takes a lot memory, and opening multiple windows is slow and impractical.

Modern software interface (say, post 2000) usually uses one window per file (or task), and or show tabs if multiple tasks are represented in a single window. However, emacs's buffer system doesn't provide the tabs visual clue. Compared to the modern standard of tabbed window, emacs's buffer interface is inferior because it is less intuitive. Arguably, emacs's operation methods may be more efficient for expert users. 20 years ago, efficiency for expert users may out weight the ease of use for majority of average users. But in today computing era, computers are standard tools in every household, efficiency and ease of use for general users is as important for professional users. Even for professional users, it is openly questionable that emacs's ways of operation induced by its default user interface allows more efficient operation than a user interface based on modern software conventions. (this can be certified by having 2 programmers roughly equally experienced or skilled in using emacs. One person uses traditional Emacs, the other uses a emacs with modernized interface (such as Mac's Aquamacs), then compare their efficiency in finishing a set of coding tasks.)

Note: we are not disputing the general power, flexibility, and qualities of emacs. Emacs, with a powerful embedded language lisp, and consequently embodies many software applications other than text editing (email, ftp, dired, calc, ...etc), has induced certain system of user interface that is all consistent and unique in comparison to modern software applications. We do not advocate that this is bad. Specifically, we only propose a very few trivial items for interface or documentation changes as listed in this article. Most are simply turning on some features by feault and or changing some terminologies in the documentation. They have no bearings on how emacs operate in general.

Aquamacs is a emacs variant based on emacs, for Apple's Macintosh computers, created in about 2004 by David Reitter. Aquamacs modifies emacs so that its user interface follows modern (Mac OS X) conventions. For example, copy/cut/paste shortcuts are cmd-c/x/v. Open file is cmd-o, saving is cmd-s, save-as is cmd-shift-s. Close window is cmd-w. Undo is cmd-z, and there is a redo command by default, with shortcut cmd-shift-z. It opens each file/buffer by a window. By following a modern user interface, almost all points mentioned in this article are fixed in Aquamacs. For more info, see: Wikipedia Aquamacs↗ and Aquamac's home page at: Aquamacs.org ↗.

As a emacs variant, it does help in spreading the idea that emacs user interface should be modernized. However, a third-party variant software does not change the fact that GNU emacs itself needs to be modernized.

For example, suppose Microsoft Word remained with its DOS era interface, for example, file is opened with [Esc] (to open the menus), [T] (for Transfer), [L] (for Load). Suppose Microsoft hired a third party to release a variant called MS AquaWord. This would not help Microsoft Word the software itself or its image perceived by the populace, and is likely to complicate the issue around Microsoft Word.

Also, Aquamacs changes emacs to conform to Apple's user interface guidelines as much as possible. For example, besides changing the many shortcuts, Aquamacs open each file in a new window (i.e. what emacs calls frame). So, dired is opened in its own window. “shell-command” is opened in a new window. Emacs info files (C-h i) is opened in a new window. Using the graphical menu “Help:Aquamacs Help” launches Apple's help application. Aquamacs makes emacs palpable for Mac users, but in many ways, Aquamacs imposes a major change of operation for people already familiar with emacs. Its modernization of emacs, has priority with Mac application's system of operation over emacs system of operation.

Aquamacs is only a Mac application. Its user interface changes, is not wholly compatible with Microsoft Windows's user interface guidelines in minor details. (in particular, shortcut modifiers are different (Ctrl vs Cmd), and some shortcut keys differ) 90% of computer users world wide are familiar with Window's user interface and are using PC keyboards. If we consider improving emacs's user interface, then it is important to consider the familarity of vast majority of computer users.

In summary, when we consider modernization, we could create a version for Mac, a version for Windows, each follows as much as possible of each operating system's user interface guidelines. Alternatively, we can consider modernization based on emacs's unique ways of operation (as opposed changing emacs to comform to a particular company's UI standard that are currently most popular).

This attitude has plagued unix and computer geekers for decades. In the early 1990s (DOS and unix), tech geekers would sneer at graphical menus and mouse, with hordes of reasons how pure text interface, the command line, and or keyboard operations are sufficient and superior than graphical user interface or using a mouse. This seems ridiculous today, but such voices are commonly seen all over newsgroups. (Since about 1998, linuxes are in a frenzied race to copy whole-sale of Microsoft Windows's user interface ( KDE↗, GNOME↗, Lindows↗ ) trying to make itself easy-to-use.)

The reason for these type of attitude, is almost never a sensible alternative view about the topic in discussion, but a show of machismo. It is silly to retort “Why should emacs want to be popular?”. It is like asking “why do you want to live longer?” when someone is picky about healthy food, or “why should you want to look beautiful?” when someone dresses up.

We like emacs, we want emacs to be used by more people, we like more elisp programers. By improving emacs, as a side effect emacs will also be more popular. It is not a popularity contest.

The issue is not a individual's convenience. Let's say you lobby for greener planet. Then somebody retorts: “why don't you just plant more trees in your backyard?”.

Page created: 2006-04.
© 2006 by Xah Lee.