In article <[EMAIL PROTECTED]>, "Drew Adams" <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] _______________________________________________ emacs-pretest-bug mailing list [email protected] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
