emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: menu indications of key bindings for remapped commands


From: Drew Adams
Subject: RE: menu indications of key bindings for remapped commands
Date: Thu, 11 Jan 2007 18:06:58 -0800

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 via email to

[Prev in Thread] Current Thread [Next in Thread]