EMACS: The Extensible, Customizable Display Editor<br>- GNU Project - Free Software Foundation
EMACS: The Extensible, Customizable Display Editor
This paper was written by Richard Stallman in 1981<br>and delivered in the ACM Conference on Text Processing.
Table of Contents
Introduction
Background: Real-Time Display Editors
Applications of Extensibility
Customization<br>Operating on Meaningful Units of Text<br>Redefining Self-inserting Characters<br>Editing Programs<br>Editing Large Programs<br>Editing Other Things
The Organization of the EMACS System
Editing Language vs. Programming Language<br>The Library System and the Command Dispatcher<br>The Display Processor
Extensibility and Interpreters<br>Language Features for Extensibility
Global Variables<br>Dynamic Binding<br>Formal Parameters Cannot Replace Dynamic Scope<br>Variables Local to a File<br>Hooks<br>Errors and Control Structure<br>Non-local Control Transfers
Self-Documentation and Extensibility<br>History
Successors of EMACS
Conclusions
Research Through Development of Installed Tools<br>Lisp is Loose!<br>Blue Sky
Appendices
Display Processing<br>Libraries
Notes
EMACS Distribution<br>Further Information<br>EMACS-related Editors<br>Other Interesting Editors<br>Other Related Systems
Introduction
EMACS(1) is a real-time display editor which can<br>be extended by the user while it is running.
Extensibility means that the user can add new editing commands or change<br>old ones to fit his editing needs, while he is editing. EMACS is<br>written in a modular fashion, composed of many separate and independent<br>functions. The user extends EMACS by adding or replacing functions,<br>writing their definitions in the same language that was used to write<br>the original EMACS system. We will explain below why this is the only<br>method of extension which is practical in use: others are theoretically<br>equally good but discourage use, or discourage nontrivial use.
Extensibility makes EMACS more flexible than any other editor. Users are<br>not limited by the decisions made by the EMACS implementors. What we<br>decide is not worth while to add, the user can provide for himself. He<br>can just as easily provide his own alternative to a feature if he does<br>not like the way it works in the standard system.
A coherent set of new and redefined functions can be bound into a<br>library so that the user can load them together conveniently.<br>Libraries enable users to publish and share their extensions, which then<br>become effectively part of the basic system. By this route, many people<br>can contribute to the development of the system, for the most part<br>without interfering with each other. This has led the EMACS system to<br>become more powerful than any previous editor.
User customization helps in another, subtler way, by making the whole<br>user community into a breeding and testing ground for new ideas. Users<br>think of small changes, try them, and give them to other users--if an<br>idea becomes popular, it can be incorporated into the core system. When<br>we poll users on suggested changes, they can respond on the basis of<br>actual experience rather than thought experiments.
To help the user make effective use of the copious supply of features,<br>EMACS provides powerful and complete interactive self-documentation<br>facilities with which the user can find out what is available.
A sign of the success of the EMACS design is that EMACS has been<br>requested by over a hundred sites and imitated at least ten times.
Background: Real-Time Display Editors
By a display editor we mean an editor in which the text being edited is<br>normally visible on the screen and is updated automatically as the user<br>types his commands. No explicit commands to `print' text are needed.
As compared with printing terminal editors, display editor users have<br>much less need for paper listings, and can compose code quickly on line<br>without writing it on paper first. Display editors are also easier to<br>learn than printing terminal editors. This is because editing on a<br>printing terminal requires a mental skill like that of blindfold chess;<br>the user must keep a mental image of the text he is editing, which he<br>cannot easily see, and calculate how each of his editing command `moves'<br>changes it. A display editor makes this unnecessary by allowing the<br>user to see the `board'.
Among display editors, a real-time editor is one which updates the<br>display very frequently, usually after each one or two character<br>command the user types. This is a matter of the input command<br>language. Most printing terminal editors read a string of commands<br>and process it all at once; a useful feature on a printing terminal.<br>For example, there is usually an `insert' command which inserts a<br>string of characters. When such editors are adapted to display<br>terminals, they often update the display at the end of a command<br>string; thus, the insertion would be shown all at once when it was<br>over. It is more helpful to display each inserted character in its<br>position in the text as soon as it has been typed.
A real-time display editor has...