THE EMACS TEXT EDITING PROGRAM FOR VAX/VMS Presentation: DECUS Symposium, December, 1984 by Allen A. Watson What is EMACS? EMACS is a new text editor program now available for your VAX that gives you, to paraphrase an old book title, everything you always wanted in a text editor but were afraid to ask for. Large systems users (DEC 10's and 20's) may already be familiar with this editor; I understand they have had it for some time. It has also been available for Unix users. Only recently, however, has it come on the market for VAX/VMS systems. Incidentally I do not know the meaning, if any, of the name "EMACS". If anybody does know I would be interested. Perhaps "EMACS" stands for "Extensible, Modifiable, And Customizable Screen-oriented" editor. EMACS is "an extensible, customizable, screen-oriented text editor." That phrase is taken from VAX System Improvement Request F83-33. I quote that SIR in full because it explains many of the reasons why such a text editor is needed: VAX SIR F83-33 Despite repeated requests from the user community, the capabilities of the EDT editor on the VAX appear largely frozen. EDT provides insufficient features for customization and extension, and is hopelessly bound to VT52 and VT100 style terminals. Many of these restrictions may be traced to the fact that EDT as the "DEC Standard Editor" must be limited enough to fit onto PDP-11's. This is a penalty which VAX users should not have to pay. DEC should support a fullly customizable, screen-oriented editor. Customization is best handled in a manner similar to the EMACS editor, in which a text-oriented, generalized programming language (loops, variables, functions, etc.) underlies the editor, and is accessible to the user. This model is familiar to many VMS, UNIX, and particularly TOPS-20 users. The editor should support multiple windows on a screen, and should provide an interface by which any sufficiently powerful screen oriented terminal could be supported. Reply from Digital Equipment (Pageswapper, July 1984) Digital expects to have an editor meeting these requirements available in the Version 4 time frame (not necessarily with VMS 4.0). Initially, it will support only VT1xx and VT2xx type terminals. Eventually, it will use the RTL routines to support other terminals. It will include a customizing package which will make it completely compatible with EDT. It is not yet clear whether this editor will be bundled with VMS or will be a layered product. But such an editor exists now, if you are willing to pay for it. (You will very likely have to pay for DEC's EMACS when it finally appears, probably in late 1985 or early 1986.) And EMACS already supports almost any terminal you can name, while DEC's new editor will support only DEC terminals at first. Two vendors offer EMACS for the VAX. There was a public domain EMACS in an earlier incarnation. Computer Corporation of America (CCA), in Cambridge, Massachusetts, offers a VMS version; UniPress Software, Inc., in Highland Park, NJ also offers their own version. As nearly as I can tell the two versions offer almost the same capabilities. Both offer EMACS in binary form and (for a good deal more money) in source form. EMACS is written in C and can be compiled using VAX-11 C. WHY EMACS? Why another editor? Most of us are used to EDT; why learn another editor program? After using EMACS for nearly five months what I can tell you is this: if you do a lot of text editing, either of documents or of program sources, you are going to love this product. If you can bear the strain of learning another editor and retraining your fingers, you will never want to go back to EDT. In this talk I will try to describe some of the many useful features of EMACS. Most of the features are common to both CCA and UniPress versions. For a fuller comparison of the two versions, I refer you to my article that will appear in the DEC Professional, November of this year. EMACS Does Everything EDT Does, But Faster EMACS does everything EDT does, but does it faster. EMACS uses virtual memory on the VAX to hold most of what it needs in memory, allowing fast response to commands. EDT, on the other hand, is designed so that it can run on the PDP-11's, with their limited virtual address space. DEC has reported that the new version 3.0 of EDT, with many added features, is even slower than version 2.0. EMACS has more advanced editing features Here are just a few of the editing features EMACS has that EDT does not: Can move cursor or delete by units of character, word, line, sentence, paragraph, and region. Paragraph recognition is much improved. Understands "Runoff" commands as paragraph delimiters. Can transpose any of the above units. Enhanced searching and replacing; incremental, pattern matching, wildcards. You can define abbreviations and have them replaced automatically as you type them, or on command, e.g. NYM could translate into "New York Metro LUG", or ECSOTE could translate to "exstensible, customizable, screen oriented text editor". Automatic indenting and tabbing. You can even combine automatic word-wrap and indentation. That is, as you type along, when you reach end of a line, EMACS will not only move the word that doesn't fit onto the next line, it will also insert blanks and tabs at the left end to line up with previous lines. The "Fill Prefix" does not have to be blank; it could be something like "_$ !", which is useful for entering comment blocks in command procedures. Built-in fill and justify modes. Overwrite mode available so you can more easily edit formatted, aligned text (such as tabular matter). Multi-window editing with horizontal or vertical split screen. Can have multiple splits. Supports up to 200 buffers, so can have multiple files available for editing. Self-documenting. EMACS has extensive built-in help files that are much more useful than normal VMS help. CCA's EMACS even has on-line access to the full text of the user manual! Customizable. Keys can be defined any way you want. Users can write their own text editing functions in a LISP-like language and bind them to the keys of their choice. Has a "learn mode" like KED. EMACS makes complex editing easier Multiple files can be edited at the same time. Files can be read, by a single command, into several buffers. Some buffers can be made read-only if you are using them just for reference. With multiple files, you can display two or more files in separate windows on the screen, with the screen split horizontally, vertically, or both ways. EMACS has improved recovery from errors EMACS saves the last sixteen deleted text portions and you can recover them. There is an "Undo" command to undo mistaken commands. EMACS keeps a keystroke recovery file in case of system crashes. You can cause your files to be automatically saved every so many keystrokes. There is a quick command to "save all files" at any time. And there is even a way to recover what you were doing if EMACS itself bombs. EMACS interfaces to DCL directly You don't need to leave EMACS to use DCL commands. You can read and write your mail, do directories, even delete and rename files, all from within EMACS. You can execute any DCL command and capture the output in your EMACS buffer. And finally, you can start a DCL subprocess within an EMACS buffer and capture all the input and output permanently. Many EMACS users think of it as an environment instead of an editor. I get into EMACS in the morning and often don't leave it until I log off at night. I run EMACS in a sub-process. In that way, if I want to get back to normal DCL level, I just suspend EMACS and Attach back to my main process, where I execute DCL commands to my heart's content. When I want to resume editing, I attach back to my EMACS process. All the files I was working on, all the buffers and windows I had set up, all the macros I defined -- everything is still there waiting for me, and it starts back up much more quickly than going through image activation or process creation. But I could not do this if it were not possible to execute DCL commands from within EMACS. Sometime at the end of a day I want to make a note of what I worked on that day. By scanning through the various buffers I have left around in EMACS I can get a partial record of what I was doing. EMACS has special commands for editing program sources There are commands to help in balancing parentheses in expressions and to find or insert comment lines. You can create a "Tags File" which identifies the location of subroutines within programs, so that you can quickly "go to" any subroutine in your editing. And there is an automatic abbreviation mode so that, for example, when you type in "SSD", EMACS will automatically replace it with "SOCIAL-SECURITY-DEDUCTION", which can save an enormous amount of time inputting COBOL programs with long labels for variables. In addition, this guarantees that you do not misspell the field name. Over 400 Commands There are so many EMACS commands that probably no one ever uses them all. Almost all of them are accessible through one or two keystrokes. EMACS uses the Control and Escape keys to initiate commands. Normal keyboard keys, for the most part, just insert into the buffer: typing "A" will insert an "A" into the buffer, for example. But CTRL/A will move the cursor to the beginning of the current line. Whoever set up the mapping of commands to keys did a very good job of making them, in large measure, easy to remember. It takes a lot of getting used to when you first start, but before long you begin to remember the patterns: CTRL/K kills a line, Escape/K kills a sentence, CTRL/C-CTRL/K kills a paragraph. That sort of pattern runs through most of the commands. The keypad keys are active as well. It is possible, if you want, to set up the keypad to look a lot like EDT. Personally, I prefer to use the standard EMACS keypad because it has commands that you use frequently when using EMACS features. These are commands that EDT does not have, such as Select Buffer, Find File, and Prefix Control. However, from my experience in trying to train hardened EDT users on editing with EMACS, I think I might change my tune if I had it to do over. It seems that not too many people are as patient as I am when it comes to learning a new editor. After a few times of hitting the wrong keys and screwing up their files, a lot of my users just gave up and went back to EDT. I think if I had given them an EDT keypad to start with, they could have gotten used to EMACS gradually instead of cold turkey. Multiple Buffers EMACS is designed for use with multiple files. When you want to document a program you can call the source up in one buffer and write your description in another. You can even do things like "EMACS *.FOR" and call up all the FORTRAN routines in your directory into EMACS. There are special editing commands that take effect globally in all buffers, for example, changing all occurences of a variable name in an entire set of subroutines with a single command. You can get a list of the buffers you have and what files are in them. And unlike EDT, when you exit, EMACS makes sure you have a chance to save all of your modified buffers. It's easy to copy things from one buffer to another, to take pieces from several buffers and append them all together in a different buffer, and so on. There are more than a dozen commands dealing with buffers. Any time you want to look at a new file, you just use the Find File command; EMACS locates the file on disk (or in a buffer if you already have read it) and switches you to a new buffer containing the file. You can mark some buffers Read Only so that if you inadvertantly change them they will not get written back to disk. Multiple Windows EMACS can split the screen eight ways from Sunday. My EMACS can split the screen horizonally, vertically, or both. The most windows I have found practical is three: one for a reference file, one for the document I was creating to describe it, and a third in which I could execute DCL commands when necessary. You can even have multiple windows on the same buffer, for instance when you want to look at some code at one place in a program and write related code in another part of the same file. User-written Functions You can use a subset of LISP to write your own EMACS functions. This gives you (dare I say?) all the power of TECO and more, because you can compile your functions, where TECO had to interpret them each time you ran your macro. (And hey, my EMACS even has Q-registers!) Oh, yeah. EMACS allows you to write macros, too, when you just need a throwaway function. You can write them in "learn mode", test them, and then store them in a macro library that gets loaded whenever you start up EMACS. Or you can have several macro libraries and load them selectively. Extensive Command Set The commands defined for EMACS are so extensive that just to list each with a brief description takes thirty-three pages! There are things like the "occurs" command. There are two: one just counts the number of occurances of a string (actually the string can be a regular expression, much as in GREP from Unix); the second command will actually display every line containing the pattern. There are commands to indent text, to fill indented text, to indent for comments in program code (you give the delimiters for comments and the column you want them in; EMACS does the rest). There are four different search commands, each with variations and in some cases a special command subset for doing things like reversing direction, backing up to previous hits, adding to the search string on the fly ... it goes on and on and on. There is a special "DIRED" mode for editing directories. Yes, editing. You get a directory listing on the screen, move your cursor up and down, and delete, undelete, read, edit, rename, print, or purge files at will. I don't know how I lived without this; now I actually clean up my directories fairly often because the pain has been removed. You can even split the screen in two windows and have the directory in one window while you edit files in the second one. Conclusion Is EMACS worth the double price, first of money, and second, of re-educating your fingers from EDT or TECO to another set of editing functions? I would not be giving this talk if I didn't think it was. It took me a lot of time to learn EMACS well. I had to force myself, at first, to use it when the commands were unfamiliar. It took me longer because I had to keep looking things up with the Help facility (I almost never look at the manual anymore). But now, I'm sure that EMACS has repaid me many times over in the time I've saved. The two versions of EMACS I have seen both suffer from less than perfect introductory material. Both CCA and UniPress have told me they are working on new manuals and tutorial material. Trial packages are available with documentation. If your users are mostly unsophisticated computer users, you might have to develop some of your own training material. I did, and with just a few hours instruction secretaries are using EMACS in our Personnel Department, so it isn't really that difficult to learn. I have no idea what Digital's version of EMACS will be like: better, worse, faster, slower, more limited or more extensive. I do know this: even if I eventually wind up using DEC's new editor, I will have profited from the experience of using EMACS. Copyright 1984