long-char, kanji

["Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>]

Sorry, that last message got away.  Someday someone will write a decent
mail program that is tolerant of sloppy typists...

    I haven't used fonts, but only because I wasn't on a machine that could do
    them.  I've since moved to an Explorer, and I'm sure that now that I have
    them, I'll use them.  Also, now that I *have* a computer with Control,
    Meta, Super and Hyper keys, I'd be very upset if I couldn't input any
    combination I can type as a character.

    My vote is for leaving at least bits (and probably font) in the language.
    As long as string-char is there when you need efficiency, I don't see
    what's wrong with having full chars as well.

It is clear that each implementation will want to provide Lisp
programs with access to any keyboard event the user is capable of
generating (and that the operating system doesn't censor).  The point is
not that we want to take these away from you, but that such "input
events" are deeply unportable and that they don't have much in common
with the kinds of characters you want to use internally, pack into
strings, etc.  Not only are there various bit fields to worry about, but
in an input event you might want to distinguish between "3" from the
nornal keyboard and "3" from the numeric pad, you might want a timestamp
as part of this input, and so on.

The suggestion is that hanging a "bits" field off each character is a
half-baked solution that doesn't solve the full problem for input
events, and that therefore doesn't get used in the ways we originally
anticipated.  What it does do is to needlessly complicate the
representation of internal characters.  The argument about "fonts" is
parallel, but this time the issue is what you send to the display to get
various effects.  A font field doesn't really do the job, and it
generally makes no sense to store this in strings.  I'm still pondering
whether I believe that the "style" is a legitimate part of an internal
text string or is something you do on output.

Anyway, the question was not whether you ever want to use the notion of
"fonts" and "bits" in some generic sense; the question was whether you
currently use the Char-Font and Char-Bits facility as currently defined
in the language.  If people haven't made a lot of use of these in their
current form, we are free to think about whether there is some better
way of providing the comparable functionality, and how much of the
better way ought to be in the standard part of the language.  If people
have made a lot of use of this facility, we're probably stuck with the
status quo, though all the implementors can conspire to make these
fields of zero length.

-- Scott