From: utzoo!decvax!ucbvax!C70:editor-people
Newsgroups: fa.editor-p
Title: 
Article-I.D.: ucb.1179
Posted: Tue May 25 21:10:44 1982
Received: Sat May 29 03:11:30 1982

>From KLOTZ@MIT-AI Tue May 25 20:10:48 1982
Since most of the people reading this won't know who I am, I'll
explain somewhat.  I've worked on EMACS here for a while, involved
with suggested changes for about two years.  I also worked with
the Logo group and participated in the design of a small editor
for children to use with Logo on micro's.

We chose to use the EMACS model of text in the editor, and found
that it works quite well with kids.

I've used editors on various machines which have some of the
``features'' described in previous messages: truncation instead of wrap
on long lines, replace-mode editing, and ``anything-goes'' cursor
motion.  I found that I dislike them, and feel glad that there is at
least one editor that does what I consider to be the right thing.

I think that it would be a grievous error to change the basic organization
of EMACS in order to speed it up on a not-yet-fully-designed machine.
EMACS has had many years of user-testing, whereas (I suspect) the
proposed optimizations for the 2080/IO-processor scheme are based on
models of what programs do that don't include the sort of processing
that EMACS does.  Perhaps the DEC designers are aware of EMACS
behavior, but don't think that it's important.  Frequently, people think
of an editor as ``just another program'' and don't consider it's exact
behavior very important; however, many people (including me) spend most
of their logged-in time in an editor, and if it does something that
makes me have to stop and think about the fact that I am editing text
using an editor, then it is disrupting my train of thought and impeding
my work.

I think that the proposed feature changes would be detrimental, but I'm
not going to explain why because everyone probably knows anyway.  I just
think that those who are arguing for the changes might want to consider
that the current behavior might be very important, and that any editor
without it would not be EMACS.  (Just a thought:  If the people who
now know TECO and maintain EMACS decided that the new editor wasn't
EMACS, then who would maintain it?  I guess the new editor would
probably be re-implemented in another language, anyway.)

While I think that a discussion of these basic issues of EMACS
display and its model of text are useful in a basic discussion of
editor technology, I don't think they are very important with respect
to the task supposedly at hand -- converting ITS/TOPS20 EMACS to run
efficiently enough on the 2080 to encourage people to use it.

What I would like to see (and participate in, if I had anything to
contribute) is a discussion about how to implement RMS's local-editing
protocol, or something like it, in the 2080/io-processor system.  Also,
(of course) ideas about other, completely different schemes of allowing
EMACS to run efficiently.

Leigh.