looking up a submenu keymap in a menu keymap, when the submenu key is a string

looking up a submenu keymap in a menu keymap, when the submenu key is a string

[Drew Adams]

I can't seem to find the answer to this in the Elisp doc. Perhaps it's
there, but I've spent a lot of time looking and haven't discovered it. It's
possible I read the answer without recognizing it. I've also looked closely
at several Emacs-Lisp source files, to try to understand better and perhaps
find a model for what I'm trying to do. No luck so far.

How can I look up a menu item that is a submenu in a keymap, and whose key
(or item-string) is a string, not a symbol? That is, how can I pass the
submenu menu-item string to some function and have it return the keymap for
that submenu?

For example, in this Imenu keymap, which is the result of (lookup-key
(current-local-map) [menu-bar index]), how can I look up the "Variables"
keymap:

(keymap "foo.el"
        ("Variables" "Variables" keymap "Variables"
         ("toto" "toto" lambda nil
          (interactive)
          (imenu--menubar-select
           '("toto" . #<marker at 37004 in foo.el>)))))

IOW, what would I use to obtain from the Imenu keymap the following submenu
map, given the menu-item string for the submenu, "Variables"?

(keymap "Variables"
        ("toto" "toto" lambda nil
         (interactive)
         (imenu--menubar-select
          '("toto" . #<marker at 37004 in foo.el>))))

`lookup-key' doesn't seem to help here - at least I cannot just pass
"Variables" as the key arg to it. And passing the symbol `Variables' to it
obviously doesn't work either, since the key in the map itself is a string.

If Variables in the keymap were a key (event) instead of a string, I could
do (lookup-key (current-local-map) [menu-bar index Variables]) or
(lookup-key (lookup-key (current-local-map) [menu-bar index]) 'Variables).
IOW, if the submenu item were like this, there would be no problem:

(Variables "Variables" keymap "Variables"
 ("toto" "toto" lambda nil
  (interactive)
  (imenu--menubar-select
   '("toto" . #<marker at 37004 in foo.el>))))

But, how do I deal with a string "Variables" as the key (which is the
item-string) here? In other menus, I usually see a symbol as the key for a
submenu, but for Imenu it is always a string.

Please let me know what I'm missing - thanks!

Re: looking up a submenu keymap in a menu keymap, when the submenu key is a string

[Stefan Monnier]

> (keymap "Variables"
>         ("toto" "toto" lambda nil
>          (interactive)
>          (imenu--menubar-select
>           '("toto" . #<marker at 37004 in foo.el>))))

> `lookup-key' doesn't seem to help here - at least I cannot just pass
> "Variables" as the key arg to it.

You can try to pass ["Variables"].  But it's really not that simple, since
you have to distinguish between the menu name and the "pseudo-key"
associated with it.  In your examples, both are strings and they are equal,
but that's not necessarily the case.
You may want o check the easy-menu functions for that, tho they're not
always as "easy" to use as the name implies.


        Stefan

RE: looking up a submenu keymap in a menu keymap, when the submenu key is a string

[Drew Adams]

    > (keymap "Variables"
    >         ("toto" "toto" lambda nil
    >          (interactive)
    >          (imenu--menubar-select
    >           '("toto" . #<marker at 37004 in foo.el>))))

    > `lookup-key' doesn't seem to help here - at least I cannot just pass
    > "Variables" as the key arg to it.

    You can try to pass ["Variables"].  But it's really not that
    simple, since
    you have to distinguish between the menu name and the "pseudo-key"
    associated with it.  In your examples, both are strings and
    they are equal,
    but that's not necessarily the case.
    You may want o check the easy-menu functions for that, tho they're not
    always as "easy" to use as the name implies.

Right. Thanks for your reply. I did try ["Variables"] (and [menu-bar index
"Variables"]), and I did study the easy-menu stuff. The easy-menu stuff
almost seemed as if it was going to get me what I needed, but I wasn't able
to make it work. Other suggestions are welcome, from anyone.

If there is no easy (or even feasible) way to do this, I wonder if it isn't
a mistake to "allow", or at least encourage, this kind of keymap entry -
Imenu is a standard library. If Imenu used the normal convention, there
would be no problem, and I don't think there would be a problem for Imenu
either. Is this more or less a bug, in that users cannot (at least not
easily, or any way I've found) look up such a key in the keymap (that is,
retrieve the submenu keymap)?

Anyway, I'm more immediately interested in finding a solution for the
current state, than in reporting a problem here. Help appreciated. Thanks to
Stefan, I feel a little confirmed in not having found a solution.

Re: looking up a submenu keymap in a menu keymap, when the submenu key is a string

[Stefan Monnier]

>     You can try to pass ["Variables"].  But it's really not that
>     simple, since
>     you have to distinguish between the menu name and the "pseudo-key"
>     associated with it.  In your examples, both are strings and
>     they are equal,
>     but that's not necessarily the case.
>     You may want o check the easy-menu functions for that, tho they're not
>     always as "easy" to use as the name implies.

> Right. Thanks for your reply. I did try ["Variables"] (and [menu-bar index
> "Variables"]),

This can work, but the test is `eq' rather than `equal' so you have to pass
not just some random "Variables" string, but the very one used in the keymap.

> and I did study the easy-menu stuff.  The easy-menu stuff almost seemed as
> if it was going to get me what I needed, but I wasn't able to make it
> work.  Other suggestions are welcome, from anyone.

I think easy-menu is the way to go.  Tell us what you tried.
Of course, it may also be important to know the context in which you're
doing that: maybe there's a simpler way.

> If there is no easy (or even feasible) way to do this, I wonder if it isn't
> a mistake to "allow", or at least encourage, this kind of keymap entry -
> Imenu is a standard library.

It's definitely not encouraged, but it should mostly be irrelevant, because
it's an internal issue.  Normally, either you have the key already (from
read-key-sequence, for example), or you have the menu entry name (in which
case you have to use code such as the one used in easy-menu to scan the
keymap and recover the corresponding key).


        Stefan

RE: looking up a submenu keymap in a menu keymap, when the submenu key is a string

[Drew Adams]

    >     You can try to pass ["Variables"].  But it's really not that
    >     simple, since you have to distinguish between the menu name
    >     and the "pseudo-key" associated with it.  In your examples,
    >     both are strings and they are equal,
    >     but that's not necessarily the case.
    >     You may want o check the easy-menu functions for that,
    >     tho they're not always as "easy" to use as the name implies.

    > Right. Thanks for your reply. I did try ["Variables"] (and
    > [menu-bar index "Variables"]),

    This can work, but the test is `eq' rather than `equal' so you
    have to pass not just some random "Variables" string, but the very
    one used in the keymap.

I suspected that. I don't have that information at the time I'm querying, at
least not the way I'm doing things now. I save the exact binding (command or
keymap), but for the key bound to it I save only the external name of the
key (a string).

    > and I did study the easy-menu stuff.  The easy-menu stuff
    > almost seemed as if it was going to get me what I needed, but I wasn't
    > able to make it work.  Other suggestions are welcome, from anyone.

    I think easy-menu is the way to go.  Tell us what you tried.
    Of course, it may also be important to know the context in which you're
    doing that: maybe there's a simpler way.

I will have to look at this again later - perhaps next weekend.

    > If there is no easy (or even feasible) way to do this, I
    > wonder if it isn't a mistake to "allow", or at least encourage,
    > this kind of keymap entry - Imenu is a standard library.

    It's definitely not encouraged, but it should mostly be
    irrelevant, because
    it's an internal issue.  Normally, either you have the key already (from
    read-key-sequence, for example), or you have the menu entry
    name (in which case you have to use code such as the one used in
    easy-menu to scan the keymap and recover the corresponding key).

I map over a keymap with `map-keymap', so I have the `event' and `binding'
arguments. I build an alist of (name . binding) pairs, where `name' is a
string that includes external names of the key and its command, or "..." for
a prefix map - examples:

 "C-a  =  beginning-of-line"
 "C-x  = ..."

I can pick up the Imenu prefix map (`index') OK, but I haven't been able to
pick up its entries (e.g. submenus) on a recursive call. I've tried to treat
all the various key-binding cases, but it's possible I've overlooked
something.

As I say, when I get a chance, I'll take another stab at it. The code is
here, if anyone would like to take a look:
http://www.emacswiki.org/cgi-bin/wiki/icicles-cmd.el. The function that
builds the alist is `icicle-keys+cmds-w-prefix'. The function that does
alist lookup later is `icicle-complete-keys(-1)'.

Right now, I've excluded the Imenu menus, because I can't handle them
properly. To disable that exclusion, take out the line that has the comment
"Skip Imenu menu".

To try this in context interactively, you'll need the other Icicles
libraries too: http://www.emacswiki.org/cgi-bin/wiki/Icicles_-_Libraries.
This feature is bound to `S-TAB' when in Icicles minor mode - use `S-TAB' to
navigate the key-binding hierarchy (`..' to go up; `...' to go down into a
prefix map). When you try to descend into the keymap `menubar', then `index'
(which is Imenu), then a submenu (such as `Variables'), you get error "No
keys for prefix `[menu-bar index Variables]'". Right now, the code looks for
this submenu keymap as [Variables], not as ["Variables"] with the exact
string from the keymap.

Thx.

Re: looking up a submenu keymap in a menu keymap, when the submenu key is a string

[Stefan Monnier]

> I map over a keymap with `map-keymap', so I have the `event' and `binding'
> arguments. I build an alist of (name . binding) pairs, where `name' is a
> string that includes external names of the key and its command, or "..." for
> a prefix map - examples:

>  "C-a  =  beginning-of-line"
>  "C-x  = ..."

So that's why you rely crucially on read-kbd-macro being an exact inverse of
single-key-description?  Sounds like bad design.  Why not return an alist of
the form (name key binding) so you can always trivially recover the `key'
from the name, without even using read-kbd-macro?


        Stefan

RE: looking up a submenu keymap in a menu keymap, when the submenu key is a string

[Drew Adams]

    > I map over a keymap with `map-keymap', so I have the `event'
    > and `binding' arguments. I build an alist of (name . binding)
    > pairs, where `name' is a string that includes external names
    > of the key and its command, or "..." for a prefix map - examples:
    >
    >  "C-a  =  beginning-of-line"
    >  "C-x  = ..."

    So that's why you rely crucially on read-kbd-macro being an
    exact inverse of single-key-description?  Sounds like bad design.
    Why not return an alist of the form (name key binding) so you can
    always trivially recover the `key' from the name, without even
    using read-kbd-macro?

Well, that was going to be my next step, after you had explained that the
same string (eq) was needed and would work. Yes, it will be simpler. Using
simple strings seemed simpler initially; sometimes, what seems simpler is
not. It now appears that moving between name and key for this use is
non-trivial, and that keeping the key and binding around is simpler.

I added the real binding for that same reason, in fact. I originally used
just the external key name and command name, both strings. That worked fine
for all but the menu-bar keymap, which was not part of the original idea.
The real binding was needed for the menu-bar keymap, and the real key is
apparently needed for the Imenu keymap.

Thanks for your feedback.