emacs-pretest-bug
[Top][All Lists]
Advanced

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

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


From: Drew Adams
Subject: RE: accessible-keymaps gives wrong result for autoloaded prefix keys
Date: Tue, 3 Oct 2006 07:56:07 -0700

    > M-: (accessible-keymaps (current-global-map) [f2])
    > This returns nil.
    > (accessible-keymaps (current-global-map) []) shows this in the global
    > map: (f2 . 2C-command).
    > The problem is that the `symbol-function' of `2C-command' is (autoload
    > "two-column" nil t keymap).
    > `accessible-keymaps' cannot do its job correctly, and return a correct
    > result, unless it loads two-column.el when it needs to.  Emacs should
    > consider that using `accessible-keymaps' this way should load the
    > file, just as using `C-h k f2' or `C-h f 2C-command' loads it.
    > The same is true for all other autoloaded commands bound to keymaps
    > (prefix keys).

    Currently accessible-keymaps indeed does not execute any elisp code (and
    hence doesn't autoload keymaps either), so that as to guarantee
    not to call the garbage collector. IIRC this is necessary because
    it's used in where-is-internal, itself called from the menu-construction
    code at a place where GC could screw things up.

    Furthermore, if keymaps were autoloaded by accessible-keymaps,
    it would mean that all keymaps would be autoloaded at the first use
    of where-is-internal, which basically means "immediately" since
    where-is-internal is used very often (e.g. after M-x, or to build
    menus, or ...).

    I'm not saying it's not a bug, but just giving some explanation for the
    current situation.

    One possible fix is to change accessible-keymaps so that it returns
    (([f2] . 2C-command)) rather than nil.  The patch below does just that.

    Could you explain why it matters to you?

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.

It matters to me for two reasons:

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

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

Thx.





reply via email to

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