unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
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.

  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

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