[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
char-equal of control characters
- To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
- Subject: char-equal of control characters
- From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
- Date: Thu, 27 Jun 1985 00:59:00 -0000
- Cc: Common-Lisp@SU-AI.ARPA
- In-reply-to: Msg of 26 Jun 1985 12:39-EDT from David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>
- Sender: FAHLMAN@CMU-CS-C.ARPA
Now that you mention it, this business about CHAR-EQUAL ignoring
differences in the bits attributes looks like a pure mistake to me. I
don't remember any discussion of this -- it probably just sounded
halfway plausible and slipped by us all at the time. (Then again, I
might be misremembering. I've got no easy way to search the archives.)
If we think of the bits attribute as encoding things like control and
meta -- funny shift modifiers that really only make sense in keystrokes
coming in -- I can't think of very many situations in which we would
want to consider #\control-A as being in an equivalence class with #\A.
It certainly is not a situation that parallels the close relationship
between #\A and #\a.
Unless someone thinks of a good reason why CHAR-EQUAL ought to be the
way the manual says it is, maybe we should consider changing CHAR-EQUAL
to take differing bits into account.
The next time we design a new Lisp, we should separate the concept of
characters (which might or might not want to have fonts attached) and
input-keystrokes, which would be some implementation-dependent
representation of anything that might come in from keyboard land,
including combinations of shift bits. It was a mistake to muddle these
two ideas together, but it is too late to change that now.