single character response

[grobibi]

I have read from

http://rosettacode.org/wiki/Keyboard_input
/Obtain_a_Y_or_N_response#Common_Lisp

this explanation :

"When a single-character input is not accepted till <Enter> it means
your connection to Lisp
is not direct, and whatever is doing your connection has a bug that
makes it not send the input
till it has a whole line to send. Both of the above versions work fine
in Lispworks, and respond
immediately to a single character. To fix a bug that requires <Enter>
when it shouldn't, fix
that in the configuration of whatever sends your input to Lisp. The
main difference in the above
two versions is that the long one uses *STANDARD-INPUT* instead of
*QUERY_IO* which might or might
not make a difference when there is a bug in your connection to your
Lisp environment."

Is this "explanation" relevant?
How can I modify the behaviour of sbcl or clisp, for exemple, to
"respond immediatly" as mentionned above?

Thanks.

[Kaz Kylheku]

On 2015-02-28, grobibi <tristanh...@free.fr> wrote:
> I have read from
>
> http://rosettacode.org/wiki/Keyboard_input
> /Obtain_a_Y_or_N_response#Common_Lisp
>
> this explanation :
>
> "When a single-character input is not accepted till <Enter> it means
> your connection to Lisp
> is not direct, and whatever is doing your connection has a bug that
> makes it not send the input
> till it has a whole line to send.

Out of context, that statement is stupid. Collecting lines of input is a
feature of operating systems (POSIX TTY line disicpline in "canonical input
processing mode") and some devices and protocols.

That is a feature, not a bug.

> Is this "explanation" relevant?
> How can I modify the behaviour of sbcl or clisp, for exemple, to
> "respond immediatly" as mentionned above?

On what platform? If the input stream is connected to a Unix TTY, and that TTY
is in canonical input processing mode, then the only way to fix it is to
change the TTY operation with tcgetattr/tcsetattr: either directly yourself
via FFI, or through some library function provided by the Lisp implementation
for switching to a raw input.

[Pascal J. Bourguignon]

In the case of clisp, you can use the KEYBOARD package (in combination
with the SCREEN package, you can make nice things in clisp).

http://clisp.org/impnotes/


--
__Pascal Bourguignon__ http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

[Rob Warnock]

Kaz Kylheku <k...@kylheku.com> wrote:
+---------------

| grobibi <tristanh...@free.fr> wrote:
| > How can I modify the behaviour of sbcl or clisp, for exemple,
| > to "respond immediatly" as mentionned above?
|
| On what platform? If the input stream is connected to a Unix TTY,
| and that TTY is in canonical input processing mode, then the only
| way to fix it is to change the TTY operation with tcgetattr/tcsetattr:
| either directly yourself via FFI, or through some library function
| provided by the Lisp implementation for switching to a raw input.

+---------------

Indeed. SBCL and CMUCL can do this via their "alien" facility,
executing "tcgetattr/tcsetattr" more-or-less directly. In CMUCL,
see UNIX:UNIX-TCGETATTR and UNIX:UNIX-TCSETATTR. [Note: A fairly
clean implementation of a READ-CHAR-NO-ECHO-CBREAK (several years
ago) took me ~15 lines of CL code.] In SBCL, the package [and
perhaps the symbol names] will be different, but equivalent
functions should be available.

And as Pascal B. already noted in a parallel reply, CLISP can
do this through its SCREEN:WITH-WINDOW and EXT:WITH-KEYBOARD
facilities on both Unix/Linux and MS Windows, see:

http://www.clisp.org/impnotes.html#screen
http://www.clisp.org/impnotes.html#with-kbd

To reinforce what Kaz said, doing this sort of stuff is *very*
platform- and CL implementation-dependent! You have been warned. ;-}


-Rob

p.s. For comparison, this is (roughly) what the FreeBSD "less"
program [in C] does to get into cbreak mode on the terminal,
where "s" is a "struct termios":

s.c_lflag &= ~(ICANON|ECHO|ECHOE|ECHOK|ECHONL);
s.c_oflag |= (OPOST|ONLCR|TAB3);
s.c_oflag &= ~(OCRNL|ONOCR|ONLRET);
s.c_cc[VMIN] = 1;
s.c_cc[VTIME] = 0;

You need to save & restore the old values around the read of
the character, of course...

-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <http://rpw3.org/>
San Mateo, CA 94403

[tar...@google.com]

On Saturday, February 28, 2015 at 3:44:38 PM UTC-8, Kaz Kylheku wrote:
> On 2015-02-28, grobibi <tristanh...@free.fr> wrote:
> > I have read from
> >
> > http://rosettacode.org/wiki/Keyboard_input
> > /Obtain_a_Y_or_N_response#Common_Lisp
> >
> > this explanation :
> >
> > "When a single-character input is not accepted till <Enter> it means
> > your connection to Lisp
> > is not direct, and whatever is doing your connection has a bug that
> > makes it not send the input
> > till it has a whole line to send.
>
> Out of context, that statement is stupid. Collecting lines of input is a
> feature of operating systems (POSIX TTY line disicpline in "canonical input
> processing mode") and some devices and protocols.
>
> That is a feature, not a bug.

And following up on why that is often a feature is that it allows local editing of the input line by the terminal.

So if you type 'Z' instead of 'Y' or 'N', you may be able to fix it before it is sent to the program to be interpreted.

For that particular use-case, it isn't likely to be too useful, but if you were to instead type
(cra '(This is a long list))
it may be useful to change "cra" to "car" before hitting <enter>