From: utzoo!decvax!ucbvax!C70:editor-people Newsgroups: fa.editor-p Title: Re: Improved support for Emacs in TOPS-20. Article-I.D.: ucb.1182 Posted: Tue May 25 22:55:27 1982 Received: Sat May 29 03:25:09 1982 >From Wood@YALE Tue May 25 22:41:52 1982 Now that the shelling has died down, here is my reply to all the messages I received in response to my flame. First let me apologize for the ad hominem remarks in my original message. They were gratuitous and resulted in misunderstandings about the points I was trying to make. Many people felt that the following statement was an insult to the entire academic community: "The fact that EMACS is so widely used within the academic community reflects the current lack of knowledge about display editing as much as it reflects the virtues of EMACS." That was not my intention. I could have said "lack of research", but it amounts to the same thing. The design of a display editor is at least as important as the design of an operating system or programming language, yet the amount of published research about display editing pales in comparison to the latter two subjects. Most of what has been written consists of general surveys of existing software. Very little has been written about what the issues are in the design and implementation of a display editor. Anyone who has written an editor knows what some of these issues are from painful experience, but that experience has to be published in order for others to learn from it. I was not trying to convince people that a 2-d model is "better" than a 1-d model. My point is that the 2-d model is as valuable as the 1-d model, and that the editor should be able to provide both. I feel that the 1-d model of Emacs is unnecessarily restrictive because it precludes the possiblility of a 2-d model. It is unclear to me what Emacs users feel is important about the 1-d model. Is it not allowing the cursor to be positioned at a point where the file does not exist? This strikes me as a side effect of a decision made in the underlying implementation and not a feature that is intrinsically valuable. Or is the ability to manipulate a continuous stream of text, including any intervening line breaks? This is what I think is important about the 1-d model and what must be provided by any 2-d editor. The Z editor presents a 2-d model that allows the user to select contiguous lines of text and rectangles of text. The Z editor presents a 1-d model in that the user can also select a continuous stream of characters, including line breaks. The 1-d model has no affect on the 2-d motion of the cursor keys. About my criticisms of the semantics of the next/previous line and forward/backwards char commands in Emacs, several people responded by saying that they move by words, sentences, and paragraphs, and that the line/char motion commands are not that important. My response is that both types of motion are equally important but that in Emacs the line/char motion commands are second class citizens. For example: suppose I am reading text on the screen and see a word or phrase that I would like to change. My goal is to get to the location of the change quickly and with as little mental effort as possible. Ideally I am in the cockpit of an F-16 fighter and the computer watching my eyeballs moves the cursor for me as soon as I have focused on the spot I want to destroy. Lacking the ideal solution then I would like to use whatever pointing device my display terminal has to offer, because a pointing device allows me to look at the screen and let my hand do the rest. The semantics of the line/char motion commands in Emacs prevent me from doing this WELL as they do not always move in a linear fashion. The slow response time only aggravates the problem. Some may argue that the cursor keys on most terminals are not a pointing device, and this is true for poorly designed terminals such as the VT100 (bad layout and very slow autorepeat rate). But on the Datamedia 1521, the cursor keys are a poor man's mouse and it seems unreasonable that the design of Emacs should prevent me from using them as such. Designing the editor to take advantage of the available hardware seems perfectly reasonable. If you have a bit-map display with a mouse, are you going to let it sit idle? I think not. If Xerox or someone else starts marketing a cheap optical mouse, then it would be reasonable to install one on an ASCII terminal by having it send cursor motion commands to the host, provided the host can echo the commands in real time. Some of the larger ASCII display terminals, such as the Ann Arbor Ambassador with its 48x80 display, would benefit from having a mouse. The question of insert mode versus replace mode is a non-issue, as the editor should provide both and let the user decide what he wants. There is nothing about the 2-d model that favors replace mode over insert mode. I was wrong to say that the 1-d model favors insert mode, as several people pointed out. The idea of a canonical text file format seems to have been misunderstood. I am suggesting that a reasonable default is for the editor to convert tabs to spaces; trim trailing blanks and trailing blank lines; and insure that every line ends with a newline sequence. The reason for these rules is that all of these situations are not visually apparent to the user, other than by moving the cursor over a location that violates one of the rules. The need to generate files for the occasional program that requires files with such characteristics is not a reason to sacrifice the default, but rather a reason to add an escape to the default that lets the user handle the situation, possibly in a less graceful manner. I have avoided talking about performance issues or monitor hacks so that people will not get the mistaken impression that I think the design of the user interface should be driven by performance considerations. On the other hand, the issue of poor response time cannot be ignored if it renders the cursor keys useless as a pointing device and forces the user to move in a manner more clumsy. Other random points: Z will run on the distributed TOPS-20 monitor, but with response time similar to Emacs. Z does not require the use of special ASCII terminals, as the user is free to rearrange the keyboard any way he wants. Each command can be assigned to any input sequence from 1 to 4 characters in length. Z currently has terminal capability files for the following: Datamedia (15xx, 30xx), Ann Arbor Ambassador, VT52, VT100, TVI9nn, Z19, and HP2621. Z is a production editor, used by over one thousand users at Yale, including secretaries, business students, and system hackers. It is fully documented, including a reference manual, on-line help, and a tutorial walk-through file. Z can be accessed by all users on the system, most of whom use 9600 baud terminals. There may have been valid reasons for including certain jsyses in the monitor when TENEX was developed. I think those reasons no longer apply and should not be used to justify adding functionality to the monitor that can just as easily be implemented as a user library that is easily accessable for fixing bugs and making enhancements. The COMND jsys already has enough "virtual terminal support" to handle RUBOUT, ^W, etc. The only improvement I can suggest is adding system calls to allow new terminal types to be defined without having to rebuild the monitor, as is currently necessary. -Steve -------