RE: single-key-description no good for Japanese and Chinese chars

[Drew Adams]

        That would be OK. A box is already displayed (for me) for
        lots of characters ("keys"). That happens, I assume,
        whenever my machine doesn't have the
        proper font to display the character.

    Many keys will fail to display on various terminals, and that can't be
    avoided.  However, when key-description returns something that won't
    display properly on certain terminals, it means that help displays
    such as that of C-h b are not meaningful either.  That is not good.

Maybe not. But I don't think that's much of a problem - or, rather, I don't
think there's much that can be done about it. If a user has the proper
fonts, then the characters are displayed; otherwise, they are not. There is
nothing different here from using a Web browser or other applications.
Novice users might wonder about the empty boxes displayed, but they will
wonder the same thing in other apps. You don't see Web browsers displaying
long-winded descriptions for each character that they can't display because
of missing font. That's the whole purpose of those empty boxes, after all -
let them do their job ;-).

    Perhaps single-key-description ought to describe every non-ASCII
    character using ASCII.  Or perhaps it should do this for characters
    that can't display on the current terminal.

I don't think that's a good solution - at least not for
`single-key-description'. It might be possible for help displays to detect
whether the user has the proper fonts, and, if not, do what you describe as
a work-around (or in addition to showing the box). But I don't think
`single-key-description' should itself do that at all.

1. Whatever `single-key-description' returns should be unique for each key.

2. I think `single-key-description' should just return a string with the
character, for keys bound to `self-insert-command' - always. If that
character is sometimes displayed as an empty box, so be it. The current
behavior is a real bug, IMO - those long-winded, non-unique descriptions are
worse than useless; they are a nuisance.

3. What `single-key-description' returns should play well with
`read-kbd-macro' - always.

    Anyway, that sort of change should wait for after the release.

Agreed (the help-display workaround you proposed).

Any chance of getting the basic bug fixed beforehand: getting unique
character descriptions for these characters? There are lots of them, in lots
of languages, so that might take a while. Currently, they really pollute the
key-description space.

        My concern here is the multi-byte chars (keys), for which
        `single-key-description' does not return a single-character
        string (which might or might not be displayed as a box,
        depending on your font support).

    How many bytes are used internally to represent the character
    should be irrelevant to this issue, and not visible either.
    Latin-1 characters take two bytes, for instance.  Why do you
    mention the byte-length in this context?

Sloppy and ignorant description on my part, sorry. I don't know how to
correctly characterize these "keys". Here is a list of the culprit key
descriptions I see. *Each* of these "single-key" descriptions is used for
multiple separate characters (i.e. a hundred or so chars each); I list each
description only once here:

Character set Big5 (Level-1) A141-C67F
Character set Big5 (Level-2) C940-FEFE
Character set CNS11643-1 (Chinese traditional): ISO-IR-171
Character set CNS11643-2 (Chinese traditional): ISO-IR-172
Character set CNS11643-3 (Chinese traditional): ISO-IR-183
Character set CNS11643-4 (Chinese traditional): ISO-IR-184
Character set CNS11643-5 (Chinese traditional): ISO-IR-185
Character set CNS11643-6 (Chinese traditional): ISO-IR-186
Character set CNS11643-7 (Chinese traditional): ISO-IR-187
Character set Ethiopic characters
Character set GB2312: ISO-IR-58
Character set Indian 2 Column
Character set Indian glyph
Character set JISX0208.1978 (Japanese): ISO-IR-42
Character set JISX0208.1983/1990 (Japanese): ISO-IR-87
Character set JISX0212 (Japanese): ISO-IR-159
Character set JISX0213-1
Character set JISX0213-2
Character set KSC5601 (Korean): ISO-IR-149
Character set Tibetan 1 column
Character set Tibetan 2 column
Character set Unicode subset (U+0100..U+24FF)
Character set Unicode subset (U+2500..U+33FF)
Character set Unicode subset (U+E000+FFFF)

The total number of such characters, for all of these descriptions combined,
is 2263. That's a lot of characters that don't yet have proper (i.e. unique)
single-key descriptions! Each such key (character) needs to be given a
unique description - preferably simply the character itself (as a 1-char
string), but in any case, something that `read-kbd-macro' can work with
properly.