Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site rtp47.UUCP Path: utzoo!linus!philabs!cmcl2!seismo!harvard!talcott!panda!genrad!decvax!mcnc!rti-sel!rtp47!throopw From: throopw@rtp47.UUCP (Wayne Throop) Newsgroups: net.arch,net.unix-wizards Subject: Re: dumber terminal device drivers // DG AOS does it right Message-ID: <33@rtp47.UUCP> Date: Wed, 1-May-85 16:37:03 EDT Article-I.D.: rtp47.33 Posted: Wed May 1 16:37:03 1985 Date-Received: Sat, 4-May-85 18:37:16 EDT References: <327@piggy.UUCP> <2536@nsc.UUCP> <524@hou2d.UUCP> Organization: Data General, RTP, NC Lines: 72 Xref: linus net.arch:952 net.unix-wizards:10196 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 $ $ 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 $ bar $ bletch 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 ":" 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 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 !mcnc!rti-sel!rtp47!throopw