Re: accessible-keymaps gives wrong result for autoloaded prefix keys

[Stefan Monnier]

> Thanks for a clear explanation. Your fix would work fine for me. What's
> important is that `accessible-keymaps' return the right result. I think
> you're saying that it's not necessary for it to load the library to be able
> to do that.

My fix doesn't cause accessible-keymaps to return "the right result".

E.g. if 2C-command contains a prefix key such as [f2 f1], it would return
just (([f2] . 2C-command)) even, whereas after autoloading the map
accessible-keyamps would return

  (([f2] keymap ...)
   ([f2 f1] keymap ...))

>  - `accessible-keymaps' advertises that it does this, so it should (or else
> the advertising should be changed).

Well, if we want to nitpick, we can argue that the docstring is sufficiently
vague to allow many different interpretations.  So I don't find this
argument very compelling.

>  - I have code that calls `map-keymap' for each accessible keymap. I want it
> to also pick up the `f2' keymap and other autoloaded keymaps.

> FYI - My code lets you complete key sequences using minibuffer completion
> against the key name (description) plus the binding. In the case of a keymap
> binding (prefix key), you can descend into the prefix to continue
> completing. This is similar to completion of file and directory names
> (command ~ file, prefix key ~ directory) or completion of menu items
> (command ~ menu item, prefix key ~ submenu). IOW, you can navigate through
> the set of key bindings currently accessible. Without this fix, the effect,
> when you complete (i.e. choose) `f2', is that I can only raise an error: "No
> keys for prefix `f2'", which is misleading.

I don't understand why you need accessible-keymaps at all, then.
E.g. before C-x is entered, you don't need to know that there's another
prefix on C-x v.


        Stefan