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

[Kenichi Handa]

In article <address@hidden>, "Drew Adams" <address@hidden> writes:

> Question: are 20864 and 20992 the _same_ group of characters (same generic
> character)?

No.  split-char tells you the difference.

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

As those are not valid character events, they should not be
given to read-kbd-macro.

> Still, each such _group_ of characters (each generic char)
> should have its own unique name, it seems to me.

I agree that unique name is more informative, but I don't
understand how does it work in an actual code.

> 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 don't understand this part.  How did you see such a
number?  Contents of a keymap is usually a char-table, and
for efficiency, if all characters in a group are mapped to
the same thing, there's only a single table entry for them.

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

Each valid key should be identified uniquely by name.  But,
as genenric characters are not a valid key, how it is useful
being unique by name.

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

As I wrote before, it doesn't work, it signals an error.

I agree that it is confusing that (lookup-key global-map
[20864]) returns self-insert-command.  It may be better that
it returns nil or signal an error.

>     How did you get the key 20864?

> By running through the debugger as it executed `map-keymap'.

Ah, I see.  The docstring of map-keymap should be improved,
perhaps something like this.

Call function once for each event binding in keymap.
function is called with two arguments: the event that is bound, and
the definition it is bound to.  If the event is an integer,
it may be a generic character, and that means that all
actual character events belonging to that generic character
are bound to the definition.

The reason why map-keymap doesn't call function for all
actual characters is that such a code is tooooo inefficient
(the function will be called more than 100000 times then).

By the way, I've just fixed bindings.el to make the
char-table in keymap more tight.

---
Kenichi Handa
address@hidden