dumber terminal device drivers // DG AOS does it right

[Wayne Throop]

Pardon me if someone else has noted this, but there is another important
area in which the DG terminal interface is "right", in terms of how it
parcels out work between the host and a smart terminal driver.

Others have mentioned two things.  First, there is a 256-bit-long
delimiter table, which gives those characters that will terminate a read
(DG missed out having another 256-bit-long echo-this-character table,
but this loss is not too bad, since other ways exist to control echo,
ie, there is a "don't echo delimiter" bit).

Second, there is a "screenedit read" feature, so that all vanilla input
has character insert/delete, and left-right cursor positioning, in
addition to the traditional 'delete-last-character' and 'forget current
line'.

But third, AOS and AOS/VS treats echo properly.  Consider typing ahead
to unix:

    $ foo
    bar
    bletch
    <foo output>
    $ <bar output with first line offset>
    $ <bletch output with first line also offset>

On AOS/VS, echoing is done when characters are consumed by a read, so
that typing ahead results in a screen that looks like so:

    $ foo
    <foo output>
    $ bar
    <bar output>
    $ bletch
    <bletch output>

The tradeoff is that you can't see what you type ahead, but it is less
confusing when all is done.  So, why is this "right", when you give up
seeing what you type as you type it?  Well, consider the following two
problems.

Reading of a password.  This normally means, read some preliminary info,
like a username or a filename, then turn off echoing, then read the
password, then turn on echoing.  If the password was typed ahead, it is
likely that it is echoed.  If a command following the password is typed
ahead, it will likely NOT be echoed.  Thus, you must discard typeahead,
to be sure you discourage users from typing passwords while echoing is
still turned on, and you simply put up with some of your command input
not being echoed.  On AOS/VS, since the echo is delayed until the read
is started (and after the echo is turned off), things happen more
naturally, and typeahead can occur cleanly across echo/no-echo modes,
raw/cooked modes, and so on.

Optimizing input to an editor.  Let's say you want to implement vi using
the delimiter table scheme to optimize reads.  If vi does an echoing
read (for example, to do an append), and then the user types
"<esc>:<some command>" quickly, vi won't have time to change echoing
modes and delimiter tables, and the "command" would be echoed by the
terminal driver onto the middle of the screen.  On AOS/VS, the echo of
the string following (and including) the <esc> would be delayed until
the next read, by which time vi would have updated the echo and
delimiter tables appropriately.

Note that it is this last point which is crucial.  The original
discussion was exploring how to push some of the terminal interaction of
a screen-oriented editor out into a smart peripheral.  This cannot be
done unless there is some method of *synchronizing* as well as
*specifying* the echoing to be done (otherwise it might be done at the
wrong screen position).  Also, this synchronization of echo should
happen for mode changes, such as raw/cooked, as well as for echo-status
changes, such as echo-noecho.
-- 
Wayne Throop at Data General, RTP, NC
<the-known-world>!mcnc!rti-sel!rtp47!throopw