From: utzoo!decvax!harpo!npois!ucbvax!C70:editor-people
Newsgroups: fa.editor-p
Title: Re: Improved support for Emacs in TOPS-20.
Article-I.D.: ucb.1310
Posted: Thu Jun 10 00:39:59 1982
Received: Fri Jun 11 00:56:27 1982
Reply-To: ople

>From Goldberg@RUTGERS Thu Jun 10 00:35:54 1982
Date:    24-May-82 12:51AM-EDT (Mon)
	From:    Steve Wood 
	Subject: Re: Improved support for Emacs in TOPS-20.

			...    The design of a display editor is at
	least as important as the design of an operating system or 
	programming language, yet the amount of published research 
	about display editing pales in comparison to the latter two 
	subjects.  Most of what has been written consists of general 
	surveys of existing software.  Very little has been written 
	about what the issues are in the design and implementation of 
	a display editor. ...

I fully agree with this statement, and I would extend it to
editors in general, not just display editors.  In fact, the following
statement appears in my Dec. 1981 Ph.D. thesis on distributed editing 
architectures (which has not yet been sent by Rutgers to University	
Microfilms, grrrr):

		Text editors are of greater importance than generally
	recognized.  They are arguably the most important class of
	programs in existence, because of their central role in any
	application, and because of the amount of time people spend
	using them.  Computer Scientists have studied the design
	of operating systems and programming languages in great 
	detail,	but have generally regarded text editors merely as
	utility programs.  In reviewing the literature on the subject,
	one finds that very little has been written beyond broad 
	surveys of existing software, and almost no analysis has been 
	done of the design decisions faced by the implementor of a 
	text editing system.

	I have nothing to add to the discussion of editor user 
interfaces, and in fact quite pointedly avoided that issue in my
thesis, beyond asserting that a good architecture should allow any
reasonable user interface.  Building some restricted interface into
TEXTI violates this principle, though I suspect that a few of the
more common editing situations (such as adding text to the end of the 
file or line) could be optimized in a given editor using some suitably
designed jsys.  Indeed most timesharing editors go to some pains to 
optimize normal insertion of characters at the end of a line as a 
special case (including, I believe, TWENEX EMACS).

	I see two consistent themes in the correspondence here:
1) dissatisfaction with the editing response on a timeshared host, and
2) the desire to have one's preferred user interface and file model.
One contributor suggests that we all buy powerful single user systems
and use timeshared hosts as file servers, etc.  That is fine if you
can afford it.  Perhaps the cost of powerful single user systems will
fall enough in 5 to 10 years so that this may be an option to more 
than an elite few.

	In the mean time, given the economic reality faced by most of 
us that says we must use a timeshared host as both the file server and
file processor for compilation, text processing, etc., I suggest that
an editor distributed between the host and a dynamically programmed 
terminal/microprocessor does a good job of addressing these two 
themes.  

	In terms of the alternatives raised by the correspondents
of this mailing list, what I propose (as *one* alternative, not the
*only* solution, mind you) is to handle most of the local cursor
movements, insertions/deletions, local searches, etc. in the local 
terminal+processor itself.  Simulating one possible scheme for doing 
this, I found that the average editing session at Rutgers would 
require on the order of only a dozen user-observable host wakeups (the 
rest would occur in the background, and there would be many fewer 
total host wakeups than user keystrokes).  

	Note well that the local terminal+processor interface would 
have to be written to communicate with a specific program on the 
host, assuming the same file model as the host editor server with
which it communicates; an IBM block mode style "general editing 
terminal" is totally inadequate unless one does not care what the user 
interface looks like.

	A further benefit of this approach is that the effective rate
of communication between host and screen can be made much higher than
the actual connection bandwidth, through judicious saving of 
previously displayed text and predictive background fetching of the 
"next" screenful.  In fact, much of the time the window motion would
not require host communication.

	The performance claims I make here are backed up by hard 
evidence in my thesis, from analysis of 15,000 actual editing sessions
using a variety of editors, and through simulations of proposed
schemes using the file-reference data obtained during these sessions.

	Let me apologize again for the bureaucratic snail's pace at
which Rutgers University's thesis handling office crawls.  I asked
the University to send out some copies to some of you (did anyone get
one yet?) and hope to have it made available though University 
Microfilms for the rest of you.  Unfortunately, the heart of the
work is the editing session analysis, which I have summarized in about
50 plotted graphs and figures, so electronic distribution is not 
feasible.
				Bob
-------