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

[Drew Adams]

    >     I don't think it is unreasonable for
    >     single-key-description to use the
    >     same description for these many thousands of characters
    >     especially if
    >     they are not produced directly by any keyboard in common use.

    > If those values are meaningless junk, then it is not crucial
    > what happens
    > for those argument values.  But if they are meaningful, then
    > they should be handled right.

    > Handa, can you tell us whether these values are meaningful?
    > Please ask Drew for more info if you need it.

    It seems that Drew misunderstand generic characters.

I don't misunderstand them. I'm ignorant of them altogether ;-). Never heard
of them before.

    > `single-key-description' returns the exact same key description for
    > each key in the asian character sets (Japanese, Chinese, etc.).

    > For example, for the different input events (keys) 20864 and 20992,
    > the exact same description is given: "Character set JISX0208.1978
    > (Japanese): ISO-IR-42".

    Both 20864 and 20992 are generic characters, i.e. not an
    acutual character but a code representing a group of
    characters (a charset or a row of characters).  For
    instance, (insert 20864) signals an invalid-character error.

OK, I just read up on this a bit in the manual, so I'm beginning to
understand a little...

Question: are 20864 and 20992 the _same_ group of characters (same generic
character)? I'm guessing not. They both have the same "single-key"
description, which seems wrong to me.

Anyway, IIUC (now), there are no single keys that correspond to single
characters in this case. We have only one key that corresponds to a group of
multiple characters.

If a "key" here does correspond to multiple characters, then I understand
that its description won't represent a single character (though I'm not sure
what that does for `read-kbd-macro' - does it necessarily break that
functionality?). Still, each such _group_ of characters (each generic char)
should have its own unique name, it seems to me.

When I was debugging this a bit, I think I saw a unique event number for
each key in the keymap (I assumed naively that separate such events/keys
represented separate, individual characters). I cited two such evnet
numbers: 20864 and 20992. I don't think I ever saw the same number used more
than once. That, to me, shows a unique identifier for each such key in the
keymap - whether that key represents a single character or a group of
characters (a generic char). So that makes me think that each such key could
have a unique name, couldn't it?

IOW, the items in the keymap are "keys", and it is they that need unique
identifiers. Are you also saying that it is impossible for each such key to
have a unique identifier? Regardless of the mapping between keys and
characters (or groups of chars), shouldn't we be able to identify (describe)
each key uniquely?

If we did that, and if some such keys corresponded to groups of characters,
then perhaps the `read-kbd-macro' inverse functionality would be broken for
such keys. That would be regrettable, but if there is no alternative, so be
it.

However, wouldn't the binding of such keys to `self-insert-command' also
produce broken behavior? That is, if such a key corresponds to a group of
characters, and it is bound to `self-insert-command', how does that work?
How does `self-insert-command' know which character of the group to insert?
I didn't see anything in the manual about this relation.

You are right that I'm ignorant of all this stuff. I'm just trying to
understand the use of `single-key-description', `read-kbd-macro', and
`self-insert-command' for these special "keys".

    > This is useless. The single-key description must be unique for a given
    > key. If nothing else, the event value should be included in the
    > description: e.g. "Character set JISX0208.1978 (Japanese): ISO-IR-42 -
    > 20864".

    As (split-char 20864) => (japanese-jisx0208-1978 35 0),
    the description can be changed to "Characters in row 35 of
    character set JISX0208.1978 (Japanese): ISO-IR-42 - 20864"
    if that is more useful.

At least it is a unique description of the "key", IIUC, so that would be
better, IMO. It could probably be shorter - something like
japanese-jisx0208-1978-20864, perhaps, or just jp-jisx0208-1978-20864.

Anyway, I'll bow out of the fix/design part of this now, as I know nothing
about it. I would like, as much as possible, for the usual relations between
`single-key-description', `read-kbd-macro', and `self-insert-command' to
also hold for these special "keys". Please do the best you can in that
regard, so the behavior is as sensible as possible.

    > I have code, for instance, that lets you complete key sequences.  The
    > completion candidates are the `single-key-descriptions' of the key
    > sequences typed so far.  At top level, they are the descriptions of
    > all top-level bindings and commands.  For example, this is a possible
    > completion:

    >  "a = self-insert-command"

    > And so is this:

    >  "Character set JISX0208.1978 (Japanese): ISO-IR-42" =
    self-insert-command"

    How did you get the key 20864?

By running through the debugger as it executed `map-keymap'. I just map over
keymaps, picking up the keys and their bindings. For the keys, I apply
`single-key-description'. Later, I also need to be able to apply
`read-kbd-macro' to the result of `single-key-description' to get back the
key.

Thx.