[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Does READ-CHAR echo?
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
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
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 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.
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.