Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!think.com!paperboy!hsdndev!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.unix.questions
Subject: Re: Type-ahead in unix
Message-ID: <15845@smoke.brl.mil>
Date: 16 Apr 91 01:36:43 GMT
References: <+G-_A&=@warwick.ac.uk> <50ed9956.cb12@dabo.citi.umich.edu> <-Q=_Y$_@warwick.ac.uk>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 23

In article <-Q=_Y$_@warwick.ac.uk> cudcv@warwick.ac.uk (Rob McMahon) writes:
>On a constructive note, I used to quite like the Burroughs MCP/CANDE approach
>of holding up output while you were half-way through an input line, allowing
>you to see and edit the line you were typing, and then releasing it when you
>hit return, until you had typed the first character of the next line.

Yes, but one problem we had with that was that a partial input (say, a
space character) would block output indefinitely, which could be bad news
if urgent messages were piling up.

>On the whole, though, with ^R, and with automatic reprint when you try to
>delete a character that's before a chunk of output, I prefer the Unix
>approach.

Not all flavors of UNIX implement those features, which are typical of a
"BSD-style" terminal handler.  Recently, such features have been creeping
into AT&T UNIX System V-based implementations.  However, not all of them
are done right.  We have serious problems, for example, with the BSD-style
terminal handler on SGI Irix 3.3.1 when used with DC3/DC1 flow-controlling
terminals and various screen editors (also, ^V in such a mode sometimes is
taken as a literal ^V character and sometimes causes a "literal-next" of
the following character).  The history of such features has shown that it
is hard to get them to ALL work together correctly.