Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!dog.ee.lbl.gov!elf.ee.lbl.gov!torek
From: torek@elf.ee.lbl.gov (Chris Torek)
Newsgroups: comp.unix.questions
Subject: Re: Type-ahead in unix
Message-ID: <11909@dog.ee.lbl.gov>
Date: 9 Apr 91 01:48:29 GMT
References: <7297@utacfd.UUCP> <659@adpplz.UUCP> <15686@smoke.brl.mil> <659@rufus.UUCP>
Reply-To: torek@elf.ee.lbl.gov (Chris Torek)
Organization: Lawrence Berkeley Laboratory, Berkeley
Lines: 71
X-Local-Date: Mon, 8 Apr 91 18:48:29 PDT

[Beware, heavy religion below... I must be feeling extra grumpy this
morning.]

>In article <15686@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) notes:
>>UNIX has "always" supported type-ahead.
>>I think what you are discussing is deferred echo.
>>Why would you have to have that?

In article <659@rufus.UUCP> drake@drake.almaden.ibm.com writes:
>I think they are discussing deferred echo, too.

(Doug already said that....)

>As for why you have to have it ... well, it would sure be nice to be
>able to type the next command without ruining the appearance of the
>output of the current one!

True ... but deferred echo is not the way to do this.  Deferred echo
is even more broken than immediate echo.  The *only* right thing is
immediate-echo-unless-it-would-not-be-echoed-when-read followed by
drag-user-echo-along-in-front-of-output.  That is, if you type

	% compute
	_

(here the underscore represents the cursor position) and compute runs
for two minutes, then prints an answer, and you type `compute2<RETURN>'
in the meantime, the screen should show:

	% compute
	compute2
	_

When `compute' finishes the screen should look like this:

	% compute
	The answer is 42.
	% compute2
	_

If, on the other hand, you type

	% compute

and compute runs for two minutes, then demands a password, and while it
is running you type `mypassword<RETURN>', `mypassword' (and possibly the
RETURN) should *not* appear on the screen.

Both of these are far too much work for me to want them done in a `tty
driver' (or `streams module' or ANYthing in the kernel), so even though
these are both required to make typeahead echo truly work, I am just as
happy that typeahead echo does not `truly work'.  As such, I much prefer
immediate echo (and if I used VMS, and were therefore limited to VAXen
---which are, these days, horrendously slow---I would *really* hate
waiting for the computer just so I could see if I made any typos).

Now, if I had a GNOT, I would get `sliding echo-ahead' `for free',
which solves most of the problem---password typeahead is very rare and
`do not echo if future events would cause this not to be echoed' is an
unreasonable demand.  Or I could use Emacs, which almost gets it right
(Emacs does not get an `input taken' message and therefore cannot know
when to stop sliding typeahead; it uses a completely different trick).

The reason this can be done on the GNOT is that the GNOT knows it is
a GNOT, and in this case the `terminal' is part of the whole O/S.  I
do not want to make the VMS mistake of assuming everything is a (VT100,
Wyse, pick-some-favorite-brand), therefore I do not want screen control
in my kernel.
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov