From: utzoo!decvax!ucbvax!C70:editor-people Newsgroups: fa.editor-p Title: Re: EDITOR discussion on TOPS-20 Article-I.D.: ucb.1181 Posted: Tue May 25 21:16:48 1982 Received: Sat May 29 03:15:32 1982 >From RWK@SCRC-TENEX@MIT-AI Tue May 25 19:22:34 1982 [Editor's note: I have taken the liberty of appending two related messages from RWK into this one message. The first message advertises itself as "flame", but both present a great many important observations. /jq] I'm getting tired of seeing a barrage of opinions in the form of dogmatic statements. I think it's about time I make a few strong statements of my own. Date: 20-May-82 9:36PM-EDT (Thu) From: Steve WoodI have already implemented a change to TOPS-20 that provides a significant improvement in the interactive response time of a display editor, while at the same time reducing the number of process wakeups. It works and is in use everyday here at Yale. My suggestion is that EMACS could be changed to take advantage of the changes to the monitor. What would have to be changed? There should be a one to one mapping between file positions and display positions. This would require long lines to be clipped instead of wrapped; This is completely, absolutely unacceptable. Any editor which hides long lines is completely unusable in many environments, such as any environment I've ever been in. Such an editor is BROKEN, a mere fragment of an editor. The change is also completely gratuitous, since it is quite acceptable to wake up the editor in this unusual case. control characters to be displayed as a single high-lighted character; tabs to be expanded to spaces; This isn't acceptable either, since EMACS supports that majority of terminals that don't have highlighting modes. It is also doesn't buy you anything. If you're really going to do up/down cursorpositioning commands in the monitor (which I don't think would make an appreciable difference) then just position it. Let the editor figure out the mapping when it finally gets control and finds out the new cursor position. Inserting into the middle of the tab would require the editor to handle it so it could move the cursor before inserting to the begining of the TAB, but this would be no more disconcerting than the current TAB behaviour. Actually, maybe it should instead just insert the necessary spaces actually put it in the place the cursor moved to. THAT would be an improvement, I think. Converting the file's tabs to spaces and making the user work with spaces is a fine user-interface idea, but ignores the reality that the files may NEED tabs for whatever program. next/previous line and forward/backward character to move by screen positions and not by file positions. They already *DO* work by screen position. What they DON'T do is extend a line beyond the end. It should be no problem to tell the monitor where the line ends, if you really wanted to do this. Would these changes be fatal to EMACS users? I don't see how as they would only improve what is already a very good editor. I would refuse to use it. So would a lot of other people, I'm sure. I'd keep around a non-performance-enhanced version and use that instead. Many editor designers have taken the attitude that they know better than the designers of EMACS what an EMACS-child should look like. It has been my experience that they have often been very, very wrong. EMACS was in a very real sense designed on the experiences of a very large community of users, and end up breaking some of the most important features. This does not mean that an editor has to be identical before I would accept it. But I do wish people would not start calling features very many people consider essential "obsolete" and such. And don't underestimate the importance of compatibility in command sets. Editor designers don't seem to realize that people who use their editors use other editors too. I find that all the good ideas in the world can't overcome an incompatible command set (especially if the editor isn't extensible enough to fix it!) or a single bad idea like line-truncation. So please, I really don't want to hear more about changing EMACS's COMMANDS to make it easier to implement the monitor. I think this is more of a TOPS-20 issue than it is an editor issue. Certainly, if you are only going to try to make improvements in the performance of a specific editor. I think such an attitude is a mistake when making changes to an operating system. It seems to me that you're trying to redesign the editor around the operating system. This has to be the biggest mistake of them all. I consider the attitude of "operating system efficience over user interface" to border on criminal. And all for the sake of optimizing what will be a minor fraction of the commands -- I can only shake my head in disgust. ---------------------------------------------------------------- Date: 22-May-82 1:24AM-EDT (Sat) From: Steve Wood Date: 20-May-82 3:06PM-EDT (Thu) From: Steve Wood However the design of EMACS is such that you could not change the stream editing model that EMACS presents to the user. The mapping between file positions and display positions is buried at the lowest level of the implementation. I know this is true of the TECO implementation and I suspect it is true of the LISP-based versions of EMACS. I wish I knew what this meant. If I did, I might be able to tell you about some of the LISP-based versions of EMACS. In order to make the mapping between file positions and screen positions be one to one, the following changes would have to be made. Unfortunately not all of these changes are not possible using the extension language and the editor kernel itself would have to be hacked. First tabs would have to be stored as spaces, by changing the tab command to insert the appropriate number of spaces instead of a single tab character. You would also have to hack file input to convert tabs to spaces. Control characters are displayed as two characters, which can't be changed without hacking the low level display primitives. Long lines are wrapped onto succeeding lines. Making it so they are clipped instead would also require modifications to the low level display routines. All movement commands could be changed to allow movement to non-existent file locations, by automatically inserting enough blanks so that the file does exist at the cursor location. If you did this, you would have to change the file output logic to remove any extraneous blanks caused by moving the cursor past the end of a line or the file, but not making any other changes. Probably all of this is doable with existing Emacs implementations, except for the modifications to the low level display routines, as the redisplay algorithm is not accessable to the user. I don't know what affect these changes would have on other Emacs commands. -Steve Well, in all LISP-based editors I know of, tabs are stored as Tabs. (Ten-space-wide in Multics EMACS). I went into why this is necessary (we know why it is unfortunate) in my recent flame. I might try making ^N do the "right thing" with Tab's in ZWEI (the base for the ZMACS editor on the Lisp Machine which is also used in a number of contexts which are not strictly text-editing). I.e ^N would move the cursor to more-or-less the right place, and if you tried to insert there it would add enough spaces. The redisplay algorithm is available to the user in all the Lisp-based editors. (This doesn't mean the code is easily changable, but any user can replace it in his init or whatever). I say "more-or-less" because of another problem: The 2-D array of fixed-width characters model is bankrupt and obsolete. Documents and even programs make use of fonts of variable widths. TAB's are not the only character which is of non-standard width! ZWEI tries hard to move as close to the same vertical position, since the 2-D array is one of many competing models which are useful to the user in various circumstances. The "stream" of characters model that you so despites is another model which has its own uses. So much so that the Lisp-based editors provide it to users (in addition to the 2-D array model, the paragraph model, etc), despite the fact that they do not represent it that way internally at all. In at least ZWEI and Multics Emacs, text is represented as a doubly-linked list of lines. This wealth of different models for the text is one of the things that makes EMACS so powerful. It also means that optimizing ^N and ^P is not that important. Look to your M-A and M-E (forward and backward sentence), your M-B and M-F (fowrdard and backward word) etc. If these commands cannot respond adaquately fast, I would seriously recommend against buying that machine. Building them into the monitor is not the way to go! What is needed is to optimize the most common ones to minimize the load on the system. (I've seen somewhere a frequency table of various types of commands in some EMACS-like editor. My recollection is that C-N and C-P were down in the noise; I'm sure this is true of my own usage. Does anybody recall seeing these statistics somewhere?) Echoing and sequential paging are the only reasonable canidates for further monitor support that I can believe in without solid frequency-of-use statistics to back them up.