Subject: Re: read-char vs. read-char-no-hang
From: rpw3@rpw3.org (Rob Warnock)
Date: Thu, 09 Apr 2009 02:44:35 -0500
Newsgroups: comp.lang.lisp
Message-ID: <pZ6dnfA-hdz-OkDUnZ2dnUVZ_g-dnZ2d@speakeasy.net>
chthon  <jurgen.defurne@pandora.be> wrote:
+---------------
| rpw3@rpw3.org (Rob Warnock) wrote:
| > buts easily enough, though. I don't know what facilities CLISP
| > provides, but here's what I use in CMUCL when running on FreeBSD:
| > ...[code]...
| 
| Thanks for the info on SBCL.
+---------------

Note: The code I gave was for CMUCL, not SBCL. Despite the fact that
SBCL originally forked from CMUCL, the code I gave is unlikely to work
out of the box on SBCL [if nothing else, package names may have changed].

+---------------
| After looking somewhat more around yesterday evening, I supposed that
| it would have to end up somehow like your code. The biggest problem
| was finding out why. Looking through some examples, I then found out
| that cbreak is an ioctl setting, not a setting that you can print to
| the terminal to change its characteristics (like an VT100 or ANSI
| escape code).
+---------------

That's because it's not the terminal that decides when to "push"
data up to the user process, but the operating system.

+---------------
| But CLISP itself sets one on the wrong track. If you run CLISP from
| the command-line and try (read-char) and (read-char-no-hang) they will
| return immediately, because CLISP uses the GNU readline library.
+---------------

The version of CLISP I have does *not* return immediately from READ-CHAR,
but waits for the next #\Newline to be typed, then returns the first
character on that line. And in any case, the GNU readline library
doesn't necessarily fix the operating system issue [it might in fact
make it *worse*!].


-Rob

-----
Rob Warnock			<rpw3@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607