CSUN NOS Screen Text Editor Proposal


	Screen text editors are the desired text preparation method
on many computers.  Due to the extensibility of the text editor EMACS
developed at MIT by Richard M. Stallman,  a standard for text editing 
has begun to emerge.

The desired features are:

	1) Real time screen update.
		Any changes made by the user appear on the screen 
		immediately.  The user should feel as though he is a
		physical part of the text he is editing and able to
		"manipulate the text with his fingers"

	2) Terminal independence.
		The user should be able to use the editor on any terminal,
		even a printing one.

	3) Extensibility.
		This is one of the most important aspects.  EMACS has
		developed its default set of commands through the user's
		ability to define new editing procedures at run time.
		When a command is needed that is not present, the user
		creates it using a built in "extension language", and then
		binds it to a set of keystrokes for execution.

		The extension language used in the original (PDP 10)
		implementation of EMACS is MIT's special version of TECO.
		Later implementations of EMACS (Multics, Vax) have used
		LISP as the extension language.  (In the case of the MULTICS
		implementation,  the entire editor is written in LISP)


VAX Emacs was written by James Gosling of Carnegie Mellon University, and
is the editor of choice for placing on the CYBER.  It is well written,
supports many terminal types (including VT100 and Teleray), is well
documented, and (since it was developed using Arpanet Resources) is 
available at no charge.

The major obstacle to successfully installing Emacs on the Cyber is the
Cyber's means of handling terminal I/O.  A request for terminal I/O
will nearly guarantee that the user will be swapped out.  This is also
a problem on Multics, where the solution used was a protocol called
echo negotiation.  This worked on the principle that the most commonly
performed operation that the user would need "real time  performance"
for is entry of fresh text.  The original implementation of Echo 
Negotiation took into account only entry of text at the end of a line.
The editor would request X number of characters, and would pass to the
front end processor (FNP, similar in concept to a cyber PPU) a bit mask
which determined which characters could be echoed. Any unechoable characters
were considered to be exceptional conditions (either commands, or characters
which required special ecoing).  When such an exceptional condition occurred,
the FNP would cease echoing, and pass it's buffer of received data to the
editor running (or more likely swapped out) in the CPU.  Once the editor
awoke,  it would process the buffer of input passed to it, but not yet
update the CRT screen. It would then make a second I/O request, this one
being a "no wait request" to see if any more characters had been typed
between the time the FNP stopped echoing and the current time. (which was
very likely- after all the process had been swapped out on a loaded system
and had to be swapped back in to execute).  The editor would then process
this input if it exists, and subsequently update the screen to reflect
the new state of the buffer.  Ironically, this scheme is most efficient
on a heavily loaded system.

A more advanced scheme is one called "local editing protocol", devised by
Richard M. Stallman of MIT (who incidentally was the originator of Emacs).

Local editing protocol is designed to be implemented on small intelligent 
terminals communicating with editors on large mainframes, or in small
computers used as terminal processor front ends to main frame computers.

There are many degrees of sophistication to LEP. At MIT, it is implemented
as a program running on LISP machines (small dedicated computers on the
Arpanet) that maintains an image of a portion of the users text buffer in
core, and allows editing commands to edit this local core copy instead of
the copy in the editor.  It periodically passes terminal editing commands
in "batches" to the main EMACS editor running on the MIT-AI lab PDP-10,
and also passes on any commands that it cannot handle.  In order to be able
to do this, the Local Editor knows of common operations such as cursor
movement, character deletion, means of insertion, what constitutes word/
sentence delimeters,  and so forth. It also keeps on hand the text "most
likely to be called to be displayed".  EMACS tells the local editor
what characters to echo normally, how long lines should be, terminal
characteristics (needed to accomplish defined functions) and so forth.
It is necessary for the local editor to be able to change character binding
upon command, since the meaning of a typed character may change with context.

This is much too complicated to envision being correctly implemented in the
CSUN Cyber. It would take so much work that the computer center would find
that the hassle of getting it running would outweigh acheivable benefits.

Instead, I think that a compromise between local editing and simple echo
negotiation is probably the best approach. I envision a small editor
capable of handling one single input line being used. This would be part
of the terminal driver.  It would be capable of no more than horizontal
CRT motion, and keeping track of what characters were in what part of the
buffer.  The editor would send a line to the terminal driver consisting of
the current line, the driver would make any changes on the CRT needed to 
make the CRT line match the passed line and then interactively edit the
current line with no help from the CPU.  When some exceptional condition
occurred, a record of all changes would be passed back to the CPU program,
or better, to someone locked in core with whom all editor processes could
communicate.  This is a simplification of what needs to be done, but should
be basically a sound outline. The important thing to note, is that the editor
can be swapped out a lotof the time without any degradation of response 
to user requests.