Emacs Modernization: Simple Changes Emacs Should Adopt
By Xah Lee. Date: . Last updated: .
Problem
Emacs is a great editor. It is perhaps the most powerful and most versatile text editor. And, besides text editing, it is also used as a email reader, newsgroup reader, ftp client, irc client, web browser, shell interface, file management application, scientific calculator, calendar and personal info management application, lisp language system, among other things. These seemingly wild functionalities are employed in production daily by a significant number of programers around the world. Some calls emacs as a Operating System as a joke. (Technically it does not qualify because a OS implies management of hardware.).
If emacs is such a great and powerful text editor why relatively few people use it? Vast majority of people who need to write will be more than happy to use editors other than emacs. Ask a Microsoft Windows user. She'll be more than happy to use Microsoft Word. If he doesn't have MS Word, he'll use NotePad or WordPad. If he is a programer, most will be more than happy to use any of other graphical editors on the Windows platform or any of the Integrated development environment such as Visual Studio, Eclipse, Xcode. In many cases, they are willing to pay money for it. Same is true on other operating systems, and new editors spring up here and there even though they don't have as much power or flexibility as emacs. For example, some popular ones are: Notepad++, gedit, NEdit, JEdit, BBEdit, TextMate, Sublime Text.
Many reasons can be made out of this. For example, emacs is not bundled on the popular operating system Windows, which are used by some 90% of computer users worldwide. Windows and Mac both have simple text editors bundled that will satisfy majority of computer users, which are non-professional computer users. (NotePad and WordPad on Windows, TextEdit on Mac) For the few professional computer users (secretaries, graphics artists, scientists, engineers, game developers, 3D-modelers, system administrators, programers), a majority will need a easy to use, yet powerful editor that also does styled text, formatting, and sundry light publishing needs such as table layout, simple line graphics drawing, embedded images, math formulas. They will choose and adopt Microsoft Word for their needs. The tiny percentage that might be interested in emacs, are programers.
If you take a survey of all professional programers (defined as those who makes a living primarily by writing code), i think, a vast majority, perhaps greater than 95%, do not use emacs.
A major difficulty among programers who do not use or like emacs, is that emacs's user interface is rather esoteric, involving arcane terminologies and keystrokes. This is in sharp contrast to the modern software applications used today, where their User Interface are similar and familiar to computer users.
The Common User Interface
The following is a excerpt from the Wikipedia article on Common User Access:
CUA was a detailed specification and set strict rules about how applications should look and function. Its aim was in part to bring about harmony between MS-DOS applications, which until then had implemented totally different user interfaces.
Examples:
- In WordPerfect, the command to open a file was F7 3.
- In Lotus 1-2-3, a file was opened with / (to open the menus), w (for Workspace), r (for Retrieve).
- In Microsoft Word, a file was opened with Escape (to open the menus), t (for Transfer), l (for Load).
- In WordStar, it was Ctrl+k+o.
- In Emacs, a file was opened with Ctrl+x followed by Ctrl+f (for
find-file).Some programs used Escape to cancel an action, some used it to complete one; WordPerfect used it to repeat a character. Some programs used End to go to the end of a line, some used it to complete filling in a form. F1 was often help but in WordPerfect that was F3. Insert sometimes toggled between overtype and inserting characters, but some programs used it for “paste”.
Thus, every program had to be learned individually and its complete user interface memorized. It was a sign of expertise to have learned the UIs of dozens of applications, since a novice user facing a new program would find their existing knowledge of a similar application absolutely no use whatsoever.
Simple Changes
In the following, i describe some critical changes that are also very easy to fix in emacs, which may be made by a single elisp programer within a single day, and has no impact on emacs's power. If emacs officially adopt these changes, i think it will make a lot people, at least programers, like emacs and choose emacs as their text editor.
All the following change proposals, simply makes emacs in sync with the behavior of modern applications, with no effect to emacs's power and flexibility.
Simple UI Changes
- {Cut, Copy, Paste, Undo} have shortcuts with x c v z keys. (turn on
cua-modeby default.) - Change the undo behavior so that there is a Undo and Redo. (bundle
undo-tree.el, turn it on.) - Get rid of the “*scratch*” buffer.
- Typing or Delete key deletes text selection if there's one. (turn on
delete-selection-mode.)
Note: the following items are fixed in emacs 23 (released in [see Emacs 23.1 Features (released 2009-07)]):
Highlight text selection.Make the up/down arrow keys move the cursor by a visual line, not by newline character.Text selection can be done by holding down the Shift key and pressing a arrow key.
Documentation Changes (for the User Documentation of Emacs (not Emacs Lisp Doc))
- Change the terminology of “Meta key” to “Alt key”, and replace the abbreviations “C-” by “Ctrl+” and “M-” by “Alt+”.
- Change the terminology of “kill” to “cut”, and “yank” to “paste”.
- Change the terminology of “keybinding” to “key” or “keyboard shortcut”. Use the term keybinding or binding only in a technical context, such as in elisp documentation.
- Switch the terminology of “window” and “frame” so it is compatible with standard terminology. That is, emacs's notion of “frame” should be called “window”, emacs's notion of “window” should be called “pane” or “frame”.
- Reduce the use of the word “buffer”. Call it “opened file”, “unsaved document”, “tab”, “window”, as appropriate.
Frequently Asked Questions
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, …}, 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'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'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 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:
- ① Is it easy to learn? (is it familiar to most people? Is it easy to remember?)
- ② 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?)
- ③ 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.
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.
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 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.
Spread the Awareness
Please consider this modernization proposal, and spread the idea.
If emacs officially adopt these very few simple, trivial to implement, and non-radical changes, perhaps emacs's user base will increase 5 fold in the next couple of years. Emacs old timers and elisp hackers wouldn't have to change their working habits a bit since they can TRIVIALLY make emacs behave the old way. The increased user base will be tremendous help in the continued emacs development and growth for the future generation of programers.
Other Web Resources
Addendum,
Here are some collection of web resources discussing the emacs modernization issues.
The following is a quote from Daniel LaLiberte, author of emacs lisp debugger Edebug (1994) and co-author of GNU Emacs Lisp Reference Manual.
Since the web grabbed my attention around 1994, I haven't done much of anything with Emacs, except I continue to be a reluctant user, stuck with emacs bindings to my brain, frustrated by its archaic UI as the world moves on. Now JavaScript is my favorite language, and the web browser would be the environment in which one might do everything, except we are not quite there yet.
—Daniel LaLiberte (http://www.hypernews.org/~liberte/), (Full text: Daniel_LaLiberte_on_emacs_doc.txt)
Steve Yegge, author of js2-mode (JavaScript mode with js grammar aware parser), and author of ejacs (JavaScript interpreter written in elisp), intended to make JavaScript a Emacs Lisp alternative. steve yegge blog on js2-mode (), steve yegge blog on js in elisp ().
Daniel Weinreb, co-founder of Symbolics, alludes to why emacs keybinding is the way they are. [see Daniel Weinreb on Emacs Keybinding]
Xah wrote:
Emacs's default cursor moving shortcuts are Ctrl+f, Ctrl+b, Ctrl+n,Ctrl+p. The keys f, b, n, p are scattered around the keyboard and are not under the home row.
Daniel wrote:
That's true. At the time Guy Steele put together the Emacs default key mappings, many people in the target user community (about 20 people at MIT!) were already using these key bindings. It would have been hard to get the new Emacs bindings accepted by the community if they differed for such basic commands. As you point out, anyone using Emacs can very easily change this based on their own ergonomic preferences.
from Hacker News https://ift.tt/3kveFCK
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.