[fa.editor-p] EDIT/TOPS-20

C70:editor-people (05/27/82)

>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 --
-------

C70:editor-people (06/03/82)

>From Mishkin@YALE Thu Jun  3 01:53:00 1982
[Editor's note:  with the consent of the authors, I am trying an
  experiment of publishing related messages together as a single one.
  Let me know if you like this scheme:  perhaps in future we'll experiment
  with a debate format like that used in Behavioral & Brain Sciences. ]

         (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...

I don't mean to be persnickity or anything, but is this kind of thing going
to make a big difference in view of the fact that god knows how many
instructions are executed when you call a JSYS?

    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.

I don't want to overestimate our influence but aren't WE the people these
XON/XOFF terminal manufacturers are selling their wares to?  I mean, if we
don't like it, let's bitch not acquiesce; don't buy their terminals.  I don't
know much about terminal hardware, but isn't XON/XOFF a wimpout solution.
Why do some terminals need it and some not?
  -------
Date: 29 May 1982 1434-PDT
From: ADMIN.MRC at SU-SCORE
Subject: Re: EDIT/TOPS-20
In-Reply-To: Your message of 29-May-82 1317-PDT

     The research community really does not have that much influence with
terminal manufacturers.  It may well be in a few years you won't be able
to buy a terminal which does not have XON/XOFF.  All of my conversations
with terminal manufacturers seems to indicate that that will be the
tendency.

     A lot of the TOPS-20 jsi are being rewritten to do if/else type
stuff in an efficient way for the Jupiter.  If EMACS did I/O in an
efficient manner (just doing output buffering and using TEXTI, not
drastic changes in EMACS' user interface), it probably wouldn't be very
JSYS-intensive.

-- Mark --
-------
Date:    31-May-82 8:57PM-EDT (Mon)
From:    Nathaniel Mishkin <Mishkin at YALE>
Subject: Re: EDIT/TOPS-20

The XON/XOFF stuff seems like a loss and it seems too bad that we can't do
anything about it.  Perhaps someone else knows the issues and tradeoffs of
the terminal design.

		-- Nat
-------