From: utzoo!decvax!ucbvax!C70:editor-people Newsgroups: fa.editor-p Title: Semantic cross product command structures. Article-I.D.: ucb.1236 Posted: Tue Jun 1 16:25:36 1982 Received: Wed Jun 2 03:09:33 1982 >From uucp@NPRDC Tue Jun 1 16:08:54 1982 This note wants to make a point leading to two conclusions: a) The traditional distinction in the UNIX community between line-oriented and screen-oriented editors misses the point: the significant differences between the editors referred to (ed and vi) lie elsewhere. b) One aspect of the Emacs versus Yale-Z debate concerns insert versus replace modes. If you believe - very reasonably - that a good editor exploits our 2-D visual abilities then replace mode should be natural; yet it seems that many - most? - people prefer insert mode. I offer an explanation. -------------------------------------------------------------------------- There is a standard argument in favor of a "cross product" command structure in editors. In a CPCS, there is one set of command words (nouns) for objects (e.g. W-word, L-line, S-sentence) and another set of verbs (D- delete, Y-yank (copy to buffer), C-change, etc.). Together they form a set of legal sentences e.g. DW, YL etc. Clearly a vocabulary of N nouns and V verbs gives N+V items to learn but N*V sentences: a great economy in learning and recall reliability compared to having separate commands for each combination. In UNIX, vi has part of its command language structured this way. However the cross product concept is at the syntactic level: nothing happens until a whole command (noun and verb) is entered. A more powerful idea is to implement the concept at the semantic level: you have one set of commands that select objects, another that operate on the currently selected object. In this system you would type "WD" or "LY", but the power comes in that you see the effects of "W" before "D" is executed (the selection is highlighted, say), you can correct it if it's wrong, you can do "WWWD" to step along to the word you want and so on. All the advantages of economy remain, but in addition new sequences are valid, and the user can execute, check, and correct parts of a hitherto monolithic command. I believe that this "super" or "semantic" cross product structure is part of a crucial trend towards splitting actions into small steps, and that this is important because it allows: errors to be corrected at once rather than invalidating the whole of a large action, a greater use of visual feedback, and an incremental, reactive approach to achieving some goal. It can be and has been carried further. For instance, the selection of an object can be subdivided into selecting two points (the beginning and end of it) separately. Emacs supports this with its dot and mark positions. Mouse-based editors typically have the user select a point and then expand it to an object. My claim is that the implementation of this semantic cross product command structure is perhaps the most - certainly one of the most - significant aspects of editors. In UNIX, what is bad about "ed" is nothing to do with the fact that it displays a line rather than a screen at a time, but is that it allows only one command (substitute) that compresses into two arguments and a single action what is better thought of as four separate actions. Ed demands a command like "s/shuot/shout" to do 1) search forward from the beginning of the line to the start of the first string "shuot" 2) move a second marker to the end of that string 3) delete the whole string 4) insert the second argument in its place It is awkward because you have to give a string long enough to be unique in the line, even though you only want to change part of it, and because you can't verify the correctness of the selection before a change is made. Editors that support a notion of cursor position anywhere in the file are a great step forward by separating out step 1 from the rest. In UNIX, the open mode of ex is -- I argue -- a much greater advance over ed than vi is over ex, even though only the latter is "screen-based." Similarly the true advantage of mouse-based editors may be not the 2-D display and the ability to point, but the division of object selection from command execution. (Emacs is part the way there: you can select regions of text not just points, but there is not good feedback to show the selection and this approach is not prominent.) This view is in opposition to the view that 2-D displays are the crucial feature of good editors together with command sets that support 2-D thinking e.g. moving the cursor to a point by motion commands, like cursor keys and mice, that refer to coordinate positions rather than to text objects like words, lines, and search strings. I do not think 2-D thinking is a negligible factor, but I do think that the importance of being able to split actions into separate steps has been grossly underestimated and that to the extent they can be separated, the latter is the more important. (It is hard to separate them because 2-D thinking is not useful without commands that separate motion from execution: imagine an editor that deleted whatever the cursor came to rest on! This however is consistent with my claim for the greater importance of separation.) I have more to say on the 2-D versus text- structure issue, and on the Emacs versus Yale-Z debate, but it belongs in a separate note.