Emacs Modernization: Simple Changes Emacs Should Adopt

I find the “*scratch*” buffer useful.

Suppose you have a feature 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 for vast majority of programers. 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-interaction-mode.) Majority of people who use emacs are not lisp coders. For lisp coders, they can just as simply open a new document and use it as scratch and default it to lisp mode.
• 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.

For more detail on this and a proposed fix and implementation, see Suggestions on Emacs's Scratch Buffer.

The Meta key is logical, it shouldn't be renamed to Alt.

The Meta key is simply the name of a special modifier key on lisp machine keyboards popularly used with emacs in the 1980s.

On a lisp machine 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. [see Emacs: How to define Super/Hyper Keys] The lisp machine keyboards fell out of use along with Lisp machine. The IBM PC keyboard (and its decendent the Microsoft Keyboards) became the most popular since the 1990s and is keyboard familiar to perhaps 99% of computer users. 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, because that is the keyboard 99% of computer users understand. 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.

For detail, see: Emacs M-x key Notation vs Alt+x Notation.

The Terminology “buffer” and “keybinding” is good as they are.

The terminology “buffer” or “keybinding”, are technical terms having to do with software programing. These terms are irrelevant to the users of a software.

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 action (command, function).

The term “buffer” refers to a abstract, temporary area for storing data, in the context of programing or computer science.

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, shell, email, irc, etc}, the proper term can be any of {tabs, panel, window, workspace}. (All other editors/IDEs use these terms, even though technically they are all implemented using 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 “tabs” or “keyboard shortcut”, but their contexts set them apart. This is why in all modern software application's user manual, they don't use these terms.

The reason emacs uses the technical terminologies throughout is because when emacs started in the 1980s, there has not been the concept of software application, or even other text editors. And, computer users are entirely computer scientists and programers.

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. [see Glossary - GNU Emacs Manual]

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

Emacs's undo is superior, because the prevalent Undo/Redo system actually loses info.

Emacs undo is very confusing and does not have a Redo command. To redo after a undo, people are told to type something then do undo twice. Long time emacs user argue that it is technically superior because it lets user 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 history. In the prevalent undo model, the action history 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 timeline 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 like a linear timeline. In emacs, every undo pushes a state to a stack. If we think in terms of a timeline 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 immediately undo twice), then a series of undos will traverse the timeline 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. Using emacs's undo is like riding a roller-coaster. In particular, once a person did more than once of “some random typing followed by undo twice”, 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 recent mistake. 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.

This issue is frequently debated on the net. Usually, some programer will complain about emacs's undo, and emacs die-hards will argue against it. Example: [Emacs undo is horrible At http://www.reddit.com/r/programming/info/6kscz/comments/ ]

See also:

• Emacs: Undo/Redo Saga
• Emacs Undo and Emacs Cult Problem (2011)

Emacs's ways are technically superior. It should not change.

Emacs's user interface, when compared to modern software application's user interface, is complex and unusual, however, there is 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 1970s.)

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:

• (1) Is it easy to learn? (is it familiar to most people? Is it easy to remember?)
• (2) Is it ergonomic and efficient? (Are most frequently used command'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?)
• (3) Is the shortcut system consistent and extensible?

Emacs's keyboard shortcuts system, is good only with respect to consistent extensibility. 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. Emacs's Control and Meta combinations are most cited as the major turn-off to potential users among programers. [see Famous Programers with Repetitive Strain Injury]

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 detail, see: Why Emacs Keys 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 1970s 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.

• 
  DEC VT100 Terminal

[see History of Key Shortcuts: Emacs, vim, WASD, Etc]

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 tested by having 2 team of programmers roughly equally experienced or skilled in using emacs. One team use Emacs with default UI setup, the other use 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.

[see GNU Emacs and XEmacs Schism, by Ben Wing]

Aquamacs already has the modernization you speak of.

Aquamacs is a emacs variant based on GNU 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 with ⌘ command and {c, x, v} keys. Open file is ⌘ command+o, saving is ⌘ command+s, save-as is ⌘ command+Shift+s. Close window is ⌘ command+w. Undo is ⌘ command+z, and there is a redo command by default, with shortcut ⌘ command+Shift+z. It opens each file/buffer in a new window. By following a modern user interface, almost all points mentioned in this article are fixed in Aquamacs.

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 Escape (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 (M-x info) is opened in a new window. Using the menu [Help ▸ Aquamacs Help] launches Apple's proprietary GUI-based 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's way of operation than emacs way.

Aquamacs is only a Mac application. Its user interface changes, is not wholly compatible with Microsoft Windows's user interface guidelines in minor details. (For example, shortcut modifiers are different (Ctrl vs ⌘ command), some shortcut keys differ, the ways to invoke menus differ.) Some 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 familiarity of computer users by majority.

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 conform to a particular company's UI standard that are currently most popular).

Why should emacs want to be popular and why should emacs change to conform the majority?

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

Douglas Crockford has documented tech geeker's resistance to change. See: [Crockford on JavaScript: Volume One: The Early Years 2010-01-25 By Douglas Crockford. At http://yuiblog.com/crockford/ , accessed on 2012-10-13 ]

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.

Why don't you make these changes yourself? It is easy.

The issue is not about one 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?”.

The change is too costly and or takes too much effort.

It doesn't take much work to make these changes. For the ones suggested in this article, it would take just one single elisp programer a couple of days to make all the suggested changes.

Note that in commercial orgs, major change that's a few order of magnitude more difficult has done in response to the changing industry. A good example is Apple computer, in its Motorola chip to PowerPC transition starting in 1994, Mac OS 9 to Mac OS X starting in 2001, and PowerPC to Intel chip starting in 2006.