From: utzoo!decvax!ucbvax!C70:editor-people Newsgroups: fa.editor-p Title: Emacs versus Yale-Z -- another perspective. Article-I.D.: ucb.1237 Posted: Tue Jun 1 16:50:53 1982 Received: Wed Jun 2 03:13:04 1982 >From uucp@NPRDC Tue Jun 1 16:42:33 1982 In this note I want to propose a different perspective on the Emacs versus Yale-Z debate: to advance my view of what the real issues are. I am mainly offering a framework within which judgements of editor designs might be made, but at the end I offer an idea that might count as a solution to a lot of the debate. 1. We have 2 ways of thinking about text (a) Functional: In terms of its meaning (words, paragraphs, etc. for English; expressions, functions, etc. for code) (b) Visual: In terms of its 2-D layout on the window or page. We use the latter for pointing, and often for thinking about the location of some item. We use the former especially during insertion to decide how to lay out the material and because our overall goals are largely to do with the function of the file not its 2-D appearance. This is a dual view; editors that ignore one aspect will fail to latch on to a significant portion of the mental representations we use. 2. The converse of the 2-D view of an English text file is not a byte stream but a word stream. (This is a corollary of point 1.) In text it doesn't matter at which word boundary a line feed is inserted, but it does matter if you insert one in the middle of a word. The contrast is between an editor (mode) that supports 2-D thinking and one that addresses the meaningful structures, which for English text are words, sentences, and paragraphs, but for programming languages are things like expressions, statements and functions. There are of course partial relationships between the two: paragraphs are separated at line boundaries; programming languages have strong indentation conventions. 3. In designing an editor, or any other system, we need to compile a check list of user needs to be supported. (This is NOT the same as implementing a mode or command per need - see below.) In editors, the following modes seem needed (these are a user's modes of thought and action: whether they require distinct command modes is a design issue): a) English text mode: changes and insertions should cause automatic filling of lines within a paragraph. There is no return-key function as such. The space bar is a word boundary key (causing either space or CR-LF). There should be a sentence-end key (e.g. insert period-space-space), and a paragraph key. Cursor motion commands should include moving in steps of a word, a sentence, a paragraph. b) Program code mode: the idea is the same, the structures are different. The rules for breaking input into lines are more complex. c) 2-D mode. This is especially useful for editing tables and diagrams. There may be two distinct versions. (c1) The user controls divisions into lines - the linefeed key creates vertical movement - but horizontally characters are taken literally not interpretatively. Thus tabs are inserted as single characters, trailing spaces can be added and so on. (c2) Full 2-D -- the user is concerned to create a 2-D layout, and keys like tabs are treated like linefeeds as specifying motion. The editor's concern is to produce a file that represents the appearance of the window; the user operates only on the appearance and does not think of the characters that will be used to achieve it. 3.2. There is a further class of user needs to do with getting accurate echoing and a fast response. Systems that are heavily loaded relative to the cost of supplying these needs by brute force techniques raise the design issue of whether to supply them in full and if not then what kinds of restricted service to supply (e.g. by not updating the screen accurately during certain modes). There are potential tradeoffs involving fast echo response and accuracy of the screen representation. For instance speed could be gained by causing every mid-line insertion to split the line at that point: the insertion can then continue in the trailing space using O.S. echoing; reformatting could be done at the end of the insertion. This would probably be acceptable for English text but too confusing for program code. 4. As the above suggestion shows, O.S. support for editors in the form of advanced dynamically changeable remote echoing could be exploited in many ways, not all of which require a 2-D text model. Although not all editor behaviour could exploit such support, many could besides the one Steve Wood favors. 5. A design question quite distinct from the identification of user needs is that of what virtual machine to present to the user via the interface i.e. the form in which to present means for satisfying the needs. The approach that seems to underlie most editors and most of the discussion is to try to cover all user needs and modes in parallel - to find a single "right" treatment for tabs, etc. While a single uniform model is attractive, this does not seem possible in an editor because, as noted above, we have dual perspectives on the task (2-D/visual versus functional) Even though Steve Wood emphasized the 2-D perspective presumably the Yale-Z editor has commands to advance by a word, and presumably it does automatic line breaks during insertions -- these facilities are in demand but have no logical place in a 2-D approach. Given user's demands for multiple perspectives, rather than pursuing a single consistent model it might be more fruitful to push the notion of modes or subtasks in editing further: pursue the idea in my previous note of providing disjoint subsets of commands addressed to separate subtasks -- 2-D movement, structured movement (by words, etc.), text changes. This would start with providing a simple command to switch between say, English, Lisp, C, and 2-D modes. Such a switch would simultaneously change a number of underlying things: treatment of tabs, of line wrapping, etc.: it might even cause a re-processing of the current file to do tab translation throughout. The idea is to make the user conscious that not all editing is the same task - it depends on the material. Furthermore, it can depend on the user's view of the task at a given moment. A switch rather than a disjoint subset may be necessary because of conflicting demands on certain things (rules for breaking lines, and for what constitutes a word boundary). The idea of disjoint subsets can be applied to cursor-key movements. I believe that their use is in implementing our desire to go from A to B, where A and B are positions we SEE on the screen. Once we've arrived however we usually revert to a structural mode of thinking in terms of words, sentences, etc. My proposal is to copy mouse-based editors. In the Smalltalk text editor for instance the cursor showing the mouse position and the one showing the current text insert position are different. To move to a new position you move the mouse but only when you click a button does the text cursor move to the mouse cursor. Furthermore, it moves to the nearest sensible position - and if you point off the end of the line, this will not be visually close to the mouse cursor but at the end of the last word. If this separation of pointing cursor and text cursor were adopted in Emacs and other non-mouse editors, a lot of the debate would vanish. Cursor key movements would be strictly 2-D, allowing efficient echoing and the desired regular visual behavior and adjustment to the underlying character representation would be made only on arrival, signalled by some other key press. This would decouple the text- to-screen mapping issue from the cursor-movement representation issue. I personally would then vote with Steve Wood and against both Smalltalk, Emacs, and vi and have automatic line-extension done when I point to a space beyond a line-end. This is easy for an editor to do and, I argue, not confusing in this model which clearly separates the notion of pointing cursor from character representation. (The extension would only be done when the command to equate text and pointing positions was issued). However under the above proposal, this could be left up to the user as an option, or done by a separate command. This proposal accommodates both the fact that there is no such thing as a constant-width set of characters in either old or new technologies, and the need for cursor key commands to be supported by regular 2-D behavior of the cursor (this is supported by my experience of how irritating it is in vi for a downward cursor key command to make the cursor fly 60 columns leftwards because there is a short text line). The major problem is that it requires distinct visual representation of several kinds of cursors. This, my previous note argued, is something Emacs and other editors already need to display marked positions. If my hypothesis about the mental distinctness of 2-D and structural thinking is correct, this is not a serious problem: mark such positions with a character like '^'. The inaccuracy in line length does not matter from a textual (structural) point of view, and in cursor-key mode it doesn't matter whether the displayed characters are textual or not. Of course, such an editor should support a 2-D mode where there is a strict one-character-per-column display (and no such cursor characters) for the cases like table editing where it matters. Steve Draper sdraper@yale