From: ···········@gmail.com
Subject: A problem with read-char
Date: 
Message-ID: <9a6e6801-c76f-4635-99c0-07ff5be46824@56g2000hsm.googlegroups.com>
Hi.

Is it possible to make read-char behave like getch in ó when working
with interactive stream (*standard-input*)?
In SBCL read-char wants "enter" key to unhang from REPL, in C getchar
returns immediately after user press key on keyboard.
Probably is possible to run code that uses read-char with direct
console access, aside REPL?

Thanks.

From: Tim Bradshaw
Subject: Re: A problem with read-char
Date: 
Message-ID: <62e09a81-48c4-4c3f-ab55-d8d0b5d3e488@y38g2000hsy.googlegroups.com>
On Jun 6, 4:54 pm, ···········@gmail.com wrote:

> in C getchar
> returns immediately after user press key on keyboard.

Depends on the terminal modes but generally no, it won't.
From: Pascal Bourguignon
Subject: Re: A problem with read-char
Date: 
Message-ID: <87od6ezaga.fsf@hubble.informatimago.com>
···········@gmail.com writes:

> Hi.
>
> Is it possible to make read-char behave like getch in С when working
> with interactive stream (*standard-input*)?
> In SBCL read-char wants "enter" key to unhang from REPL, in C getchar
> returns immediately after user press key on keyboard.
> Probably is possible to run code that uses read-char with direct
> console access, aside REPL?

No.  It is not possible.   

That is, it's not possible with COMMON-LISP:READ-CHAR and neither with
COMMON-LISP:READ-CHAR-NO-HANG.

By the way, you are totally wrong about the standard C library getchar
functions.  It behaves exactly like COMMON-LISP:READ-CHAR.

About the curses routine getch, the situation is different.


And what is this difference would you guess?  Here lies the answer to
your question.

The difference is that curses puts the terminal in raw mode to be able
to receive the characters from the keyboard one at a time, instead of
leaving the terminal in cooked mode, where the unix driver bufferize
lines and handles backspace, amongst other niceties.

Now, I don't know about SBCL, (check the manual of SBCL).  I only have
the Implementation Notes of CLISP loaded in my wetware.  In CLISP you
can use the EXT:WITH-KEYBOARD macro (while the basic output features
of curses are provided by the SCREEN package).

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

PLEASE NOTE: Some quantum physics theories suggest that when the
consumer is not directly observing this product, it may cease to
exist or will exist only in a vague and undetermined state.
From: Rob Warnock
Subject: Re: A problem with read-char
Date: 
Message-ID: <WdCdnaGs2JnN4NfVnZ2dnUVZ_vOdnZ2d@speakeasy.net>
Pascal Bourguignon  <···@informatimago.com> wrote:
+---------------
| ···········@gmail.com writes:
| > Is it possible to make read-char behave like getch in С when working
| > with interactive stream (*standard-input*)?
...
| No.  It is not possible.   
| 
| That is, it's not possible with COMMON-LISP:READ-CHAR and neither with
| COMMON-LISP:READ-CHAR-NO-HANG.
...
| The difference is that curses puts the terminal in raw mode to be able
| to receive the characters from the keyboard one at a time, instead of
| leaving the terminal in cooked mode, where the unix driver bufferize
| lines and handles backspace, amongst other niceties.
| 
| Now, I don't know about SBCL, (check the manual of SBCL).  I only have
| the Implementation Notes of CLISP loaded in my wetware.  In CLISP you
| can use the EXT:WITH-KEYBOARD macro (while the basic output features
| of curses are provided by the SCREEN package).
+---------------

If it helps, "meta.person", I once wrote the following for CMUCL
for an application that wanted to be able to type a single character
response to a prompt without messing up the terminal screen:

    (use-package :alien)
    (use-package :unix)
    ...
    (defun read-char-no-echo-cbreak (&optional (stream *query-io*))
      (with-alien ((old (struct termios))
		   (new (struct termios)))
	(let ((e0 (unix-tcgetattr 0 old))
	      (e1 (unix-tcgetattr 0 new))
	      (bits (logior tty-icanon tty-echo tty-echoe
			    tty-echok tty-echonl)))
	  (declare (ignorable e0 e1)) ;[probably should test for error here]
	  (unwind-protect
	      (progn
		(setf (slot new 'c-lflag) (logandc2 (slot old 'c-lflag) bits))
		(setf (deref (slot new 'c-cc) vmin) 1)
		(setf (deref (slot new 'c-cc) vtime) 0)
		(unix-tcsetattr 0 tcsadrain new)
		(read-char stream))
	    (unix-tcsetattr 0 tcsadrain old)))))

SBCL has probably diverged considerably from CMUCL in this area,
but something similar should be doable with SBCL. Start by looking
in the SB-UNIX or maybe the SB-POSIX packages...


-Rob

-----
Rob Warnock			<····@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607
From: ········@gmail.com
Subject: Re: A problem with read-char
Date: 
Message-ID: <4f3dfc70-2031-4071-8edc-5d9a4144d6a0@w7g2000hsa.googlegroups.com>
On Jun 6, 6:54 pm, ···········@gmail.com wrote:
> Hi.
>
> Is it possible to make read-char behave like getch in ó when working
> with interactive stream (*standard-input*)?
> In SBCL read-char wants "enter" key to unhang from REPL, in C getchar
> returns immediately after user press key on keyboard.
> Probably is possible to run code that uses read-char with direct
> console access, aside REPL?
C's getchar() reads and returns one byte from the stdin file stream.
stdin needs not to be your terminals input; Sometimes a terminal just
isn't there.
(same applies for *standard-input*)
In C & Common Lisp any read from a file stream may block;
If the ISO group on C (or the ANSI on common lisp) had standarized a
function similar to curses getch(), the portability of these languages
would get more limitted.
Thus, such function does not exist in either language.
Since you want to do something that might not be portable to a
microcontroller (but the benifit is the much more enhanced UI), use a
non-standard library, such as CL-ncurses.
<http://common-lisp.net/project/cl-ncurses/>