I ran across this issue/question. I don't know know if it is a bug or not. If not, perhaps someone has a suggestion of how to deal with it.
I have strings that name keys in keymaps (from map-keymap). Some are prefix keys. Examples: "C-x", "modeline", "f1". I use `read-kbd-macro' with the string name as first arg and t as the second, NEED-VECTOR arg. Example: "C-x" gives [24]. If the binding of the key is a keymap, so the key is a prefix key, then I concatenate the current prefix-key name (e.g. [] for global) with the key name: (vconcat prefix key). Example, when using map-keymap over the global-map, the prefix is [] and, for key [24] this gives [24]. This works fine for prefix keys that are not names, but it does not work for named prefix keys, such as `mode-line' and `f1'. The reason is that (read-kbd-macro "mode-line" t) does not return [mode-line]; it returns the equivalent of "mode-line", that is, a vector of characters: [109 111 100 101 45 108 105 110 101]. When I try to look up accessible-keymaps of that prefix, I obviously get none. That is, whereas (accessible-keymaps (current-global-map) [mode-line]) would work, the call generated is instead (accessible-keymaps (current-global-map) "mode-line"), or, more exactly, (accessible-keymaps (current-global-map) [109 111 100 101 45 108 105 110 101]), which fails. The first question is whether this is a bug: should (read-kbd-macro "mode-line" t) return [mode-line]? If not, I guess I'll need some other way to convert names to vector keys for the prefix keys. Suggestions? If I knew that a given prefix-key name was a "named" prefix key (as opposed to a control key name, for instance), then instead of using `read-kbd-macro' I would use just (vector (intern key)). That is, I'd use `read-kbd-macro' for "C-x" but (vector (intern "mode-line")). Anyone know how to make such a distinction? To complicate things, I see that (read-kbd-macro "<mode-line>"), with or without the second arg, returns [mode-line]. However, I use key names without angle brackets (because they are much more readable), and, again, I don't know how to distinguish the named keys, to add back the angle brackets internally, just for `read-kbd-macro'. I thought also of trying to use `kbd' on the key name, hoping that might help, but (kbd "mode-line") also gives "mode-line". I wonder too if that might be a bug. Yes, if I use angle-bracketed key names (strings), then the problem does not arise, but I really don't want to do that, as it is a zillion times less readable. Here is a sample of the *Completions* buffer in each style, to show what I mean: Without angle brackets: C-M-S-backspace = copy-to-register C-M-S-delete = append-to-register C-M-S-f1 = rename-buffer C-M-S-insert = insert-file C-M-backspace = backward-kill-sexp C-M-delete = kill-sexp C-M-down = enlarge-frame C-M-down-mouse-1 = mouse-drag-secondary C-M-drag-mouse-1 = mouse-set-secondary C-M-end = end-of-defun C-M-f1 = font-lock-fontify-buffer C-M-home = beginning-of-defun C-M-insert = lisp-complete-symbol C-M-left = shrink-frame-horizontally With angle brackets: <C-M-S-backspace> = copy-to-register <C-M-S-delete> = append-to-register <C-M-S-f1> = rename-buffer <C-M-S-insert> = insert-file <C-M-backspace> = backward-kill-sexp <C-M-delete> = kill-sexp <C-M-down-mouse-1> = mouse-drag-secondary <C-M-down> = enlarge-frame <C-M-drag-mouse-1> = mouse-set-secondary <C-M-end> = end-of-defun <C-M-f1> = font-lock-fontify-buffer <C-M-home> = beginning-of-defun <C-M-insert> = lisp-complete-symbol <C-M-left> = shrink-frame-horizontally The effect is even worse when other keys that don't have angle brackets are in the list. For example, C-d has no angle brackets, but <C-left> does. Users don't think of these as being very different, but a simple sort of *Completions* puts them very far apart. You can see from the snippets above that the order is changed even among the same set of keys that take angle brackets, because ">" is sorted after "-": `C-M-down' appears after `C-M-down-mouse-1' when angle brackets are present. Thx for any suggestions. [BTW, the doc string of `read-kbd-macro' is a bit confusing, but the manual is clear. The doc string names the args START &optional END, but it then speaks of the possibility of a "single string argument" and a "second argument NEED-VECTOR" for Lisp calls. This is correct, but it could perhaps be worded better.] _______________________________________________ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug