From: utzoo!decvax!harpo!npois!ucbvax!C70:editor-people Newsgroups: fa.editor-p Title: Re: evaluating editors Article-I.D.: ucb.1272 Posted: Fri Jun 4 03:37:36 1982 Received: Sat Jun 5 01:30:26 1982 Reply-To: ople >From gaines@RAND-UNIX Fri Jun 4 03:32:14 1982 Since I have been associated from the beginning with a family of related editors, it seems appropriate for me to discuss some ideas in the context of the history of those editors. The daddy of them is an editor developed by Ned Irons in 1967 at the Institue for Defense Analyses (IDA) in Princeton. Ned designed and implemented a timesharing system for the CDC 6600, and as part of it designed what we at the time called a "full screen" editor, to distinguish it from line-at-a-time editors. The decendents of this initial editor include E at Yale (where Ned went in 1969), NED at Rand in 1964 (guess where the name came from) (done by Walt Bilofsky, now the Software Toolworks), and (as a copy of NED) the Apple Pie editor. Dave Crocker worked briefly extending NED while he was at Rand, but the real extensions which transformed it into the current E editor from Rand were done by Dave Yost. The lastest version, with really quite a lot of goodies, is E15. Those who want information about it should contact Mike Wahrman. The original editor had very little: forward and back a page (screen) or line, cursor movement and insert. Ever heard of insert? It didn't mean insert mode, in contrast to overwrite mode. The controller for the terminals available in 1967 required a separate function key that was interpreted to mean that the screen was now correct, and therefore could be inserted in the file. The individual keys were not passed back to the 6600 as each character was struck. Instead the refresh memory (stored in the controller, which supported several terminals) was modified. I mention these details because the hardware strongly colored the model of editing that evolved. The hardware made it essential to view the screen as a blackboard with a little peice of the file on it. The non-function keys and the cursor control buttons allowed one to rearrange his little blackboard, and then later indicate by hitting "insert" that this was how the file being edited should now be updated. The terminals were specially modified to have many function buttons, and as time went on new functions began to be added to the IDA editor. However they never included an insert mode capability, since the hardware couldn't support it. Thus the intial orientation of this class of editors was determined. As an aside to a discussion of purely editor matters, in the IDA system the command executive was invoked from within the editor, and as a consequence the system had some very pretty aspects. Until I saw the Multics command executive being invoked from within EMACS, I was not able to find another system that could provide some of the nice effects that this permits. As I said, Irons' initial editor didn't have very much. But you could get a lot done. Almost immediately, though, Franz Djorup (still at IDA) started extending the editor. Eventually he and Irons published a paper in CACM (early 1971, I believe). The great leap forward was the invention "pick" and "put" (sugggested by Bob Cave, who is also still at IDA). In this class of editors "pick" and "close" copy lines to a temporary buffer ("close" also deletes them from the file) and "put" copies these lines from the buffer to a designated point in the file. Before these came along, various attempts to write programs that would rearrange a file in a nice way were tried, all almost unuseable. The capability to rearrange a file by marking sections, together with the ability to move a cursor around the screen, are among the prinicipal elements that make editors powerful, in my view. The Yale E editor had some extensions from the IDA editor, and some changes, but retained the flavor of the IDA editor. I have not seen it in 10 years, and don't remember its details, but I recall noticing at the time that the most striking differences bore a relation to the hardware being used (the PDP 10 running TOPS 10, and the funny terminals Irons found -- made by Sugarman, I vaguely recall). Insert mode was possible with that system, I think. Someone with more experience may wish to comment on the major features in E that differ from the IDA editor. The major advance made by Bilofsky was to free the editor from line size limitations and to permit the use of several windows on the same CRT. This required dealing with issues such as what to do when the two windows were displaying some or all of the same section of a file, and a change was made in one window. Bilofsky also added the capability to execute a command from within the editor, possibly sending a marked block of the text being edited as input to the command. This was doable with reasonable effort because of Unix pipes and the way the Unix shell works. The E15 editor of Dave Yost is Bilofsky's NED in spirit, but reworked from the ground up. Many new features have been added. Everyone seriously interested in editors should look at it just for the range of ideas it displays. I haven't seen the Yale Z editor, but I would suspect derives from the editors already mentioned. Various people were going back and forth between Yale and Rand during the 1970's, including Ned Irons. Again, others familiar with it may wish to comment. With the Rand editors, the model I described above has changed slightly. Now a better model is that the editor supports a workspace that extends indefinitely to the right and down, and that may be initialized with the contents of a file. The screen is a window into this workspace. The user can position his window to display any portion of the workspace, and can move his cursor where he will within the window. For activities that do not involve insertion of characters, the analogy of a blackboard that extends indefinitely to the right and down is quite good. Insertion of lines, characters, or blocks (multiple lines or line fragments) cause immediate movement down or to the right of some of the blackboard. One need not, when using a blackboard, explicitly supply white space (black space??). The E15 editor embodied so many features that I though it was getting to be about as good as one could expect in an editor. Then I saw EMACS. It was a surprise and a delight to me as a computer scientist. I found the idea that one could build in some knowledge of the domain of the text being edited very exciting. This clearly is a step in the direction we keep striving to go with computers: reduce the work of someone using a computer by having it do as much as possible under the user's control. Furthermore, the fact that to a degree it is possible to build in additional knowledge is another large plus. Having seen EMACS, I got another suprise when I saw my first good word processor. While not extensible as EMACS is, knowledge of some nice aspects of printed language are built into the best of them that do not appear in general-purpose editors. A real effort has been made in them to follow the idea of "what you see is what you get", in contrast to the edit + nroff approach in which most special formatting is simply described for a later pass through a formatter. There is a limitation, though, to the "what you see is what you get" approach: terminals cannot display what can be printed. This is true at the top end of the quality scale, in that typsetters and printers can do things that even the high resolution bit-map terminals being offered today cannot do. It is also true on a relative scale; the cost of good display quality terminals is high relative to the cost of printing equipment for organizations that need lots of terminals. In closing this note, I would like to make some comments about the 2D versus 1D debate that has been going on. The model I have described above is a slight extension of the 2D view. It seems to me that this model is more general than the "edit-the-file" model (I don't think the term 1D is very descriptive of what goes on in EMACS). It seems to me that the cases when one must append white space at the right end of a line or after the last line in a file are so rare that it is best taken care of by a file reformatter, and that aside from this capability the "indefinite blackboard" model gives the user more power than the edit-the-file model, while giving up nothing else. Certainly it is nice to be able to position the cursor by reference to the semantic constructs the editor has been taught to recognize. But as when making marks on a real blackboard, it is also nice to be able to get to a point in the workspace independently of these semantics. I think the edit-the-file model is simply restrictive to no significant advantage. Unfortunately, at least in the LISP version of EMACS on Multics, I don't think it is changeable through EMACS extensions, but rather would require major surgery. Those who only have familiarity with the edit-the-file model should take a look at the many goodies related to the indefinite blackboard model Yost has built into E15 to see how much power that model really has.