[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Keyboard inputs

>        On interactive streams users may have the possibility of
>erasing typed characters.  What happens if listen? returns true and
>then the user erases the character?  The program which invoked listen?
>will probably attempt to read a character thinking that it will not
>hang but it will.  We had this bug and went to a fair amount of hair
>to get it fixed.

This problem doesn't arise if the rubout handler is implemented
using READ-CHAR.  The system should be designed this way if you
expect to implement an Emacs-like editor in Scheme.

If the rubout handler is at a lower level than READ-CHAR, then
the system is probably set up so that the user first edits her
input using rubouts and whatever other facilities are available
(cut and paste using a mouse, Emacs, whatever).  Let's say that
this input is liquid.  When the user is satisfied with her input
she does something to signal that the input should be sent to
Scheme, perhaps by typing the "Execute" key (on the HP 9836) or
the "Enter" key (on the Macintosh).  At that moment the input
should be frozen so that it cannot be edited further.  At any
given time the input buffer for READ-CHAR may contain older
characters that are frozen as well as newer characters that are
liquid.  READ-CHAR should return only frozen characters, and
should hang if there are none. The LISTEN? procedure (or whatever
we wind up calling it) should therefore return true only if there
are frozen characters in the buffer.

It is possible to design a system that can switch back and forth
between the first way and the second way. (Unix calls these raw
mode and cooked mode.)

>       We have not talked at all about keyboard interrupts.  It
>seems to me that any reasonable implementation should provide a
>way for the user to (at least) abort an infinite loop.  It would
>be nice if we had a simple standard mechanism for doing this, but
>implementations would be free to have more keyborad interrupts
>(we currently have 5 by default).  I propose that we choose some
>control character (^G, for example) which on all implementations
>and unless inhibited (an editor may want to do this) will
>interrupt Scheme and make it return to the top-level
>read-eval-print loop.

Yes, any reasonable implementation must have keyboard interrupts,
but we shouldn't standardize on the characters.  Consider Scheme
312, which runs under four very different operating systems.
Under CP/M-68k, control-G is fine as the interrupt character, and
an operating system convention leads users to expect that
control-C will leave Scheme for good (it does).  Under Un*x,
however, users expect SIGINT to be the interrupt character and
SIGQUIT to be the abort character; usually these are control-C
and control-\, respectively.  Under HP Pascal the HP 9836
"Execute" key is rigged to send a control-C; it doesn't make
sense for "Execute" to interrupt or abort.  The Macintosh doesn't
have a control key (the command (cloverleaf) key is something
completely different); pull-down menus are probably more
appropriate.  In short, no matter what conventions we could
choose, they would be wrong for some machines.