Also, shouldn't the form of the string output by `single-key-description' be a possible input to `read-kbd-macro', in order to get back the key sequence? That is, isn't there a conventional key description format that should be followed?
For example, the Elisp manual says this about `read-kbd-macro': "it can also be used as a rough inverse for `key-description'. You call it with a string containing key descriptions, separated by spaces; it returns a string or vector containing the corresponding events. (This may or may not be a single valid key sequence, depending on what events you use; *note Keymap Terminology::.)" BTW - I followed the cross reference, but I'm not sure that it explains what is said in parentheses. I don't really see an explanation that lets you know under what circumstances `read-kbd-macro' returns a valid key sequence. Perhaps I'm not looking in the right place, but I would like to find an inverse for `key-description' that works in all cases, and I'd like to understand the cases where `read-kbd-macro' does not do that. -----Original Message----- From: Drew Adams [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 20, 2006 11:18 AM To: Emacs-Pretest-Bug Subject: single-key-description no good for Japanese and Chinese chars `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". 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". 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" And this: "Character set Big5 (Level-1) A141-C67F = self-insert-command" However, *all* characters in each of those Japanese and Chinese character sets have the exact same key description, so there is no way to understand which character corresponds to which description (i.e. completion candidate) - they are all the same. In sum, the `single-key-description' is not a key description at all in these cases; it is a character-set description. Each key description should be unique. Imagine if all ASCII characters had the same key description: "ASCII character set" - you can see that it would be useless. In GNU Emacs 22.0.50.1 (i386-msvc-nt5.1.2600) of 2006-07-19 on BOS-CTHEWLAP2 X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-msvc (12.00)' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: ENU locale-coding-system: cp1252 default-enable-multibyte-characters: t Major mode: Dired by name Minor modes in effect: encoded-kbd-mode: t tooltip-mode: t tool-bar-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t Recent input: <help-echo> <help-echo> <help-echo> <help-echo> <menu-bar> <help-menu> <report-emacs-bug> Recent messages: (C:\Emacs-22-2006-07-19-Fran\bin\emacs.exe -q --no-site-file --debug-init C:\drews-lisp-20) Loading encoded-kb...done For information about the GNU Project and its goals, type C-h C-p. Loading dired... Loading regexp-opt...done Loading dired...done Loading emacsbug...done _______________________________________________ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug