> Does anyone know how to control which of several bindings for
> a command is displayed by `substitute-command-keys'?
There is the same problem for the key suggestion feature activated by
`suggest-key-bindings' displaying in the echo area only the "first"
key binding which is not always better than other key bindings.
A good solution is to suggest all key bindings in the echo area
just like `where-is' (`C-h w') does.
Perhaps it is not a good solution for `substitute-command-keys' to
replace key descriptions with all key bindings since the resulting
string might be too long. However, how about introducing a new
convention that all strings on which `substitute-command-keys' is used
should be designed to reserve enough space for the case when the
command is not on any keys, and so `M-x COMMAND' is printed. The size
of the command name plus 4 characters of the "M-x " string should
define the maximum length of allowed substitutions, and if the command
is bound to several key, then to print as many keys as many of them
fits into this limit. For example:
M-x scroll-left -> defines the maximum 15 characters
C-next, C-x < -> both keys fit into 15-characters limit,
so replace \[scroll-left] with both keys
I appreciate the response, and the workaround suggestion. However, this
convention will not work for many uses of `substitute-command-keys', because
the helpful prompt, message or help text 1) already has a premium on space
and, more importantly, 2) often mentions more than one key.
Here's an example of text I append to the minibuffer prompt during
completion:
(substitute-command-keys
" (\\<minibuffer-local-completion-map>\\[icicle-apropos-complete], \
\\[icicle-prefix-complete]: list, \\[icicle-completion-help]: help) ")
That produces this text: " (<S-tab>, TAB: list, C-h: help) "
If each of these commands had several bindings, the result would be not only
long but incomprensible. Even something like the "tab" key can involve
multiple bindings, to deal with different kinds of terminals.
_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
