gnu@sun.uucp (John Gilmore) (04/24/85)
I heartily agree with the guy who said if you're smartening the Unix tty interface, look at how DG did it in AOS. Not only did they make it better and more featureful, they cleaned it up a lot too. A simple example: on Unix if you read() 512 chars from a terminal you get up to the next terminator. You can't get that behaviour from a file. AOS lets you open any file or device for "data-sensitive" reads as well as raw character count reads. (And if you open a terminal for raw char count reads, it waits until you type that many chars! Now if only Unix would do that...) Of course you can set the delimiter table (256 bit table) and the default is reasonable (CR, NL, and suchlike). You can specify data sensitive/char count/various other options in each read() call to override the way you open()ed it, if you like. All of the above is independent of the "screenedit read" interface described by the preceding message. This facility adds a standard interface for editing input lines, kinda like Unix cooked mode but (important!) it knows about cursor positioning, insertion, and deletion, so you don't have to retype the whole line to fix a typo in the first word. You'd be amazed at the difference. (Some DG expatriates who moved to Microsoft hacked a Bourne Shell that did screenedit reads, probably in cbreak or raw mode or something. I don't know if it ever got put in their kernel, or released as a product.) Note that the kernel need not know anything about escape sequences to position the cursor within a single line (use BS or the next char on the line), insert (repaint to the right) or delete (ditto). Updating speed is not a problem for typical input lines on hardwired terminals, and if you're on a 300 baud line, you don't have to use the screenedit features now do you?
henry@utzoo.UUCP (Henry Spencer) (04/29/85)
> I heartily agree with the guy who said if you're smartening the Unix > tty interface, look at how DG did it in AOS. Not only did they make it > better and more featureful, they cleaned it up a lot too... If I were being snide, I would say that "better"/"cleaned up" and "more featureful" are direct opposites... Who, me? Snide? Nah... -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
throopw@rtp47.UUCP (Wayne Throop) (05/01/85)
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