Assuming this reader macro in clisp\slime:
(SET-DISPATCH-MACRO-CHARACTER (CHARACTER "#") (CHARACTER "!") (LAMBDA (STREAM CHAR ARG) (DECLARE (IGNORE CHAR ARG)) ;; read characters up to the first occurence of "!#", ;; and return the string read. (loop for curr = (read-char stream nil nil t) while (and curr (or (char/= (character "!") curr) (char/= (character "#") (peek-char nil stream nil nil t)))) collect curr into str finally (read-char stream nil nil t) (return (coerce str 'string)))))
Typing:
#! hello RET
returns:
" hello "
instead of waiting for further input.
With clisp\xterm this works as expected:
#! hello RET
waits for further input:
the last line !# RET
returns:
" hello the last line "
"Pascal J.Bourguignon" pjb@informatimago.com writes:
Typing:
#! hello RET
returns:
" hello "instead of waiting for further input.
With clisp\xterm this works as expected:
Yes, that's true. The reason is that RET sends a command like `evaluate the string after the prompt' to Lisp. The string is converted to stream and the string-stream ends after the newline.
You could explicitly read from standard-input if you call (read). Or you could press C-j instead of RET to insert a newline.
Usually SLIME doesn't wait for input from standard-input but for input from the socket to Emacs. Input is read from standard-input only if do so yourself. The REPL buffer will then show a [read] indicator. One side effect of this is that the repl appears to be work even if the debugger is active. The other nice thing is that the *inferior-lisp* isn't blocked when the fd-handler communication style is used.
So, all this will probably not be changed until somebody finds an elegant way to keep the REPL and the debugger active at the same time.
Helmut.
-
Helmut Eller -
Pascal J.Bourguignon