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