Does READ-CHAR echo?

[David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>]

    Date: Fri, 26 Jul 85 15:02 EDT
    From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>

    I could not find any place in CLtL where it says whether READ-CHAR echos
    the character that it has read. Likewise for PEEK-CHAR. Also, there is
    no discussion of whether UNREAD-CHAR should unecho the character.

The manual says on page 328 that READ-CHAR from the terminal echos.  I don't
know why this isn't repeated on page 379.  The manual should say that
UNREAD-CHAR doesn't unecho characters; it implies it by saying that UNREAD-CHAR
is only for parsers and can only back up one character.

    I note that Symbolics Common Lisp has (somewhat arbitrarily, I guess)
    decided that READ-CHAR echos, PEEK-CHAR does not echo, and UNREAD-CHAR
    does not un-echo the character. 

PEEK-CHAR echos characters it eats, but not the one it leaves in the stream's
input buffer.  Yes, the manual ought to say something about echoing in PEEK-CHAR.

				    This has the odd effect that:
 
     (PROGN (PEEK-CHAR) (UNREAD-CHAR (READ-CHAR)) (READ-CHAR))

    echos the character twice.

This is a bug in our operating system, not in Common Lisp.  The problem is
that if instead you had written

     (PROGN (PEEK-CHAR) (UNREAD-CHAR (READ-CHAR)) (PRINT 'FOO) (READ-CHAR))

then it really was supposed to echo it twice, once before the FOO and again
after it.  It's somewhat difficult to fix your example without breaking this
one.

    Does anyone have any thoughts about whether we should think about adding
    functions called PEEK-CHAR-NO-ECHO, READ-CHAR-NO-ECHO, and UNREAD-CHAR-NO-ECHO?
    Or maybe there should be WITH-INPUT-ECHO and WITHOUT-INPUT-ECHO special forms
    which affect calls to the character readers within the dynamic scope of their
    body.

I don't see anything about this in the manual, but I remember discussions of the
Common Lisp committee at which we decided that Common Lisp (first edition) wasn't
going to try to be a language you could write a display editor in.  The problem
is that this quickly gets you mired in a host of operating-system dependencies.
We decided it was better to have to go outside the portable language to do the
terminal input and output sections of your display editor; of course all the
difficult parts could be written in Common Lisp.

In addition to the ways of reading one character of input with echoing you
suggested (different function, dynamically-scoped state), one should also
mention using a different stream, adding a fifth optional argument to READ-CHAR,
and providing functions to turn an echoing "mode" on and off.  I can't guess which
implementors would have difficulty getting their operating system to conform to
which of these methods.

    Date: Fri, 26 Jul 85 17:21 EDT
    From: Robert W. Kerns <RWK@SCRC-YUKON.ARPA>

    I think the only one needed would be READ-CHAR-NO-ECHO.

I agree.

    [From: KMP]
    I kind of assume that we all agree that READ and READ-LINE should echo
    the characters as they come in from an interactive terminal. Perhaps,
    we should state that explicitly in the next edition of the manual.

Page 328.

    Date: Fri, 26 Jul 85 16:13:10 pdt
    From: mips!earl@Glacier (Earl Killian)

    Does READ-CHAR echo, or does the terminal handler, which supplied the
    character in the first place, echo?  Echoing is terminal-specific
    (you don't want READ-CHAR from a file to echo) so it makes more sense
    to talk about what the terminal handler does.  

See the carefully evasive language on page 328.

						   This starts to get
    into the controversy over whether you want to echo the character when
    it is typed ("interrupt level") or when it is read, or try to rise
    above these simple alternatives to do the right thing.

Here comes the morass of operating-system dependencies!  In some systems these
concepts aren't even meaningful.  In some others the implementor of Common Lisp
has no control over these affairs.