Aucb.111 fa.editor-p utzoo!decvax!ucbvax!C70:editor-p Fri Dec 4 14:13:14 1981 Cross-Product Languages >From LAWS@SRI-AI Fri Dec 4 13:48:36 1981 Thanks for the replies. I see that the level of scholarship on Editor-People is much higher than that of the flaming on Human-Nets. I will therefore document my position further. Some of this is in response to private communications from Jan Walker @BBNA. My comments are based on my own experience with SOS, VI, NED, and UNIX EMACS. I have no lab data to support my claims. Simple operations should have single keystrokes. I maintain that meta-control-D is not a single keystroke, at least for me. (On my Datamedia 3250 terminal it is very difficult to use both meta and control keys together.) While I recognize that a skilled pianist can hit chords more easily than the same keys separately, I am not willing to practice enough to gain such skills. Single shifts do not bother me, but selection of multiple prefix and shift combinations requires more mental effort than hitting the same number of lowercase keys during ordinary typing. The VI and ZED editors also recognize the need for simple commands to have simple key sequences. VI binds nearly every single key to some operation (and the same for nearly every shifted or prefixed key). Only a few commands have the factored structure that I advocate, and these often permit alternate shortened syntax. Thus "d" and "x" can both be used to delete a single character. When the verb is omitted VI assumes "move": thus alone can be used to move one character and "w" to move one word. Numeric qualifiers always default to unity. Actions can be repeated by typing ".", so it is usually less mental effort to type dw.... than 5dw. ZED has given up some of this single-key ease for syntax regularity, but it also allows defaulting of most command factors. That is why "w" can't be used for both "whole" and "word" -- the parser wants to know which you mean as soon as you type one character. The command "w" alone means to move forward one word. Another tradeoff here is whether you want the computer to respond to keystrokes or to commands terminated by s. EMACS and most editors are oriented toward the former. VI and ZED both act as soon as the intention is clear, but the multiple character syntax is better suited to those of us who want to examine and reconsider complex commands before hitting that final fatal keystroke. (In VI nothing is fatal. I love the undo facility.) For operating system command languages I definitely prefer that the system wait for an ESC or before trying command completion or execution. The same goes for the EMACS help-on-command-completion option. Next flame: EMACS syntax is not fundamental to EMACS. I have been hearing this about UNIX and about VMS DCL, as well as for LISP and any language that supports macros or subroutines. In theory anyone can have his own interface. In practice the interface is always extended in the spirt of the original. Eventually "standards committees" spring up to guarantee the stylistic consistency of extension packages. (Witness the recent birth of SIGAPL.) The original EMACS set a style which will propagate as long as there is an EMACS. For the most part I like EMACS. I simply object to the default bindings. They need such complete repackaging that only a dedicated hacker can do the job without making matters worse. (Worse in the sense that the user becomes isolated from the printed EMACS documentation and from other EMACS users since they no longer speak the same bindings.) As an example, try running the maze package in the Twenex EMACS using the original bindings of ^N, ^P, ^F, and ^B to move the cursor around the maze. It is physically painful. The main problem with the bindings is the lack of a sticky insert mode. Or rather, of a way to turn it off. This consumes all the simple key bindings and forces one onto the meta and control shifts. It is easy enough to add insert and non-insert modes, but purists will claim that that isn't EMACS. As a result, UNIX EMACS is used to "emulate" other editors with insert modes rather than "becoming" them. A final point: Of course expert operators are capable of learning complex systems -- even English. I have heard of a typesetting machine used in Communist China for putting names on maps that requires seven years to learn to operate proficiently. Is this the type of system we want to design? Why give commands arbitrary names when we can give them sensible ones? There is no doubt a need for instant-response maximum-complexity systems like Emacs. If the need is strong enough special keyboards should be designed. But let's not confuse such applications with ordinary text editing by students, programmers, and researchers. They need flexible systems that are easy to learn. I maintain that factored languages provide much more power for the amount of training required than do "unique-key" languages. -- Ken Laws ------- ----------------------------------------------------------------- gopher://quux.org/ conversion by John Goerzen of http://communication.ucsd.edu/A-News/ This Usenet Oldnews Archive article may be copied and distributed freely, provided: 1. There is no money collected for the text(s) of the articles. 2. The following notice remains appended to each copy: The Usenet Oldnews Archive: Compilation Copyright (C) 1981, 1996 Bruce Jones, Henry Spencer, David Wiseman.