t-krgr (02/02/83)
I lead a team of UNIX software engineers at Translation Systems Inc. in Boston. We are re-hosting System III (soon to be V) to the National Semiconductor 16000 series architecture. (Yes, we are installing a full demand paging system in the first release; no, we aren't involved with the NS/HCR port.) In the process, we have been among the very few external organizations using the current release of CCA EMACS. Our experience with C-E dates back to early fall 1982, on a VAX-11/780 system maintained by CCA in Cambridge. Members of our team have used Gosling's EMACS; our company is also a test site for another version of EMACS that runs on a PR1ME system in-house. (Since we are a test site, that version will NOT be discussed here.) Collectively, we have used a bunch of other editors on various systems, some interesting (old and new EDT for RSX, EDT for VMS, TECO, Fastedit, etc etc), and some we'd rather forget (how about the MPX-32 v1.4 line editor?). Preferences in editors rank right up there with politics, religion and salary as dangerous topics of conversation. I won't spend time here defending the extent of my objectivity here other than to mention that the information presented here can be independently verified easily. I would like to hear of conflicting views, with concrete data. 1. Always my favorite point of comparison, reliability. We have NO experience with C-E failures, over a period of over 4 months of very heavy use. We have of course been on the system during some significant hardware (disk) failures, cases in which the C-E crash recovery has proven very helpful since it is based on journal files and edit history directories that remember the contents of buffers and the keystokes that apply to each buffer. When you go into crash recovery, it plays a 'movie' of the edit session up to the last few keystrokes before the crash. You then continue the edit as you wish. Very nice! (Regular Auto-Save is available, too.) 2. Features worthy of note: - The commands are built-in, with none of the delays and processing attendant with the 'libraries' approach; this makes it seem more time-effective to learn and use the less common commands. (There are 379 commands at last count.) - To the degree that they can, the command keystrokes make sense in an effort has obviously been made to keep some orthogonality for related functions. - Mark and point can delimit a rectangular area on the screen, where neither need be at the beginning of a line. These rectangular regions can be opened, filled, etc., which makes it possible to manage columns of information. - Use of the named kill buffers and mark buffers don't require use of any extension language; they can be used right in the normal editing mode. - Shell-in-buffer: you aren't limited to one (limit is currently 5). - The spelling checker has a corrector option in which it will suggest alternate spellings. - No extension language; sorry, hackers. Personally, if I need LISP, I write a LISP procedure; with C-E, there is less need for such horsing around. 3. Documentation. The manual is extensive, but approachable. Also quite good are the on-line tutorial, on-line help, in-command help, and INFO-type documentation. The extent of the documentation is unusual even for a software product of this genre. I use a relatively wide variety of commands, largely without the use of the printed documentation (in favor of the on-line information.) Worthy of note is the fact that C-E capabilities ARE documented; ever find out that your editor could do some strange function all along (while you spent a late evening creating a very imaginative extension language procedure)? 4. Performance. We pay for connect time and cpu time on a VAX with daytime loads of 25-35 logged-in users, so we pay attention to how things go in an edit (where most of our time is spent). Eight C-E users typically show a user load of less than 2.0, and it shows in general editor response and resource charges. Even with a considerable system load, C-E has some snap which makes it easier to concentrate on the real problems. 5. Product Considerations: - Price is $850 per VAX system, which speaks for itself. The only better deal I know of is the UNIX PL/I-G compiler due out this summer (for about the same price). - C-E doesn't use multiplexed files, and will be released for use under 4.2BSD (as well as 4.1BSD). Note well, users of other EMACS products! - CCA is easy to contact and ready to sell now. The product is delivered in source form, and maintenance will be via source modification. - C-E is compatible to a large degree with ITS EMACS, the PDP-10 and PDP-20 version of EMACS. Someone familiar with ITS can sit down and begin using C-E right away. - Since termcap is used, there is a good chance for support of the usual mongrel collection of in-house terminals. Now the inevitable question: what negative aspects of C-E or any EMACS haven't been mentioned? In my opinion, the perfect editor will simply require you to think of the code(*). In the meantime, find the most reasonable editing tool. EMACS' truly negative aspect: you must use your fingers. See? We avoided politics and religion! Mike Krueger Translation Systems, Inc. 138 Brighton Ave. Allston, MA 02134 617-254-3482 * When that day arrives, we'll probably verify the suspicion that programmers don't think about code.