From: utzoo!decvax!ucbvax!C70:editor-people
Newsgroups: fa.editor-p
Title: EDIT/TOPS-20
Article-I.D.: ucb.1198
Posted: Thu May 27 06:33:49 1982
Received: Sun May 30 00:43:24 1982

>From C70:daemon  Thu May 27 02:03:20 1982
Folks -

     I find myself agreeing with the EMACS'ers even though I've
been a critic of EMACS myself.  EMACS may well be in some ways
the FORTRAN of display editors; perhaps everybody hates it, but
they won't use anything else.  What I was originally bringing us
is that the present implementation of EMACS is needlessly
inefficient now, and that inefficiency will cost even more on the
Jupiter.

     There's no reason why we can't make EMACS perform better.
It is completely unfair and unscientific to judge the merits of
EMACS based upon a wretched implementation.  I honestly don't
care if EMACS is written in TECO, or assembler, or Lisp, or
Pascal, or BASIC, just so long as the implementation uses the
architecture it runs on in a reasonable fashion.  What is done
internally is completely irrelevant to the end user.  So my
philsophy is "do whatever the architecture wants internally, but
you better have a damned good excuse to change the user interface
to suit an architecture."

     Some ways I think EMACS can be improved:

     (1) Improve TECO.  Remove all PBOUT and terminal BOUT system
calls, replacing with a subroutine call to a terminal output
buffer routine.  TECO does incredibly silly things like:
	MOVEI A,ESC
	PBOUT
	MOVEI A,"H"
	PBOUT
	MOVEI A,"J"
	PBOUT
 all over the place.  Getting rid of that trash would improve
performance quite a bit.  For terminal input, use buffering as
well; specifically, use TEXTI for ordinary text entry.  If TEXTI
isn't good enough, fix TEXTI; the manufacturer has indicated its
willingness to install the fixes.  DEC wants US to do it; they
thought they had made TEXTI good enough.  They are being sensible
in realizing that we understand what EMACS requires out of TEXTI
better than they do.

     (2) Reimplement EMACS (again, I don't care how it's done).
Understand about paging considerations.  Understand about other
architectural things like on the Jupiter it will be much faster
to do:
	...test...
	 TRNA
	  JRST FOO
	...code...
FOO:
 to execute "code" if "test" does not skip than to jump to
another routine or into a literal (there are system macros to
generate these kind of constructs to enhance code readibility).

     (3) Run in extended addressing; an 18-bit address space is
just too small for large database text processing.

     All these are little things which don't affect the user
interface in the slightest other than to make EMACS much faster.
One thing that would affect users is to abandon the model that
all 128 ASCII characters are available for editing.  In
particular, a reimplementation of EMACS should recognize that
NUL, ESC, XON and XOFF can no longer be considered available
characters if it is to reach the widest possible audience.  As
much as we might dislike XON/XOFF flow control, the word is that
in a few years it may be very hard to find a new terminal that
doesn't use it.  There is nothing worse than having the display
screen garbage because EMACS disables system XON/XOFF processing.

     The thing is, though, all of these can fit within the EMACS
model without invalidating that model.  I really don't believe
that you are going to be able to convince somebody to abandon a
model that she is comfortable with for a new model which may not
even have a working implementation.  I think too that the EMACS
model can be tortured to fit in with the future.  I doubt that
RMS or any other EMACS users would be unhappy at the loss of C-S
if there was a convenient SEARCH key on the keyboard.  If that
key was as easy to type as ^S who cares if it really generates
some character sequence?  What the user sees is what's important.

-- Mark --
-------