From: "Drew Adams" <drew.adams@oracle.com>
Subject: RE: unhelpful menu keybinding notes
Date: Mon, 17 Apr 2006 09:57:05 -0700 [thread overview]
Message-ID: <DNEMKBNJBGPAOPIJOOICIEOFDEAA.drew.adams@oracle.com> (raw)
In-Reply-To: <jwvr73wmas7.fsf-monnier+emacs@gnu.org>
In some parts of Emacs we use another trick: make and use an alias,
like `advertised-undo'. I think this is a bad solution because
C-h f undo RET then lists all bindings except for the "advertised"
one C-x u.
I agree.
Maybe a better solution is to add an `advertised-binding' property
to the function's symbol:
(put 'undo 'advertised-binding [?\C-x ?u])
which could be used similarly to the :key-sequence property in menus
(i.e. it's used if the key seuqnece is indeed bound to the specified
command).
Some other ideas were kicked around previously. I don't recall them, but
it's worth discussing all of them sometime after the release. I like your
idea, but:
- What to do if the key sequence is not bound to the specified command and
there are several bindings? Which to pick?
- It might increase maintenance (but so might other solutions): Changing the
bindings in the library would also mean updating this property.
One question to consider is whether we want to allow control over what gets
communicated 1) at the point of use of `substitute-command-keys' or a doc
string or 2) at some earlier, more general point - or both.
For #2, a library might (somehow, perhaps using more or less the mechanism
you proposed) specify a list of bindings, in preference order, that would
apply to all uses of `substitute-command-keys' and all doc strings.
For #1, we might devise some way to indicate the preferred binding to use at
the point of call. For example (just thinking out loud; not a proposal),
"\\[((kbd "C-x") (kbd <f1> SPC) (kbd "C-M-<down>"))...]" might stipulate
using binding (kbd "C-x") if applicable, else (kbd <f1> SPC) if applicable,
else (kbd "C-M-<down>"). There might also be some way to specify a default
for the case where none were applicable.
Both general presciption (#2) and spec at point of use (#1) could of course
be used together, the latter (#1) taking precedence.
next prev parent reply other threads:[~2006-04-17 16:57 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-17 3:36 unhelpful menu keybinding notes Miles Bader
2006-04-17 7:10 ` Lennart Borgman
2006-04-17 7:28 ` Eli Zaretskii
2006-04-17 8:19 ` Lennart Borgman
2006-04-17 8:41 ` Eli Zaretskii
2006-04-17 8:46 ` David Kastrup
2006-04-17 15:50 ` Drew Adams
2006-04-17 16:29 ` Stefan Monnier
2006-04-17 16:57 ` Drew Adams [this message]
2006-04-18 1:42 ` Richard Stallman
2006-04-18 1:42 ` Richard Stallman
2006-04-17 19:11 ` Lennart Borgman
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=DNEMKBNJBGPAOPIJOOICIEOFDEAA.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).