Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ukma!husc6!m2c!wpi!wpi.wpi.edu!jhallen
From: jhallen@wpi.wpi.edu (Joseph H Allen)
Newsgroups: comp.editors
Subject: stuff
Message-ID: <1686@wpi.wpi.edu>
Date: 4 Apr 89 07:01:30 GMT
Sender: jhallen@wpi.wpi.edu
Reply-To: jhallen@wpi.wpi.edu (Joseph H Allen)
Organization: Worcester Polytechnic Institute, Worcester, Mass.
Lines: 77

> Why invent another language when we have LISP?

  YUK! YUK! AWK! GREP! YACCC! - sorry, but lisp is definately not on my
top-ten list of "I don't even have to think about it" languages.  BASIC or a
structured language with no punctuation would be much better than lisp as a
editor/macro language.  It's my opinion that the only reason we find lisp as a
macro language in so many environments is that it only takes about 1 day of
programming to implement a simple (gnu-emacs-mlisp like) lisp interpreter.  

> EMACS is so slow!

  There is no excuse for an editor to be slow- even on heavily loaded
machines.  If the editor is properly designed, then the number of operations
needed to do any simple editing function like positioning the cursor or
inserting typed-in text should be negligable- even if you have to interpret
lisp.  GNU-EMACS is slow because when you do cursor positioning (that is, when
you do anything), it has to _search_for_ '\n's.  It would probably be much
faster if it used the 'doubly linked list of lines' approach instead of the
'extracted buffer approach' of accessing the buffer in memory.  For example,
vi is 4 times less CPU hungry than emacs is.  No way is all of that due to
EMACS being lispified.  

  Two other speed problems bother me.  First, there's the "network-slowness"
problem.  I'm writting this message on an ENCOREmultimax.  This is an
extrememly powerfull multiprocessing unix machine on which even GNU-EMACS
flies.  The ENCORE has three cables comming out of it:  the power cord, the
console terminal line and an ethernet cable.  Even though the ENCORE is fast,
terminal I/O can be slow because at any given time, there's 100 people on the
network.  To make matters worse, the full network protocol overhead is invoked
for each characer you type.  With this overhead for each character, the line
speed ends up being equivelent to about 300 baud.

  To try to get around this problem, ENCORE decided to build a simple editor
into their 'annex' ethernet terminal server.  The terminal server does as much
editing as it can without communicating with the host.  As soon as you do an
edit function which requires information which the terminal server doesn't
have, the terminal server dumps all the characters you've typed so far to the
host for a screen update.

  This leads us to the next speed problem:  stupidness when dealing with slow
terminals- or terminals on 1200 baud phone lines.  Networks and, to a lesser
degree, unix really like to bunch data into large blocks to increase
throughput.  This is a terrible thing for slow terminals because it means
large outputs can't be 'interrupted'.  If you accidentally hit the page-down
key, then you have to wait 1/2 a minute for the screen to be restored.  And
God help you if you have a terminal which can't insert characters...
- - - - -

So, my wish-list for an editor is:

 * every long operation must be abortable
 * every lengthy screen update must be interruptable
 * it must be easy to program
 * the following commands HAVE to be single key or control keys with none of
   that vi mode switching junk:

	Cursor up	Cursor down	Cursor right	Cursor left
	Page up		Page down	Word left	Word right
	Beg. of line	End of line	Delete char.	Delete word
	Delete line	Delete to eol	Search/Replace next thing
	Insert a previously cut/copied block		Undo
	Enter ctrl char

 * the following commands should take no more than 2 key-presses to get:

	Top of file	Bot of file	Search		Insert/overwrite
	Goto line No.	Shell escape	Exit and save	Exit and abort
	Insert file	Cut/Copy block	Save block to file

 * DEL and ^H must both backspace

 * And, most importantly and with religeous intensity, when moving between
   lines, the cursor MUST NOT EVER change column position.  If the cursor gets
   placed after the end of a line or if it gets placed in the middle of a tab
   field, then, on the next command which requires the cursor to be in a valid
   position, the cursor should jump to the beginning of the next line, end of
   current line or beginning or end of the tab field, depending on the command.