> 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. _______________________________________________ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug