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

[Drew Adams]

    > My question is this: Why do these keys have as their binding
    > `self-insert-command'?

    Because that is the binding for all characters of that group.

That sounds like "because that's the way it is". Care to elaborate? The
question is not how it is done, but why it is done that way.

    > I hear you saying that they are not valid keys, and you can't
    > use them with `self-insert-command', and you can't use them
    > (their descriptions) with `read-kbd-macro' - so why bind them
    > to `self-insert-command'?

    Because doing so binds every character within that character group to
    self-insert-command without having to bind several thousand characters
    individually.

So what? Binding thousands of characters is something computers are good at.
Or are you saying that that would affect performance in an unacceptable way?

If so, what's special about `self-insert-command' - why not bind them all to
a different command, `foobar', which does what is needed, so they don't get
in the way of the normal, simple, straightforward relations between
`self-insert-command', `single-key-description', and `read-kbd-macro'?

    > and no one would have the problems of using keys with
    > `self-insert-command' and their descriptions with
    > `read-kbd-macro'

    What problems? These are not real keys, why would someone try to use
    them with read-kbd-macro?

What indicates that they are not "real keys"? You have to parse the
`single-key-description' and match against "Character set " to determine
that. Or you have to test the type of the event/key. Or some such.

A program or a user might well expect `single-key-description' to return a
unique, _single-key_ description for each key. A program might well expect
`self-insert-command' to do what it says straightforwardly: insert the key
as a character. A program might well try to use `read-kbd-macro' as an
inverse to `single-key-description'.

My program did, and this new feature has hardly been released yet (AFAIK,
it's new in Emacs 22). If I already stumbled on these anomalies (yes, they
are deviations from the standard behavior of these functions, AFAICT), then
it's possible others will also.