unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
Subject: RE: Qs on key-description, substitute-command-keys
Date: Sat, 15 Oct 2005 07:25:33 -0700	[thread overview]
Message-ID: <DNEMKBNJBGPAOPIJOOICAEGMCNAA.drew.adams@oracle.com> (raw)
In-Reply-To: <878xwvvx36.fsf@jurta.org>

    > 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.

  reply	other threads:[~2005-10-15 14:25 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-04 23:55 Qs on key-description, substitute-command-keys Drew Adams
2005-10-05 16:23 ` Kevin Rodgers
2005-10-05 16:39   ` Drew Adams
2005-10-14 22:53 ` Drew Adams
2005-10-15 11:27   ` Juri Linkov
2005-10-15 14:25     ` Drew Adams [this message]
2005-10-16 14:40     ` Richard M. Stallman
2005-10-15 11:54   ` Stefan Monnier
2005-10-15 14:35     ` Drew Adams
2005-10-16 13:07       ` Stefan Monnier
2005-10-16 14:40       ` Richard M. Stallman
2005-10-15 18:00     ` John S. Yates, Jr.
2005-10-16 13:12       ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DNEMKBNJBGPAOPIJOOICAEGMCNAA.drew.adams@oracle.com \
    --to=drew.adams@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).