EMACS: The Extensible, Customizable Display EditorEMACS: The Extensible, Customizable Display EditorThis paper was written by Richard Stallman in 1981and delivered in the ACM Conference on Text Processing.Table of ContentsIntroductionBackground: Real-Time Display EditorsApplications of ExtensibilityCustomizationOperating on Meaningful Units of TextRedefining Self-inserting CharactersEditing ProgramsEditing Large ProgramsEditing Other ThingsThe Organization of the EMACS SystemEditing Language vs. Programming LanguageThe Library System and the Command DispatcherThe Display ProcessorExtensibility and InterpretersLanguage Features for ExtensibilityGlobal VariablesDynamic BindingFormal Parameters Cannot Replace Dynamic ScopeVariables Local to a FileHooksErrors and Control StructureNon-local Control TransfersSelf-Documentation and ExtensibilityHistorySuccessors of EMACSConclusionsResearch Through Development of Installed ToolsLisp is Loose!Blue SkyAppendicesDisplay ProcessingLibrariesNotesEMACS DistributionFurther InformationEMACS-related EditorsOther Interesting EditorsOther Related SystemsIntroductionEMACS(1) is a real-time display editor which canbe extended by the user while it is running.Extensibility means that the user can add new editing commands or changeold ones to fit his editing needs, while he is editing. EMACS iswritten in a modular fashion, composed of many separate and independentfunctions. The user extends EMACS by adding or replacing functions,writing their definitions in the same language that was used to writethe original EMACS system. We will explain below why this is the onlymethod of extension which is practical in use: others are theoreticallyequally good but discourage use, or discourage nontrivial use.Extensibility makes EMACS more flexible than any other editor. Users arenot limited by the decisions made by the EMACS implementors. What wedecide is not worth while to add, the user can provide for himself. Hecan just as easily provide his own alternative to a feature if he doesnot like the way it works in the standard system.A coherent set of new and redefined functions can be bound into alibrary so that the user can load them together conveniently.Libraries enable users to publish and share their extensions, which thenbecome effectively part of the basic system. By this route, many peoplecan contribute to the development of the system, for the most partwithout interfering with each other. This has led the EMACS system tobecome more powerful than any previous editor.User customization helps in another, subtler way, by making the wholeuser community into a breeding and testing ground for new ideas. Usersthink of small changes, try them, and give them to other users--if anidea becomes popular, it can be incorporated into the core system. Whenwe poll users on suggested changes, they can respond on the basis ofactual experience rather than thought experiments.To help the user make effective use of the copious supply of features,EMACS provides powerful and complete interactive self-documentationfacilities with which the user can find out what is available.A sign of the success of the EMACS design is that EMACS has beenrequested by over a hundred sites and imitated at least ten times.Background: Real-Time Display EditorsBy a display editor we mean an editor in which the text being edited isnormally visible on the screen and is updated automatically as the usertypes his commands. No explicit commands to `print' text are needed.As compared with printing terminal editors, display editor users havemuch less need for paper listings, and can compose code quickly on linewithout writing it on paper first. Display editors are also easier tolearn than printing terminal editors. This is because editing on aprinting terminal requires a mental skill like that of blindfold chess;the user must keep a mental image of the text he is editing, which hecannot easily see, and calculate how each of his editing command `moves'changes it. A display editor makes this unnecessary by allowing theuser to see the `board'.Among display editors, a real-time editor is one which updates thedisplay very frequently, usually after each one or two charactercommand the user types. This is a matter of the input commandlanguage. Most printing terminal editors read a string of commandsand process it all at once; a useful feature on a printing terminal.For example, there is usually an `insert' command which inserts astring of characters. When such editors are adapted to displayterminals, they often update the display at the end of a commandstring; thus, the insertion would be shown all at once when it wasover. It is more helpful to display each inserted character in itsposition in the text as soon as it has been typed.A real-time display editor has (primarily!) short, simple commandswhich show their effects in the display as soon as they are typed. InEMACS, text (printing characters and formatting characters) isinserted just by typing it; there is no `insert' command. In otherwords, each printing character is a command to insert that character.The commands for modifying text are nonprinting characters, or beginwith nonprinting characters. Many-character commands echo if typedslowly; if there is a sufficiently long pause, the command so far isechoed, and then the rest of the command is echoed as it is typed.Aside from this, EMACS acknowledges commands by displaying theireffects.EMACS is not the first real-time display editor, but it derives muchappeal from being one. It is not necessary to know how to program, orhow to extend EMACS, to use it successfully.Applications of ExtensibilityTo illustrate and demonstrate the flexibility which EMACS derives fromextensibility, here is a summary of many of the features, available toEMACS users without the need to program, to which extensibility hascontributed. Many of them were written by users; some were written bythe author, but could just as well have been written by users.CustomizationMany minor extensions can be done without any programming. These arecalled customizations, and are very useful even by themselves. Forexample, for editing a program in which comments start with `<**'and end with `**>', the user can tell the EMACS commentmanipulation commands to recognize and insert those strings. This isdone by setting parameters which the comment commands refer to. It isnot necessary to redefine the commands themselves. Another sort ofcustomization is rearrangement of the command set. For example, someusers prefer the four basic cursor motion commands (up, down, left andright) on keys in a diamond pattern on the keyboard. It is easy toreassign the commands to these positions. It is also possible torearrange the entire command set according to a different philosophy.Operating on Meaningful Units of TextEMACS can be programmed to understand the syntax of the language beingedited and provide operations particular to it. Many major modesare defined, one for each language which is understood. Each major modehas the ability to redefine any of the commands, and reset anyparameters, so as to customize EMACS for that language. Files cancontain special text strings that tell EMACS which major mode to use inediting them. For example, `-*-Lisp-*-' anywhere in the firstnonblank line of a file says that the file should be edited in Lispmode. The string would normally be enclosed in a comment.For editing English text, commands have been written to move thecursor by words, sentences and paragraphs, and to delete them; to filland justify paragraphs; and to move blocks of text to the left or tothe right. Other commands convert single words or whole regions toupper or lower case. There are also commands which manipulate thecommand strings for text justifier programs: some insert or deleteunderlining commands, and others insert or delete font-changecommands.Many commands are controlled by parameters which can be used tofurther adapt them to particular styles of formatting. For example,the word moving and deletion commands have a syntax table that sayswhich characters are parts of words. There are two commands to editthis table, one convenient for programs to use and an interactive onefor the user. The paragraph commands can be told which strings,appearing at the beginning of a line, constitute the beginning of aparagraph. Such parameters can be set by the user, or by aspecification in the file being edited. But normally they are setautomatically by the major mode (that is, by telling EMACS whatlanguage the file is written in) and do not require attention from theuser.Redefining Self-inserting CharactersA very powerful extension facility is the ability to redefine thegraphic and formatting characters as commands. These characters,which include letters, digits and punctuation, are normally alldefined as commands to insert themselves into the text. Usefulalternate definitions for these characters usually insert thecharacter as usual, and then do additional processing which is in someway meaningfully associated with the insertion of that character.The single most useful command for editing text is the `auto-fillspace'. It is a program intended to be used as the definition of thespace character. In addition to inserting a space, it breaks the lineinto two lines if it has become too long. With the space characterredefined in this way, the user can type endlessly ignoring the rightmargin, and the text is divided into lines of a reasonable length. Ofcourse, this feature is not always desirable. It is turned on or offby redefining the space command. If the auto-fill space did notexist, any user could write it and also the command to turn it on andoff.A bolder use of redefinition of self-inserting characters is theabbreviation facility, part of the standard EMACS system but stillimplemented as an extension maintained by the user who wrote it. Theabbreviation facility allows the user to define abbreviations for words,and then type the abbreviations in order to insert the words. Forexample, if `cd' were defined as an abbreviation for`command', typing `i/o-cd' would insert `i/o-command'into the text. Abbreviation expansion preserves case, so `Cd'would expand into `Command'. Abbreviation works by redefining allpunctuation characters (the list of which can be altered bycustomization) to run a program which looks at the preceding word and,if it is a defined abbreviation, replaces it with its expansion.Yet another application of redefining printing characters is automaticparenthesis-matching. When this feature is in use, every time theuser inserts a close-parenthesis, the cursor moves briefly to thematching open-parenthesis, then back again. Automatic matching isespecially useful in editing Lisp code, but it is helpful with mostother programming languages also. It is implemented by redefining theclose-parenthesis character.Editing ProgramsExtensibility is especially useful for editing programs. One mightconceivably design in advance all the editing commands needed forediting English text, but each programming language has its own set ofuseful syntactic operations, which suggest useful editing commands.Because languages differ so much, simple customization is not in generalenough to implement familiar operations for a new language. A newextension package is required.EMACS commands have been written, for many languages, to move over orkill balanced expressions, to move to the beginning or end of afunction definition, and to insert or align comments. But the mostuseful editing operation for programs, and the first one to beimplemented for any programming language, is automatic indentation.The structure of a program can be made clear at a glance by adjustingthe indentation of each line according to its level of nesting. Mostprogramming communities attempt to indent code properly but do itmanually. Automatic indentation is used mostly by Lisp programmers.Automatic indentation was traditionally done by a program which wouldread in an entire source file, rearrange the indentation, and writeout a corrected source file. Such a tool has several disadvantages.For one thing, processing the entire file is likely to take a while.For another, the tool insists on imposing its own idea of properformatting, which the user cannot override. Even after a lot ofeffort is put into heuristics for good indentation, users are stilldissatisfied.Automatic indentation in EMACS is done incrementally. The Tabcharacter is redefined, as a command, to update the indentation of thecurrent line only, based on the existing indentation of the precedinglines. The Tab command is used on lines whose nesting haschanged. With it, the user can indent code properly as it is firsttyped in. If he does not agree with the Tab command's choice ofindentation, he can override it.Because the indentation function must understand the syntax of theprogramming language being edited, each language requires a separateindentation function. It is the job of the major mode for eachprogramming language to redefine the Tab character to run anappropriate indenter. Users can always use the same command to indent,no matter what sort of program they are editing. In addition, anotherediting command can do indentation by calling the current definition ofTab as a subroutine. (One such function is the one which indentsseveral consecutive lines.)Conventions such as this are vital, in an extensible system, forenabling unrelated extensions to avoid interacting wrong; one user canwrite an indentation function for a new language, while another userwrites new language-independent operations for requesting indentation,and the two automatically work properly together.Languages which have support for indentation include Lisp, Pascal,PL/I, Bliss, BCPL, Muddle and TECO.Comprehension of the user's program reaches its greatest heights forLisp programs, because the simplicity of Lisp syntax makes intelligentediting operations easier to implement, while the complexity of otherlanguages discourages their users from implementing similar operationsfor them. In fact, EMACS offers most of the same facilities aseditors such as the Interlisp editor which operate on list structure,but combined with display editing. The simple syntax of Lisp,together with the powerful editing features made possible by thatsimple syntax, add up to a more convenient programming system than ispractical with other languages. Lisp and extensible editors are madefor each other, in this way. We will see below that this is not theonly way.Editing Large ProgramsLarge programs are composed of many functions divided among manyfiles. It is often hard to remember which file a given function isin. An EMACS extension called the TAGS package knows how to keeptrack of this.The TAGS package makes use of a file called a tag table, which recordseach function in the program, stating what file it is defined in and atwhat position in the file. The tag table is made by running a specialprogram named TAGS, which is not part of EMACS. Once the tag table isloaded into EMACS, the command Meta--Period(2) finds the definition of any function, using theinformation in the tag table to select the proper file and find thefunction in it.The positions within the source file, remembered in the tag table, areused to find the function in the file instantly. Changing the filemakes the remembered positions inaccurate. If this has happened,Meta--Period searches in both directions away from the rememberedposition until it finds the definition. So small inaccuracies causeonly slight delays.When many new functions have been added, or moved from one file toanother, the TAGS program can reprocess the tag table into an updatedone. To make this more automatic, the tag table also remembers whichlanguage each source file is written in. This information is neededfor recognizing the function definitions in the file.Editing Other ThingsInteractiveness is useful in many activities aside from editing text.For example, reading and replying to mail from other users ought to beinteractive. Many of these activities occasionally involve textediting: for example, editing the text of a reply. If a specialeditor is implemented for the purpose, it can easily be much more workto write than all the rest of the system. It is easier to write theother interactive system within the framework of an extensible editor.EMACS has two extensions, RMAIL and BABYL, for reading mail. Commandsin RMAIL and BABYL are not like EMACS commands; typical commandsinclude `D' for `delete this message', and `R' for `reply to thismessage'. Editing the text of the reply is done with ordinary EMACScommands.DIRED is used for editing a file directory. The normal editingcommands, as extended, can be used to move the cursor through thedirectory listing. Other special commands defined only in DIREDdelete, move, compare or examine the file whose name is under thecursor.The INFO extension is designed for reading tree-structureddocumentation files. These files are divided textually into nodes,which contain text representing pointers to other nodes. INFOdisplays one node at a time, and INFO commands move from one node toanother by following the pointers.The Organization of the EMACS SystemThe primary components of the EMACS system are the text manipulationand I/O primitives, the interpreter, the command dispatcher, thelibrary system, and the display processor.The text and I/O primitives are used to operate on the text under thecommand of the program. The interpreter executes programs, using theprimitives when called for. The command dispatcher remembers whichprogram corresponds to each possible input character; it reads acharacter from the terminal and calls the associated function. Thelibrary system associates functions with their names anddocumentation, and allows groups of related functions to be loadedquickly together. The display processor updates the screen to matchthe text as changed by the text primitives; it is run whenever thereis nothing else to do.Editing Language vs. Programming LanguageAn EMACS system actually implements two different languages, the editinglanguage and the programming language. The editing language containsthe commands users use for changing text. These commands areimplemented by programs written in the programming language. When wespeak of the interpreter, we mean the one which implements theprogramming language. The editing language is implemented by thecommand dispatcher.Previous attempts at programmable editors have usually attempted tomix programming constructs and editing in one language. TECO is theprimary example of this sort of design. It has the advantage thatonce the user knows how to edit with the system, he need only learnthe programming constructs to begin programming as well.However, there are considerable disadvantages, because what is good inan editor command language is ugly, hard to read, and grosslyinefficient as a programming language. A good interactive editinglanguage is composed primarily of single character commands, with afew commands that introduce longer names for less frequently usedoperations. As a programming language, it is unreadable if the editoris to be customizable, the user must be able to redefine eachcharacter. This in a programming language would be intolerable!When the programming language is the editing language, the built-inediting commands and the primitive operations they use have to bewritten in another language. Then the user cannot change part of thestandard system slightly by making a small change to its definition;it has to be reimplemented from scratch as a macro. Since theprimitives available are only the commands he uses for editing, thiswill often be impossible because the necessary primitives will beinternal routines that the user cannot call. The primitives that anextension would like to use are not always the same as the editingoperations the user wants.The implementor of a macro processor is encouraged to ignore suchdeficiencies because he himself does not use the language inimplementing the rest of the system. Since it is traditional, indesigning a macro language, to ignore the standards of readability,power and robustness typically applied to the design of programminglanguages, these deficiencies are usually considerable. The originalTECO is a good example of this sort of problem.In EMACS, each language is designed for its purpose. The editinglanguage has single-character redefinable commands. The programminglanguage is TECO, modified and extended to be more suitable forwriting well-structured and robust programs, and to provide theprimitives needed by editing programs as opposed to editor users. Itremains hard to read, so the descendents of EMACS generally use Lispinstead. TECO was used only for reasons of historical convenience.More information on the requirements extensibility imposes on thesystem's programming language is in the next chapter.The Library System and the Command DispatcherAn important part of any practical extensible system is the ability touse more than one extension at one time, and begin using an additionalextension at any time. Extensions should be able to override orreplace parts of the standard system, or previous extensions. InEMACS the library system is responsible for accomplishing this.An EMACS library is a collection of function names, definitions anddocumentation that can be loaded into an EMACS in mid-session.Libraries are read-only and position-independent, so that they can beloaded just by incorporating them into the virtual memory of the EMACS.This allows all EMACSs using a library to share the physical memory.Each library contains its own symbol table which connects function nameswith definitions, and also with their documentation strings. Librariesare generated from source files in which each function definition isaccompanied by its documentation; this encourages all functions to bedocumented.When a function name is looked up, all the loaded libraries aresearched, most recently loaded first. For the sake of uniformity, thestandard EMACS functions also reside in a library, which is always thefirst one loaded. Therefore, any library can override or replace thedefinition of a standard EMACS function with a new definition, whichwill be used everywhere in place of the old. This, together with thefact that EMACS is constructed with explicit function calls to namedsubroutines at many points, makes it easy for the user to change partsof the system in a modular fashion without replacing it all.Subroutines are normally called by their full names. The user can alsocall any command by name, and many commands are primarily intended to beused in that way. However, the most common editing operations need tobe more easily accessible. This is the purpose of the commanddispatcher, which reads one character and looks it up in thedispatch table, a vector of definitions to find the function tobe called (the definition-object, not the name).Functions residing in the dispatch table can be invoked either by thecharacter command or by name. A function which does not appear in thedispatch table can be called only by name. The user calls functions byname by means of a single-character command (Meta--X) whosedefinition is to read the name of a function and call that function.Each user has his own patterns of use. Many functions in EMACS areaccessible only by name because we expect most users to use theminfrequently. If a particular user uses one such command often, he canplace the definition in the dispatch table using the function Set Key.The function calling conventions are designed so that almost anyfunction definition will behave reasonably if called by the commanddispatcher. If a function tries to read a string argument from itscaller, then when called by the command dispatcher it will automaticallyprompt and read the argument from the terminal instead.(3)Some libraries contain functions that are intended to be called withsingle character commands. The library can arrange to place thosefunctions' definitions in the dispatch table by defining a functioncalled Setup. This will be called automatically when the library isloaded, and it can redefine character commands as needed. However,because EMACS is intended to be customized, no library can reasonablymake the assumption that a function belongs on a particular characterwithout allowing the user who loads the library to override thatassumption. For example, a library might wish to redefineControl--S on the assumption that it invokes the search function,but a user might prefer to keep his search on Control--T instead,and he might prefer that same library to alter the definition ofControl--T when loaded by him. The author of the library cannotanticipate the details of such idiosyncrasies, but he can provide forthem all by following a convention: in the Setup function of the library(TAGS, say), he checks for a variable called TAGS Setup Hook, andif it exists, its value is called as a function instead of the usualsetting up.The Display ProcessorThe display processor is the part of EMACS which maintains on thedisplay screen an up-to-date image of the text inside the editor.Since the size of the screen is limited, only a portion or `window'can be shown. The display processor prefers to continue to start itsdisplay at the same point in the file, so as to minimize the amount ofchanges necessary to the screen. However, the text where the editor'sown cursor is located must appear on the screen so that the terminal'scursor can show where it is. This sometimes forces a new windowposition to be computed. The user can also command changes in thewindow position, moving the text up or down on the screen.The EMACS display processor embodies an unusual principle which makesfor much faster responses to the user: display updating has lowerpriority than cogitation.Most display editors change the display after each user command. Thisis the simplest strategy to implement, since each command knowsprecisely how it has changed the text. But it is very inefficient,not just of the computer's time, but of the user's time, because itmakes the user wait for the completion of display updates that havealready been made obsolete by further commands waiting to be executed.Here is an example of the problem. If the user types CarriageReturn to create a new line, all the lines below that point need to beredisplayed in their new positions.While this is still going on, if he types an additional CarriageReturn to create another new line, the rest of the display update isobsolete; there is no use displaying the rest of the lines in theirsecond positions, only to display them again in their thirdpositions.(4)The EMACS display processor is best understood as being a separate,lower priority process that runs in parallel with the editing process.The editing process reads keyboard input and makes changes in thetext. The display process is always trying to change the screen tomatch the text; it keeps a record of what is on the screen, and ineach cycle of operation finds one discrepancy between the editingbuffer and the screen record and corrects it. After each cycle, thedisplay process can be pre-empted by the editing process, which hashigher priority. The display process can be thought of as chasing anarbitrarily moving target, the edited text, with a speed limited bythe terminal baud rate.Multiple processes are not actually used in the implementation.Instead, after each line of display output, the display processorupdates its data base and polls for input.An additional benefit of this input-before-output philosophy is thatit uses less computer resources when the system is heavily loaded.When not enough computer power is available, EMACS gets behind inprocessing the user's input. When the first command is completed,more input is available, so no effort is put into display updatingyet. By saving computer time this way, EMACS eventually catches upwith the user and does its display updating all at once.Since display updating is not necessarily done at the same time as theediting operation which necessitates it, display updating cannot bethe responsibility of the editing command itself. Instead, thedisplay update must be done by somehow comparing the hew text with theprevious displayed text, or information about it. In EMACS, eachediting command returns information on the range of text it haschanged, but aside from that the display processor operatesindependently. This is good for extensibility as well: it is easierto write or change an editing command if it does not have to containalgorithms for updating the screen.Because the TECO language is not very efficient, the display processorhad to be written in assembler language to get adequate performance.This is unfortunate because extensions to the display processor couldbe very valuable. In later implementations of EMACS, the displayprocessor is written in Lisp along with the editing commands, and canbe extended.Extensibility and InterpretersDespite its syntactic obscurity, TECO is actually one of the bestlanguages to use for implementing an extensible editor. This isbecause most traditional programming languages simply cannot do thejob! Implementing an extensible system of any sort requires featuresthat they intrinsically lack. Specifically, it requires a languagewith an interpreter and the ability for programs to access theinterpreter's data structures (such as function definitions).Adherents of non-Lisp programming languages often conceive ofimplementing an EMACS for their own computer system using PASCAL, PL/I,C, etc. In fact, it is simply impossible to implement an extensiblesystem in such languages. This is because their designs andimplementations are batch-oriented; a program must be compiled and thenlinked before it can be run. An on-line extensible system must be ableto accept and then execute new code while it is running. Thiseliminates most popular programming languages except Lisp, APL andSnobol. At the same time, Lisp's interpreter and its ability to treatfunctions as data are exactly what we need.(5)A system written in PL/I or PASCAL can be modified and recompiled, butsuch an extension becomes a separate version of the entire program.The user must choose, before invoking the program, which version hewants. Combining two independent extensions requires comparing andmerging the source files. These obstacles usually suffice todiscourage all extension.The only way to implement an extensible system using an unsuitablelanguage, is to write an interpreter for a suitable language and thenuse that one. Prime is now implementing an EMACS using a simple Lispwritten in PL/I. This technique works because an editor does notrequire a very efficient interpreter; even the most straightforwardLisp interpreter is more efficient than the TECO interpreter which isempirically observed to be good enough. I would not regard this asimplementation `in' the original language, however.A PASCAL or PL/I implementation which uses an interpreter, and allowsthe user program to access the interpreter data structuressufficiently, could be used just as a Lisp implementation would beused. However, such implementations are very rare, because theselanguages are not designed for them. If the implementor appreciatesthe importance of the interpreter, and of treating functions as data,he will usually choose to implement Lisp.It is also possible to use dynamic linking--the ability to loadadditional modules of compiled code during execution, and refer tosubroutines therein by name--in place of an interpreter. However,dynamic linking operating systems are rarer than good Lisps, harder toimplement, and not as convenient for the job. One of the few suchoperating systems, Multics, has an EMACS written in Lisp. SINE, theEMACS implementation on Interdata computers, uses dynamic linking toload files compiled from a language which resembles Lisp.Language Features for ExtensibilityWhen a language is used for implementing extensible systems, certaincontrol structure and data structure features become vital.Global VariablesOne difference between Lisp (and TECO) and most other programminglanguages, which is very important in writing extensible systems, isthat variable names are retained at run time; they are not lost incompilation.In typical compiled languages, variable names are meaningful only atcompile time. In the compiled code, uses of one variable name becomereferences to one location in memory, but the name itself has beendiscarded.By contrast, Lisp remembers the connection between variable names andtheir values, so that new programs can be defined.Global variables are essential for parameters used for customization.EMACS has a variable named Comment Start which controls thestring recognized as starting a comment in the text being edited. Itsvalue is supposed to be that string. This variable is used by thecomment indenting command to recognize an existing comment. The factthat the variable name is known at run time enables the user toask to see the value of the string.change the string.define or redefine major modes, for various programming languages whichchange the string.define or redefine comment-manipulation commands, which refer to thevariable so that they will work on text in various languages.Dynamic BindingMost batch languages use a lexical scope rule for variable names.Each variable can be referred to legally only within the syntacticconstruct which defines the variable.Lisp and TECO use a dynamic scope rule, which means that each binding of avariable is visible in all subroutine calls to all levels, unless otherbindings override. For example, after(defun foo1 (x) (foo2))(defun foo2 () (+ x 5))then (foo1 2) returns 7, because foo2 when called withinfoo1 uses foo1's value of x. If foo2 iscalled directly, however, it refers to the caller's value of x,or the global value. We say that foo1 binds the variablex. All subroutines called by foo1 see the binding made byfoo1, instead of the global binding, which we say isshadowed temporarily until foo1 returns.In PASCAL the analogous; program would be erroneous, because foo2has no lexically visible definition of x.Dynamic scope is useful. Consider the function Edit Picture,which is used to change certain editing commands slightly, temporarily,so that they are more convenient for editing text which is arranged intotwo-dimensional pictures. For example, printing characters are changedto replace existing text instead of shoving it over to the right.Edit Picture works by binding the values of parameter variablesdynamically, and then calling the editor as a subroutine. The editor`exit' command causes a return to the Edit Picture subroutine,which returns immediately to the outer invocation of the editor. In theprocess, the dynamic variable bindings are unmade.Dynamic binding is especially useful for elements of the commanddispatch table. For example, the RMAIL command for composing a reply toa message temporarily defines the character Control--Meta--Y toinsert the text of the original message into the reply. The functionwhich implements this command is always defined, butControl--Meta--Y does not call that function except while a replyis being edited. The reply command does this by dynamically binding thedispatch table entry for Control--Meta--Y and then calling theeditor as a subroutine. When the recursive invocation of the editorreturns, the text as edited by the user is sent as a reply.It is not necessary for dynamic scope to be the only scope ruleprovided, just useful for it to be available.Formal Parameters Cannot Replace Dynamic ScopeSome language designers believe that dynamic binding should be avoided,and explicit argument passing should be used instead. Imagine thatfunction A binds the variable FOO, and calls the function B,which calls the function C, and C uses the value of FOO.Supposedly A should pass the value as an argument to B, which shouldpass it as an argument to C.This cannot be done in an extensible system, however, because theauthor of the system cannot know what all the parameters will be.Imagine that the functions A and C are part of a user extension, whileB is part of the standard system. The variable FOO does not exist inthe standard system; it is part of the extension. To use explicitargument passing would require adding a new argument to B, which meansrewriting B and everything that calls B. In the most common case, Bis the editor command dispatcher loop, which is called from an awfulnumber of places.What's worse, C must also be passed an additional argument. B doesn'trefer to C by name (C did not exist when B was written). It probablyfinds a pointer to C in the command dispatch table. This means that thesame call which sometimes calls C might equally well call any editorcommand definition. So all the editing commands must berewritten to accept and ignore the additional argument. By now, none ofthe original system is left!Variables Local to a FileSuppose one file is formatted with comments starting at column 50.Editing this file is easier if the variable Comment Column, whichis used (by convention) to decide where to align comments, is always setto 50 whenever this file is being editing. EMACS provides a way torequest this; but since it also provides the feature of visiting severalfiles at once, it must take special care to keep each file's variablesstraight. Suppose one file wants Comment Column to be 50 whileanother is formatted with 40?This is solved by allowing each file to have its own local values forany set of variables. Specially formatted text at the end of the filespecifies them:Local Modes:Comment Column:50End:When a file is brought into EMACS, this local modes list is parsed andthe variables and values remembered in a local symbol table. Whilethe file is not selected, its local symbol table contains the localvalues of the variables. While a file is selected, its local symboltable contains the global values, and the real symbol table containsthe file's local values instead.HooksWhen an extensible system allows the user to provide a function to becalled on certain well-defined occasions, we call it a hook. Forexample, we have already mentioned the hook which is executed whenever acertain library is loaded; for the TAGS library, the hook is namedTAGS Setup Hook.Another important class of hooks is executed when a major mode isentered. Each major mode has its own hook. For example, Text mode'shook is named Text Mode Hook. This hook can be used to requestarbitrary actions in advance for each time text mode is entered. Manyusers always define this hook to turn on Auto Fill mode, so that AutoFill mode is always on when Text mode is.Hooks can be associated with variables as well. Then, each time thevalue of the variable changes, its hook is run. Usually these hooks areused to change other data structures so that they always correspond tothe value of the variable. This is often more efficient and moremodular than checking the variable itself whenever its value isrelevant. For example, changing the value of Auto Fill Mode toturn auto-filling on or off calls a function which automaticallyredefines the Space character's command definition.Some hooks are attached to specific points within the interpreter ordisplay processor. For example, there is a hook which is calledwhenever it is time to read a character of input from the terminal.The hook program can supply the character itself. These hooks can bethought of as compensating for the fact that some parts of the systemare written in assembler language and cannot simply be redefined bythe user.Errors and Control StructureA system for programming editor commands needs more sophisticatedfacilities for handling errors and other exceptional conditions thanmost programming systems provide. Let us consider what an error is,and what ought to happen when there is an error.First of all, what exactly is an error? Sometimes the user asks to dosomething that cannot be done (a user error). Sometimes a programasks to do something which cannot be done (a program error). Programerrors often accompany user errors, but either one can happen withoutthe other.Program errors can be defined objectively: any event which executes acertain part of the interpreter is a program error. User errorscannot be defined objectively in this way because they are a matter ofattitude toward events rather than events themselves. If a commandhas done nothing, we can regard this either as the response to anerror or as normal functioning. And this choice of attitude has nonecessary connection with whether the command definition requiredspecial code to make it do nothing in the circumstances in question.When a program error happens, EMACS prints the error message and thengives the user the chance to invoke the error handler to debug it. Ifhe does not do this, control returns to the innermost error returnpoint. Programs can create error return points with a specialconstruct. (We use a Lisp-style syntax in these examples forclarity).(error-return (arbitrary-code-here))The end of the error-return construct becomes an error return pointwhich is in effect while the code inside the construct is beingexecuted. Error returns are usually used by loops which read andexecute commands of some sort, including the built-in one which readsand displays editing commands.(do-forever (error-return (read-and-execute-one-command)))Sometimes interpreted functions are called asynchronously orunpredictably. An example is the one which optionally saves the textevery so often to reduce the amount lost if the system crashes. If thisfunction gets a program error, it should notify the user, but should notinterfere in any way with the user's explicit commands. This requires aconstruct known in Lisp as errset, which prevents allnormal processing of errors that occur within it. An error occurringwithin an errset does nothing but return control immediately to the endof the errset.The programming system does not provide any such uniform handling foruser errors because the concept of a user error is not defined at thatlevel. Instead, the designer of each editing command must decide whatconditions ought to be considered errors, and what to do in each case.Sometimes the command simply does nothing. Sometimes it rings theterminal's bell and perhaps throws away type ahead. This can be best ifwe expect that, once the user is told that there is something wrong, itwill be obvious what it is. When the cause of the error is lessobvious, causing a program error deliberately with a specially chosenerror message is a good way of informing him. A special primitive isused to cause a program error with an arbitrary specified error messageso that the error-return processing can be invoked.Sometimes the user error leads naturally to an error in the program,which may be all the handling it needs. This can be so if the programerror's error message is an adequate explanation for the user, or ifthe situation is not deemed likely enough to deserve the effortrequired to make anything else happen.The error handler for debugging program errors is an interpretedprogram itself. This is possible because primitives are provided forexamining the function call stack and all other data structures whichthe programmer would want to examine while debugging. Users haveactually written extensions and complete replacements for the standarderror handler program.Non-local Control TransfersReturning to the example of the user-written command loop, there has to be acommand to exit the loop. How can it be done?(do-forever (error-return (read-and-execute-one-command)))We do it by means of a non-local control transfer. We create thetransfer point by means of a catch construct around the loop.The catch creates a named transfer point at the end of the loop, whichis accessible only within the loop.(catch (do-forever (error-return (read-and-execute-one-command))) exit-my-loop)At any time during the loop, execution of (throw exit-my-loop)transfers control immediately to the end of the catch, thus exiling theloop. The catch and throw constructs were copied from Maclisp.Like variable names, catch names have dynamic scope: the program canthrow to a catch from any of the subroutines called while inside thecatch. This is important because ease of extension dictates that eachcommand which the command-reading loop understands be implemented by aseparate function, so that the user can redefine one command withoutreplacing the framework of the loop.(6)Self-Documentation and ExtensibilityA complex program is much easier to learn if it can answer questionsabout how to use it. When the program is customizable, it isimportant for the answers to reflect any customization that has beendone. The easiest way to do this is for questions to be answeredbased on the same tables and data structures that control thefunctioning of the system. In EMACS, these include the commanddispatch table and the loaded libraries.The most basic kind of question that a user might want to ask is,"What does this command do?" He can inquire about either a functionname or a command character. A library contains a documentationstring for each function in it, and this is used to answer thequestion. When the question is about a command character, thedispatch table is used to find the function object which is currentlythe definition of that character. Then the library system is used tofind the name of the function, and then, from that, the documentationstring.The ability to ask what a certain command does only helps users whoknow what commands to ask about. Other users need to ask, "Whatcommands might help me now?" EMACS attempts to answer this by listingall the functions whose names contain a given substring. Since thefunction names tend to summarize what the functions do (such as`Forward Word' or `Indent for Comment') and follow systematicconventions, this is usually enough. The list also contains the firstline of each function's own documentation, and how to invoke thefunction with one or two characters, if that is possible.The documentation for a function is usually just a string of text, butit can also contain programs to be executed to print the documentation,interspersed with text to be printed literally. This comes in handywhen the description of one function refers to another function which isusually accessed as a one or two character command. It is better totell the user the short command, which he would actually use, than thename of the function which defines it. But exactly which command--ifany--runs the function in question depends on the user's customization.What we do is to use a program, in the middle of the documentationstring, which searches the dispatch table and prints the command whichwould invoke the desired function. Another application of this facilityis for functions which simply load a library and call a function in it.The documentation string for such functions is a program to load thelibrary and print the documentation of the function which would becalled.To help users remember how to ask these questions, we make it simpleand standard. A special character, called the Help character, isused. This character is only used for asking for help, and is alwaysavailable. Help is normally followed by another character whichspecifies the type of inquiry. If the user does not remember thesecharacters, he can type Help again to see a list of them. To closethe remaining loophole of confusion, EMACS prints a message about theHelp character each time it starts up.Help is also available in the middle of typing a command. Forexample, if you start to type the Replace String command and forgetwhat arguments are required, type Help. The documentation of theReplace String function will be printed to tell you what to do next.Because questions are answered based on the data structures as theyare at the moment, many changes in EMACS require no extra effort toupdate the documentation. It is only necessary to update thedocumentation of each function whose definition is changed. Theformat for EMACS library source files encourages this by requiring adocumentation string for every function, between the function name andits definition.HistoryI began the development of EMACS in 1974 with an improvement to TECO:the implementation of the display processor and a command dispatcherwith a small fixed set of commands. These were inspired by the editorE of the Stanford Artificial Intelligence Lab. They were notconsidered a new editor, but rather one new feature in TECO to joinmany existing features. The user would give the TECO commandControl-R to enter display editing mode, whose commands were suitableonly for making local changes to the file. He would exit displayediting mode to do anything else.But once display editing was implemented, it was fairly easy to allowcommands to be redefined to call functions written in TECO. TECOalready contained considerable facilities for text manipulation, I/O,and programming, so almost immediately many users began to implementlarge collections of editing commands, powerful enough to do every partof editing. One of the most popular of these systems was TECMAC.Others included MACROS, RMODE, TMACS, Russ-mode and DOC. The need toexit from display editing mode to use TECO directly became less and lessfrequent until new users no longer learned how.But TECO was still missing many at the important control andprogramming constructs which allow programs to be readable andmaintainable (for example, named functions and variables!). So theearly TECO-based display editors were very hard to maintain. In 1976the TMACS system experimented with adding named functions andvariables, with good results limited by the inefficiency ofimplementing them with TECO programs. This inspired me to implementEMACS itself.Writing EMACS involved simultaneously adding to TECO the featureswhich make up the library system and self-documentation, whichpermitted a new readable programming style, and writing a new set ofdisplay editing commands using this style. The design for thecommands themselves was based on examining the command sets of themany TECO-based editors for inspiration, and choosing commands so thatthe most common operations would take few keystrokes. The firstoperational EMACS system existed in late 1976.Since then, development has proceeded steadily, most new code beingwritten in TECO. New features are added to TECO itself only to speedup loops such as table searching and s-expression parsing, or to makepossible new kinds of I/O or interface operations.EMACS was developed on the Digital Equipment Corporation PDP--10computer using MIT's own Incompatible Timesharing System. By 1977,outside interest in EMACS was sufficient to motivate Mike McMahon ofSRI International to adapt it to Digital's Twenex (`Tops--20')operating system. EMACS is now in use at about a hundred sites.Successors of EMACSSeveral post-EMACS editor implementations have copied from EMACS boththe specific command set and user interlace and the fundamentalprinciple of being based on a programmable interpreter. Themotivation for these projects was to transfer the ideas of EMACS toother computer systems. Two of them, now in use, are Multics EMACS, aHoneywell product, and ZWEI, the editor for the MIT ArtificialIntelligence Lab Lisp machine.Because EMACS supplied the implementors with a clear idea of what was tobe implemented, their focus was on making the foundations clean. Theessential improvement was the substitution of an excellent programminglanguage, Lisp, for the makeshift extended TECO used in EMACS. Lispprovides the necessary language features in a framework much cleanerthan TECO. Also, it is more efficient. A Lisp interpreter isintrinsically more efficient than a string-scanning interpreter such asTECO's, and Lisp compilers are also available. This efficiency isimportant not just for saving a few microseconds, but because it reducesthe amount of the system which must be written in assembler language inorder to obtain reasonable performance. This opens more of the systemto user extensions. Another improvement has been in the data structureused to represent the editing buffer: Multics EMACS developed thetechnique of using a doubly-linked list of lines, each being a string.This technique is used in ZWEI as well.Many other editors imitate the EMACS command set and display updatingphilosophy without providing extensibility. Despite that deficiency,and despite the greatly reduced set of features that results from it,these can be useful editors, though not as useful as an extensible one.For a computer with a small address space or lacking virtual memory,this is probably the best that can be done.(7)The proliferation of such superficial facsimiles of EMACS has anunfortunate confusing effect: their users, knowing that they are usingan imitation of EMACS, and never having seen EMACS itself, are led tobelieve that they are enjoying all the advantages of EMACS. Since anyreal-time display editor is a tremendous improvement over what theyprobably had before, they believe this readily. To prevent suchconfusion, we urge everyone to refer to a nonextensible imitation ofEMACS as an `Ersatz EMACS'.ConclusionsResearch Through Development of Installed ToolsThe conventional wisdom has it that when a program intended formultiple users is to be written, specifications should be designed inadvance. It this is not done, the result will be inferior. The placeto try anything new is in a research project which users will not see.Some people know better than this, but they have been silenced.The development of EMACS followed a path that most authorities wouldsay is a direct route to disaster. It was the continuous deformationof TECO into something which is totally unlike TECO, from the typicaluser's point of view. And during the whole process, TECO and programscontaining TECO were the only text editors we had on ITS.(8) Indeed, there are ways in whichEMACS shows the results of not having been completely thought out inadvance: such as, in being based on TECO rather than Lisp. But it isstill reliable enough to be widely used and imitated. The disasterwhich would have been forecast has not occurred. Instead, a new andpowerful way of constructing editors has been explored and shown to begood.I believe that this is no accident. EMACS could not have been reachedby a process of careful design, because such processes arrive only atgoals which are visible at the outset, and whose desirability isestablished on the bottom line at the outset. Neither I nor anyoneelse visualized an extensible editor until I had made one, norappreciated its value until he had experienced it. EMACS existsbecause I felt free to make individually useful small improvements ona path whose end was not in sight.While there was no overall goal, each small change had a specificpurpose in terms of improving the text editor in general use, and eachstep had to be individually well designed and reliable. This helped tokeep things on the right track. Research projects with no users tend toimprove the state of the art of writing research projects, rather thanthe state of the art of writing usable system tools.The individual commands of EMACS benefited from a stage of unregulatedexperimentation also. When the display processor and the capabilityfor extension were created, many users began to write extensions,which developed into the complete editing environments of which EMACSis the most recent. Each command in EMACS benefits from theexperimentation by many different users customizing their editors indifferent ways since that time. This experimentation was possibleonly because a programmable display editor existed.New implementations of EMACS can now be carefully designed, becausethey have the advantage of hindsight based on the original EMACS.However, the implementor must carefully restrict his careful design tothe parts of the editor that are already well understood. To gobeyond the original EMACS, he must experiment. But why isn't such aprogram of exploration doomed to be sidetracked by a blind alley,which will be unrecognized until too late? It is the extensibility,and a flexibility of mind, which solves this problem: many alleys willbe tried at once, and blind alleys can be backed out of with minimalreal loss.Lisp is Loose!The traditional attitude towards Lisp holds that it is useful only foresoteric amusements and Artificial Intelligence. The appearance ofMultics EMACS as a Honeywell product is the death knell of this view.Now, a mainframe manufacturer is offering a system utility programwritten in Lisp; a program intended for heavy use by the general usercommunity. The special properties of Lisp, which make extensibilitypossible, are a key feature, even though many of the users will not beprogrammers. Lisp has escaped from the ivory tower forever, and is aforce to be reckoned with as a system programming language.Blue SkyThe programmable editor is an outstanding opportunity to learn toprogram! A beginner can see the effect of his simple program on thetext he is editing; this feedback is fast and in an easily understoodform. Educators have found display programming to be very suited forchildren experimenting with programming, for just this reason (seeLOGO).Programming editor commands has the additional advantage that aprogram need not be very large to be tangibly useful in editing. Afirst project can be very simple. One can thus slide very smoothlyfrom using the editor to edit into learning to program with it.When large numbers of nontechnical workers are using a programmableeditor, they will he tempted constantly to begin programming in thecourse of their day-to-day lives. This should contribute greatly tocomputer literacy, especially because many of the people thus exposedwill be secretaries taught by society that they are incapable of doingmathematics, and unable to imagine for a moment that they can learn toprogram. But that won't stop them from learning it if they don't knowthat it is programming that they are learning! According to BernardGreenberg, this is already happening with Multics EMACS.AppendicesDisplay ProcessingThe way EMACS records what remains on the screen, and compares it withwhat is now in the text being edited, is determined by therepresentation used for that text. The post-EMACS editors use bettertext representations that make for easier display updating algorithms.The representation used in EMACS is a straightforward linear string ofcharacters. A movable gap which can grow and shrink makes itunnecessary for insertion and deletion within a small region of thefile to move half of the file up and down. The gap was essential inmaking it practical to insert characters one at a time, instead of enmasse in an `insert' command, but aside from that it is made invisibleat all but the lowest levels of software, so essentially therepresentation is just a linear string. It is the task of the displayprocessor's auxiliary data to make sense out of the amorphous mass oftext.The lowest level of avoiding wasteful output is a checksum of thecharacters displayed on each line of the screen. It a screen line isabout to be rewritten, the new and old checksums are compared. If theymatch, the rewriting is skipped. Once in every2^36times this will leave old incorrect text on the screen.Higher levels of display optimization work by preserving informationwhich is a byproduct of writing the display--namely, where in the textstring the beginning of each screen line comes--and combining it withinformation which localizes the regions of the text string in whichalteration has taken place. This allows it to restrict display updateprocessing to a horizontal band of screen which contains all thenecessary changes (often just one line). While processing the otherlines on the screen would do no actual output, because of the checksums,even the time to compute the checksums is noticeable to the user as adelay. The same information can be used to decide when some lines onthe screen should be moved up or down. When lines are inserted in themiddle of the screen, it is much better to scroll the following linesdownward (if the terminal can do this) than to rewrite them all in theirnew positions.The record of where in the text string changes have taken place ismaintained by requiring every command to return values saying what partof the string it has changed. It can identify a subinterval of thestring which contains all the changes made, it can say that no changewas made (though the cursor may have been moved), or it can say nothing,which requires the display processor to make no assumptions.A better way, developed by Bernard Greenberg in Multics EMACS and usedin ZWEI, is to represent the buffer as a doubly-linked list containingpointers to strings, one for each line. Newline characters are notactually present, but implicitly appear after each line except the last.This requires the lowest level insert, delete and search subroutines tobe more complicated (for example, inserting a string cannot treatNewline characters like other characters), but this is just a finiteamount of complexity; and it greatly simplifies efficient displaycomputations. The state of the screen can be remembered in an array ofpointers to the string that was displayed on each screen line. When thedisplay is updated, one can compare the strings in the buffer with thestrings in the display, both to see whether they are the same objects(the pointers are equal; EQ, in Lisp), and to see whether their contentsare the same.Multics EMACS never changes the contents of a string in the buffer. Itcreates new strings to replace the old ones when the text changes.Thus, the string pointers in the screen state continue to record thescreen as it was.ZWEI does change the contents of existing strings. To make sure that itdoes not fail to notice that the text no longer matches the screen, ZWEImaintains a `clock' which increments each time a change is made in thetext. Each line records the clock tick of the last modification. Eachscreen line records the clock tick as of the time it was displayed. Ifthe line in the text matches the line in the screen record, but the tickcounts do not match, then the contents of the line have been changed.Line list representations also eliminate the requirements on commands tosay what they have changed. Reducing the need for the programmer toworry about how display will be done is very desirable. Anotheradvantage is that it becomes feasible to have pointers to characters inthe text which relocate when insertions or deletions are done, so thatthey continue to point to the same place in the text.LibrariesAn EMACS sharable library contains, first of all, a symbol table whichcan be binary searched for the name of an object to find the objectnamed. The symbol table points at both the names and the definitionsusing offsets from the beginning of the file, so that the file can bevalid at any location in memory. The names and definitions are allexamples of the TECO string data type, in the internal TECO format, sothat the library does not need to be translated or parsed in any waywhen it is loaded.The symbol table points to the documentation of functions in the libraryas well as their definitions. The documentation for the functionVisit File is an object entered in the symbol table with the name~Doc~ Visit File. There is also a string named~Directory~ whose definition contains a list of the names of allthe objects in the file which the library wishes to advertise. This isused for documentation purposes, not for looking up names, and it doesnot contain names of auxiliary objects such as ~Doc~ V1sit Fileor ~D1rectory~.It is possible to search the symbol table in reverse, to take adefinition and find its name. Since one can tell which library anobject is in by comparing its address with the range of memory occupiedby the library, this makes it possible to find the name of any objectwhich has one. The ability to do this is important, because when theuser asks what the character Control-K does, it is desirable to beable to tell him that it runs the function Kill Line. The namesthemselves are not kept in the dispatch table because looking up a namein the loaded libraries is slow. For other implementations, that is areasonable strategy.NotesEMACS DistributionEMACS is available for distribution to sites running the DigitalEquipment Corporation Twenex (`Tops-20') operating system. It isdistributed on a basis of communal sharing, which means that allimprovements must be given back to me to be incorporated anddistributed. Those who are interested should contact me. Furtherinformation about how EMACS works is available in the same way.Further InformationA complete manual for use (but not extension) of EMACS isRichard M. Stallman, EMACS Manual for ITS Users, ArtificialIntelligence Lab memo 554, 1980.Richard M. Stallman, EMACS Manual for TWENEX Users, ArtificialIntelligence Lab memo 555, 1980.Various lower level implementation strategies for parts of an EMACS-like editorare treated inCraig A. Finseth, Theory and Practice of Text Editors, or, A Cookbook for anEmacs, L.C.S. Technical Memo TM--165, B.S. Thesis, May 1980.EMACS-related EditorsThese include the true extensible descendents of EMACS, and the editors whichpreceded EMACS and supplied some of the ideas for it. The many ersatz EMACSeditors are not included.Multics EMACSMultics EMACS was written in MacLisp by Bernard S. Greenberg ofHoneywell's Cambridge Information Systems Lab, starting in 1978. Whenfirst implemented, it could be used only by its author, because he alonehad the necessary privileges to patch the Multics operating system sothat a program could read one character from the keyboard instead ofwaiting for a complete line. After seeing the new editor in operation,the other Honeywell people were convinced to make the feature generallyavailable. Because it is written in Lisp, Multics EMACS is even moreextensible than the original EMACS, and as a result it has accumulatedeven more powerful features.Bernard S. Greenberg, Multics Emacs: an Experiment in ComputerInteraction, in proceedings, Fourth Honeywell International SoftwareConference, Bloomington, Minn., April, 1979Bernard S. Greenberg, Prose and CONS (Multics Emacs: a commercial textprocessing system in Lisp), in proceedings, 1980 Lisp Conference, StanfordUniversity, Stanford, California, August 1980.Bernard S. Greenberg, and Katie Kissel, Multics Emacs Text Editor User'sGuide, Publication #CH27, Honeywell Information Systems, Waltham, Mass.,1979.Bernard S. Greenberg, Multics Emacs Extension Writers' Guide, Publication#CJ52, Honeywell Information Systems, Waltham, Mass., 1980SINESINE (`SINE Is Not EMACS') is based on compiling Lisp code torun in a non-Lisp editor environment, in which, unfortunately, nointerpreter is present. However, the user can load his own compiledfiles into a running editor. This design was chosen because of thesmall address space of the machine, an Interdata at the MIT ArchitectureMachine Group. SeeOwen T.Anderson, The Design and Implementation of a Display-OrientedEditor Writing System, Undergraduate Thesis, MIT Physics Department,January 1979.TECMACTECMAC was the first editor implemented in TECO to work with the displayprocessor. It developed many of the ideas used in the EMACS userinterface. It was retired because, written when TECO was less suited tosystem programming, it was unable to attain either readability orefficiency. TECMAC was maintained from 1974 to 1976 by John L. Kulpand Richard L. Bryan.TECOPDP--10 TECO was originally written by Richard Greenblatt, Stew Nelsonand Jack Holloway at the MIT Artificial Intelligence Lab, based onPDP--1 TECO which was written by Murphy in 1962. The TECO in whichEMACS is implemented is its direct descendant. The PDP--10 TECO fromDigital, a typical example of TECO, is also a descendant of an earlyversion from MIT. It is documented inDigital Equipment Corporation, DECsystem-10 TECO Programmer's ReferenceManual, DEC--10--ETEE--D (revised from time to time).Ordinary TECO lacks many important programming constructs. In MIT TECO,the constructs may be syntactically ugly, but they exist. So programscan be well organized, and clean except in the lowest level of detail.TMACSTMACS was an editor implemented in TECO which began to develop the ideaof the sharable library with commands that could be assigned to keys bythe user. TMACS was the project of Dave Moon, Charles Frankston, EarlA. Killian, and Eugene G. Ciccarelli. Interestingly, it had nostandard command set. The implementors were unable to agree on one,which is what motivated them to work on making customization easier.ZWEIZWEI (`ZWEI Was EINE Initially') is the editor for the Lisp machine.EINE (`EINE Is Not EMACS'), the former editor for the Lisp machine, wasalso based on EMACS; it was operational for late 1977 and 1978, and wasredone to make it cleaner. Both EINE and ZWEI are primarily the work ofDaniel Weinreb and Mike McMahon; seeDaniel L. Weinreb, A Real-Time Display-oriented Editor for the LISP Machine,Undergraduate Thesis, MIT EECS Department, January 1979.Other Interesting EditorsAugmentAugment (formerly known as NLS) is a display editor whose interestingfeature is its ability to structure files into trees. Making the treestructure useful required the concept of the viewspec, which specifiesthat only certain levels in the tree structure will be visible. This isthe sort of feature which cannot be added by a user to EMACS, because itinvolves modification of the display processor; but it could be added bya user to Multics EMACS or ZWEI. Augment popularized the graphicalinput device known as the `mouse', which is a small box with wheels orballs on the bottom and buttons on the top, which the user moves on thetable with his hand. This device has been copied widely because of itssimplicity and low cost. Augment was designed at SRI International butis now supplied by Tymshare. SeeDouglas C. Engelbart and William K. English, A Research Center forAugmenting Human Intellect, AFIPS Conference Proceedings, Vol. 33, FallJoint Computer Conference, San Francisco, December 1968, pp. 395--410.Patricia B. Seybold, TYMSHARE'S AUGMENT--Heralding a New Era, TheSeybold Report on Word Processing, Vol. 1, No. 9, October 1978, 16 pp.(ISSN: 0160--9572), Seybold Publications, Inc., Box 644, Media, Pa19063.BravoBravo comes from the Xerox Palo Alto Research Center. Its orientationis toward text formatting, and it can display multiple fonts,underlining, etc. It makes heavy use of a graphical pointing device,the `mouse' (see Augment). It is not programmable and offers no specialhelp for editing programs as opposed to text. For more information, seeyour local industrial espionage agent.EThe editor used at the Stanford Artificial Intelligence Lab, Einterfaces with a `line editor' (used to edit within a line, on adisplay terminal) which can also be employed to edit the input to anyother program. The line editor does not allow commands to be redefined;since it is part of the timesharing system, that is not trivial (thoughpossible in principle). E allows macros to be written using the samelanguage used for editing. These are as powerful as a Turing machine,and as easy to program with. See the on-line documentation file`E.ALS[UP,DOC]' of the Stanford Artificial Intelligence Laboratory.TRIXTRIX is a language similar to TRAC designed at Lawrence Livermore Labspecifically for writing editors. It has been used to write commandsthat are specific to particular languages, and to write text formatters.Its fatal flaw is that it was designed for printing terminals. SeeCecil, Moll and Rinde, TRIX AC: A Set of General Purpose Text EditingCommands, Lawrence Livermore Lab UCID 30040, March 1977.TVEDITTVEDIT is a distant relative of E (above) which is used at Stanford onthe Twenex and Tenex operating systems. These systems do not provide aline editor, so TVEDIT has its own facilities for changes within lines.TVEDIT is a good example of a generally reasonable but nonprogrammabledisplay editor. SeePentti Kanerva, TVGUID: A User's Guide to TEC/DATAMEDIA TV-Edit,Stanford University, Institute for Mathematical Studies in the SocialSciences, 1973. (Online document)Other Related SystemsThe Lisp MachineThe MIT Artificial Intelligence Laboratory has built a machinespecifically for the purpose of running large Lisp programs more cheaplythan ever before. One of its goals is to make the entire softwaresystem interactively extensible by writing it in Lisp and allowing theuser to redefine the functions composing the innards of the system.Part of the system is an EMACS-like editor (ZWEI; see above) writtenentirely in Lisp, which shares in this extensibility. SeeDaniel Weinreb and Dave Moon, The Lisp Machine Manual, MIT ArtificialIntelligence Laboratory.LOGOLOGO is a language used for teaching children how to think clearly.Unlike conventional computer-aided instruction, which automates a methodof teaching which offers little to motivate the student, LOGO invitesstudents to write programs to produce interesting pictures and learnwhile doing something fun.Seymour Papert, Teaching Children to be Mathematicians vs. TeachingAbout Mathematics,` |
|
