C70:editor-people (05/26/82)
>From LAWS@SRI-AI Tue May 25 19:33:54 1982
I am not surprised that authors of successful editing systems each
prefer their own. As a user, I see merits on both sides and would
like to see both systems flourish. My own preferences on particular
features are noted below. Since they are just preferences, it would
seem reasonable that other options be available in the same editor
or at least in other editors on the same operating system.
* I like the character string model of a text file for editing
raw data from tapes and for converting one character set to
another. Unix is built around stream I/O, and it works very
well. The "stream editor" is particularly handy for processing
large text files in some uniform way.
I prefer the quarter-plane model for document editing.
One place it wins is in moving blocks (not full lines) of
text around. Top-level replace mode is best with this model.
(My experience here is with the Rand editor NED.)
For special purposes I prefer a special editor or mode. A LISP
editor is essential for LISP coding, and VisiCalc is excellent
for worksheet computations. For graphic arts or newspaper layout
I would want a formatting editor as in XED or Smalltalk.
* I like an editor that understands my problems and gives me tools
(and a language) for dealing with them. For general text processing
I like the built-in primitives of VI (character, word, "metaword",
line, sentence, paragraph, section, and matching parenthesis
or bracket). Vanilla EMACS is less knowledgeable but more flexible,
particularly in the LISP-based versions: I would prefer it if I were
building a bibliography editor or other special-purpose system.
Even with a smart editor that understands my text I would like
a good cursor system. The vanilla EMACS bindings of ^F, ^B, ^P,
and ^N are exceedingly awkward, and the VI bindings of h, j, k,
and l are not much better. Sometimes I just want to get from here
to there, and many editors make this difficult.
A good cursor system is even more important when the editor does
not understand the text. As an example: Most of my work is done
with word motion and word-oriented commands. In my programming
work, however, I must deal with variable names such as newimghdr
or ImageColumnsPerBlockRow. I have yet to find an editor that can
tab into these composite words intelligently, so I must rely on
cursor motion no matter how clumsy. (With a mouse, of course, I
might prefer cursor motion to all other systems.)
Given that keyboard cursor control is necessary, I think it
integrates best with the quarter-plane model and top-level replace
mode. I should also be able to move the cursor between editor
windows -- other commands should be used to control text scrolling
within a window when more than one window is present.
* I also want to have available a marker system. EMACS offers only
one marker other than the cursor position, and its use is stream-
oriented. NED's marker pair is "block-oriented". SOS offers
multiple line markers (as well as line number addressing). VI
has (invisible) line numbers and multiple markers with both
stream-oriented and line-oriented commands. (VI needs them to
offset the lack of multiple editing windows.) Why can't one
system give me all of the above?
* As for conversion of tabs to spaces (or vice versa): This certainly
should not be mandatory (and no one has suggested that it should be).
For text processing I usually prefer spaces -- adding one character
to a word should not make the next word jump seven spaces. For
tabular work I might prefer tabs. For programming I ordinarily want
things left as they are. Just don't make NED's mistake: conversion
of tabs to spaces only on lines that are actually edited.
Sorry if this sparks a religous war. My thesis is that an editor should
offer every conceivable primitive capability (hard-wired or via extensibility)
and that the user should be able to have any subset easily available. If
only subsets can be implemented then the choice must be made intuitively,
or through controlled studies, or through user surveys. I have cast my
votes above.
-- Ken Laws
-------C70:editor-people (05/27/82)
>From C70:daemon Thu May 27 02:54:46 1982
*from: BOB (Bob Frankston)
Local: editor-people at mit-ai
Original-date: 23 MAY 1982 18:16:56
Remailed-date: 27 May 1982 0004-PDT
Remailed-from: J.Q. Johnson <Admin.JQJ at SU-SCORE>
Remailed-to: Editor People: ;
Seeing the latest cruft coming by, I thought I should add a few
(brief?) comments:
1. I can't find the arrows on most keyboards with my
fingers, but I can find keys with mnemonic associations
on the home keys (Next/Previous, Backwards/Forwards).
I switch keybroads alot -- typically using on with each
hand.
2. For the EMACS I implemented on Prime, I have both 2d
mode and 1d mode. Typically I run in 1d mode, but edit
tables using 2d mode in conjunction with replace mode.
3. I have only limited sympathy for trying to offload
echoing to the terminal since computers are getting
quite cheap. Unfortunately, packet charges on networks
are such that it is probably cheaper to dialup cross
country than use a packet net for Emacs,
Thus local echoing has a value. Multics echo
negotiation appears to be a reasonable attempt at this.
The echoing is done by a separate communications
processor which can be located near the terminal and is
given a simple rule such as echo until you see "n"
characters or see a nongraphic. It should be possible
to specify a set of tables or choose one so that people
can rebind keys without being stuck with the wired in
bindings. If one rebinds alot of keys (to implement
replace mode for example) one might not be able to use
a general purpose approach, though the editor should
know about the common ones to optimize them. The basic
rinicple is taht these optimization should help in
common cases but should not restrict what can be done
if the user is willing to accept less efficiency.
Ideally the degradation should be gradual so that
rebinding the "A" key does not prevent the use of any
local echoing.C70:editor-people (06/01/82)
>From Greenberg.Symbolics@MIT-MULTICS Tue Jun 1 13:05:00 1982
Echo negotiation as designed and implemented on Multics resends
a bitmap of what of 128 characters are breaks at the first
call to echo-negotiatedly read after rebindings have been done.
Thus, switching buffers and modes back and forth in an extension
does not cause this to happen until it is time to actually read.
There is no more expense involved with making "A" a break character
than Carriage Return. EVEN THE LISP-LEVEL EXTENSION WRITER is not
aware, and need not be, of echo-negotiation.