Keyboard inputs

[Bill Rozas <JINX%MIT-OZ@MIT-MC.ARPA>]

	I think you don't understand the problem with listen?

	The system need not have a rubout handler written in Scheme to
have an Emacs-like editor.  MIT-Scheme has a rubout handler written in
Pascal (almost all IO is written in Pascal), and Edwin (Chris Hanson's
editor) works perfectly fine, since it bypasses buffered IO.

	We have two kinds of terminal read-char: One is used by the
reader, and is buffered (no characters are given to Scheme until some
key (Execute on HP9836, Newline on UNIX) is typed).  The other is
immediate (it returns as soon as a character is typed, without waiting
for any special character).  The former is much more efficient under
some operating systems, and eliminates the need for a complicated
rubout handler since the reader never needs to back out (according to
GJS, 1/4 of all the code of MacLisp at some point was the rubout
handler).  Having an Emacs-like front-end is not incompatible with
this, since the front-end need not give any characters to Scheme until
no further character-level processing is needed.

	It is inconvenient, however, to do all input in this mode (I'd
hate to have to type a newline after a single character command to a
debugger, for example).  This is why we have immediate read-char also,
which is the default.  Users can type asynchronously, and frequently
do so ahead of the system.  For consistency, the user should be able
to edit (especially rub-out) his typeahead until it is read.  Since
the system does not know whether the next read-char will be immediate
or not, it cannot lock the required characters unless it locks all,
clearly unpalatable.

	The problem with listen? arises, for example, from programs
which ask for confirmation or a simple choice but assume a default if
no input becomes available in some period of time.  Assume that the
user types a character, the program invokes listen? which returns
true, and the user then deletes the character before the program has
had a chance to invoke immediate read-char.  This is quite likely on a
timesharing system, where the user may delete while Scheme is not the
current process running.  Clearly the program will hang while it
should not (it was intended that it "time-out").  Clearly listen? is
wothless unless it applies to both liquid and frozen characters
(otherwise a terminator would have to be typed after the option,
ugh!).  The problem is trivially solved if listen? locks the
character.

	I believe that this problem can arise even if there is no
buffered io in a system.  On Lisp systems that I know (including
MacLisp and Lisp Machines), rubout-handling is built into read, not
into tyi, and therefore user programs that use tyi rather than read do
not (by default) allow users to rub-out their input.  If you allow
rub-out on read-char throughout the system (which is certainly
desirable), the problem potentially exists.

	Since adding this extra constraint to the definition of
listen? solves all these bugs and allows implementors of the
io system greater freedom, I think it should be added.

	On my previous message I advocated for eliminating listen? in
favor of non-hanging-read-char, but I drop this.  Chris Hanson has
pointed out that unless untyi were provided, this would be the cause
of pretty ugly code.