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<SPACE>" and "x"
can both be used to delete a single character. When the verb is
omitted VI assumes "move": thus <SPACE> 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 <RETURN>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 <RETURN> 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 <
[email protected]>
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.
