From: "Drew Adams" <drew.adams@oracle.com>
Subject: RE: menu indications of key bindings for remapped commands
Date: Thu, 11 Jan 2007 18:06:58 -0800 [thread overview]
Message-ID: <BDEIJAFNGDOAGCJIPKPBGEPKCBAA.drew.adams@oracle.com> (raw)
In-Reply-To: <m37ivttfpr.fsf@kfs-l.imdomain.dk>
I think I've discovered what the problem is. IMO, there is a bug in the
definition of menu items.
As Kim pointed out, ido has no such problem. However, ido does not create a
menu item; it simply remaps a command that was already used in a menu item -
e.g., command `switch-to-buffer', used in "Buffers" menu item "Select Named
Buffer... (C-x b)". It is the binding of the command `switch-to-buffer' that
is reflected in that menu item. The menu item calls command
`ido-switch-buffer', but the binding displayed is that of
`switch-to-buffer', not that of `ido-switch-buffer'.
In my case, I create menu items, both in standard menus such as "File" and
in a new menu, "Icicles". But that's not the difference that matters. When I
create a menu item for buffer switching, I use a new command,
`icicle-buffer', which is the target of a command remapping. I have this:
(define-key icicle-mode-map [remap switch-to-buffer]
'icicle-buffer)
And it is the new command `icicle-buffer', not the remapped command
`switch-to-buffer', that I use to define the menu item:
(define-key icicle-menu-map [icicle-buffer]
'("+ Switch to Buffer..." . icicle-buffer)))
^^^^^^^^^^^^^
It is the immediate binding of the command `icicle-buffer', "(<remap>
<switch-to-buffer>)", that is reflected in the menu item. From a user point
of view, it is only the ultimate, user-friendly key binding that is of
interest, that is, the binding of the remapped command, `switch-to-buffer'.
It is that binding, "(C-x b)", that should be displayed in the menu item.
Showing "(<remap> <switch-to-buffer>)" to the user is a bug, IMO.
If I use the remapped command, `switch-to-buffer', in the menu-item
definition, then the correct key binding, "(C-x b)", does indeed show up in
the menu item:
(define-key icicle-menu-map [icicle-buffer]
'("+ Switch to Buffer..." . switch-to-buffer)))
^^^^^^^^^^^^^^^^
But it is handy and more readable to use the new command that is the remap
target, `icicle-buffer', not the remapped command, `switch-to-buffer', in
the menu-item definition. A library will typically want to express
everything in terms of its own command, and then have a single remapping
that references the remapped command. And it is possible that the remapped
command has no key binding at runtime - in that case, the menu item should
show no key binding; it should not show (<remap>...). The bottom line is
that the key-binding indication in a menu item should be as helpful as
possible to the user.
So, I see two use cases:
1. (ido use case) Remap a command that was already used to define a menu
item.
2. (icicles use case) Define a new menu item, using a command that is a
remap target. (The remapped command might or might not itself also be
already used to define a different menu item.)
The key binding shown in the menu item should in both cases be user-friendly
(C-x b), that is, regardless of which command is used in the menu-item
definition: remap source or remap target.
In the case of Icicles, the "Buffers" menu item "Select Named Buffer..."
does show the user-friendly binding "(C-x b)", because it is a pre-existing
menu item that was defined using command `switch-to-buffer'. The same key
binding should also be shown for a new menu item that is defined using the
remap target, `icicle-buffer'.
The user should see only the final key binding - what s?he types, which is
always the binding of the remap source (`switch-to-buffer', in this case).
The fix is to treat a remap target the same way: always get and use the
ultimate key binding in the menu item.
next prev parent reply other threads:[~2007-01-12 2:06 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <EIENLHALHGIMHGDOLMIMMEEFCOAA.drew.adams@oracle.com>
2007-01-11 18:15 ` menu indications of key bindings for remapped commands Drew Adams
2007-01-11 21:29 ` Kim F. Storm
2007-01-12 2:06 ` Drew Adams [this message]
2007-01-11 18:32 Drew Adams
2007-01-11 21:33 ` Kim F. Storm
-- strict thread matches above, loose matches on Subject: below --
2007-01-10 22:24 Drew Adams
2007-01-10 23:37 ` Stefan Monnier
2007-01-13 5:49 ` Drew Adams
2007-01-14 1:56 ` Richard Stallman
2007-01-22 19:44 ` Drew Adams
2007-05-20 23:54 ` Drew Adams
2007-05-24 21:22 ` Richard Stallman
2007-01-11 9:42 ` Kim F. Storm
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=BDEIJAFNGDOAGCJIPKPBGEPKCBAA.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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.