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

[Drew Adams]

    > So what? Binding thousands of characters is something
    > computers are good at.

    Binding thousands of characters is a waste of memory and time.

Only if the result is not needed. Perhaps it's not. Anyway, you seem to
suggest that it's a performance issue - see next.

    > Or are you saying that that would affect performance in an
    > unacceptable way?

(The answer is apparently yes.)

    > If so, what's special about `self-insert-command' - why not
    > bind them all to a different command, `foobar', which does
    > what is needed

    Because self-insert-command does what is needed!

Not if it also does things that are inappropriate for these "invalid" keys.
`self-insert-command' is intended to, well, insert the key it is bound to.

And `self-insert-command' enjoys relations with other functions, including
`single-key-description' and `read-kbd-macro'. If using
`self-insert-command' in some context breaks those relations, and if
another, alternative command could be bound to these "invalid" keys to do
"what is needed", then why not do that and keep `self-insert-command' clean?

If I understand Handa's explanation correctly, you cannot just apply
`self-insert-command' to one of these "invalid" keys to insert a character.
But you can just apply it to normal/real/valid keys to insert a character.
That latter property of `self-insert-command' seems broken for the "invalid"
keys. Why not preserve it for all keys bound to `self-insert-command', by
binding the invalid keys to another command (even if it does the same
thing)?

    Why should we introduce a new binding to do the same thing so
    that you can remain blissfully
    ignorant of the purpose of generic characters?

Because code would be able to expect that anything bound to
`self-insert-command' was a normal key, which could be manipulated normally,
in particular by applying `self-insert-command' to insert it.

    >     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.

    You won't get an event/key to test the type of, because they are not
    real keys. There is no way to generate that events that match generic
    characters.

I'll take your word for it; I know nothing abou this. I thought Handa was
saying that an integer event indicated such an "invalid" key. If not, then I
guess one is reduced to parsing the `single-key-description' - that's what I
do currently.

In any case, that was precisely my point: You say "why would someone try to
use them"; they "are not real keys". But one (e.g. a program) doesn't know
that, without first testing them (e.g. parsing `single-key-description'
output).

If you are mapping a function over keymaps, and the function handles only
valid/real keys, then the function must first test for the possibility of an
invalid key (for each key) and, say, ignore it. There is no such problem if
no invalid keys are bound to `self-insert-command' - just look at all the
keys that are bount to that command, and you are good to go: no special
real/fake key test needed. The other, invalid keys would be bound to
`self-insert-invalid-key' or whatever.

I don't claim to understand this stuff well, and I don't know if I'm
expressing things using the right terminology. It's probable I'm missing
something or misunderstanding stuff. What I think I understand, though, is
that you can't treat these "invalid" keys the same way you treat the normal
ones (e.g. insert them with `self-insert-command'), and if you have a
function that tries to do that, it must first filter out the invalid ones.

I brought this up not because I like to cause trouble, but because I ran
into problems when I tried to treat these special keys the same as the
others, blindly mapping over keymaps and calling the commands bound to the
keys. That works everywhere (AFAICT), except for these "invalid" keys.