read-char does not work at the repl

[stassats]

(read-char) immediately returns #\LINEFEED

[Shinmera]

Can confirm on b05884f.

> (read-char)

#\LINEFEED

[Shinmera]

Failure changed on 99669d674a6f2b7ce0a9127cf6537fc03066baa5

> (read-char)

#\NEWLINE

[drmeister]

Fixed this here 67edc9984b9f69a7c6f2faaded0d43f1b9693eda

[drmeister]

The previous fix was not sufficient - it caused other problems. Here is another attempt: d375df2b98219e16d4b72a2ef19308ef22413673

[drmeister]

Bleh - there are still problems here.

I try the following... I hit Ctrl-D once and the following happens.

COMMON-LISP-USER> (loop for x below 10 for in = (read-line standard-input nil :eof) do (format t "read |~s|~%" in)) Writing jitted symbols to /tmp/clasp-symbols-11298 read |""| read |:EOF| read |:EOF| read |:EOF| read |:EOF| read |:EOF| read |:EOF| read |:EOF| read |:EOF| read |:EOF| NIL COMMON-LISP-USER>

[kpoeck]

COMMON-LISP-USER>>>  (read-char)
#\Newline

[Bike]

The problem actually seems to be like... it's not eating whitespace?

What it's actually doing is grabbing the next character from the stream, apparently. For example, if you enter (read-char)f on the repl, you get #\f, as you might expect. But if it hits the end of the line it reads a newline instead of waiting. So (values (read-char) (read-char))f => #\f, #\Newline, and (values (read-char) (read-char)) will wait for you to input a character, and then return a newline and whatever you entered.

So I think the problem isn't actually the reader so much as the repl? Maybe?