Question on remapping keys

Question on remapping keys

[Drew Adams]

I sent this to help-gnu-emacs, but I haven't yet found a solution to the
problem. I wonder too if there might be a bug here.

I have a minor mode that redefines some of the minibuffer keymaps (e.g.
minibuffer-local-completion-map). I want turning on the mode to implement
the new minibuffer bindings, and turning it off to restore the minibuffer
bindings of vanilla Emacs.

In some cases, I reuse key sequences that are bound in the global map,
binding them to other commands in minibuffer maps. Those are the bindings
that I have a question about.

In Emacs 20, I simply do this:

(substitute-key-definition from to
   minibuffer-local-completion-map global-map)

For example, to bind `C-h' in the minibuffer to command `my-help':

(substitute-key-definition 'help-command 'my-help
   minibuffer-local-completion-map global-map)

I do the same for `self-insert-command', replacing it with `my-self-insert'
for minibuffer maps.

This is very fast in Emacs 20, but in Emacs 22 it is unbearably slow. It
takes about 5 seconds for only 10 such key-definition substitutions! I think
that the slowness might be due, in particular, to dealing with the case of
`self-insert-command'.

Someone (Kim?) suggested that I could use `define-key' with [remap...]
instead of `substitute-key-definition'. I tried using the following when my
minor mode is turned on:

(defun my-remap (from to map)
 "Remap command FROM to command TO in keymap MAP."
 (if (boundp 'this-original-command)
     (define-key map `[remap ,from] to)                 ; Emacs 22
   (substitute-key-definition from to map global-map))) ; Emacs 20

And similarly when it is turned off, using nil for TO, to remove the binding
from MAP (a minibuffer map). The result of remapping is this for
minibuffer-local-completion-map:

(keymap
 ...
 (remap keymap
        (scroll-left         . my-scroll-left)
        (scroll-right        . my-scroll-right)
        (scroll-down         . my-scroll-down)
        (scroll-up           . my-scroll-up)
        (next-line           . my-next-line)
        (previous-line       . my-previous-line)
        (help-command        . my-help)
        (self-insert-command . my-self-insert))
...)

This looks promising, but it seems to work only partially. For instance,

(where-is-internal 'my-scroll-up
                   (list minibuffer-local-completion-map))

returns ([remap scroll-up]), which looks good. `M-x' followed by `C-v' does
invoke `my-scroll-up', but `M-x' followed by [next] (also bound to
`scroll-up' in `global-map') does not invoke `my-scroll-up' - it invokes
`next-history-element', just as in vanilla Emacs.

IOW, apparently not all bindings of `scroll-up' got remapped. I don't know
if this is a bug or by design.

I'm looking for behavior similar to that of `substitute-key-definition':
remap/substitute _all_ bindings. This is especially important since I
apparently have no control over which single binding gets remapped - that
is, only one binding of the command seems to be remapped, and I don't know
how to pick which one.

Similarly,

(where-is-internal 'my-help
                   (list minibuffer-local-completion-map))

returns ([remap help-command]). That suggests that `help-command' was
remapped, but using `C-h' in the minibuffer does not invoke `my-help'.
(Why?)

If I use `substitute-key-definition', providing `global-map' as the OLDMAP
arg, it works perfectly, but the performance is unacceptable in Emacs 22.
There must be some way to do something equivalent using command
remapping(?).

Anyone have a suggestion on how to proceed?

RE: Question on remapping keys

[Drew Adams]

I realize that I sent this question only yesterday. Today, I noticed that
code identical to what I use (see `my-remap', below) is used in
`arc-mode.el' and `emerge.el' (and `tramp-util.el' and `picture.el' do
something similar), so it's apparently not a far-out request.

Is this a bug? If not, how can I get remapping to substitute _all_ of a
command's bindings?

Thanks.

P.S. Actually, `emerge.el' does _both_ `substitute-key-definition' and
remapping for the same commands. Is this useful? (Perhaps it has to do with
not using an OLDMAP arg with `substitute-key-definition'?)

----

    I sent this to help-gnu-emacs, but I haven't yet found a solution to the
    problem. I wonder too if there might be a bug here.

    I have a minor mode that redefines some of the minibuffer keymaps (e.g.
    minibuffer-local-completion-map). I want turning on the mode to
    implement the new minibuffer bindings, and turning it off to restore the
    minibuffer bindings of vanilla Emacs.

    In some cases, I reuse key sequences that are bound in the global map,
    binding them to other commands in minibuffer maps. Those are
    the bindings that I have a question about.

    In Emacs 20, I simply do this:

    (substitute-key-definition from to
       minibuffer-local-completion-map global-map)

    For example, to bind `C-h' in the minibuffer to command `my-help':

    (substitute-key-definition 'help-command 'my-help
       minibuffer-local-completion-map global-map)

    I do the same for `self-insert-command', replacing it with
    `my-self-insert' for minibuffer maps.

    This is very fast in Emacs 20, but in Emacs 22 it is unbearably slow. It
    takes about 5 seconds for only 10 such key-definition substitutions!
    I think that the slowness might be due, in particular, to dealing with
    the case of `self-insert-command'.

    Someone (Kim?) suggested that I could use `define-key' with [remap...]
    instead of `substitute-key-definition'. I tried using the
    following when my minor mode is turned on:

    (defun my-remap (from to map)
     "Remap command FROM to command TO in keymap MAP."
     (if (boundp 'this-original-command)
         (define-key map `[remap ,from] to)                 ; Emacs 22
       (substitute-key-definition from to map global-map))) ; Emacs 20

    And similarly when it is turned off, using nil for TO, to
    remove the binding
    from MAP (a minibuffer map). The result of remapping is this for
    minibuffer-local-completion-map:

    (keymap
     ...
     (remap keymap
            (scroll-left         . my-scroll-left)
            (scroll-right        . my-scroll-right)
            (scroll-down         . my-scroll-down)
            (scroll-up           . my-scroll-up)
            (next-line           . my-next-line)
            (previous-line       . my-previous-line)
            (help-command        . my-help)
            (self-insert-command . my-self-insert))
    ...)

    This looks promising, but it seems to work only partially. For instance,

    (where-is-internal 'my-scroll-up
                       (list minibuffer-local-completion-map))

    returns ([remap scroll-up]), which looks good. `M-x' followed
    by `C-v' does invoke `my-scroll-up', but `M-x' followed by [next] (also
    bound to `scroll-up' in `global-map') does not invoke `my-scroll-up'
    - it invokes `next-history-element', just as in vanilla Emacs.

    IOW, apparently not all bindings of `scroll-up' got remapped. I
    don't know if this is a bug or by design.

    I'm looking for behavior similar to that of `substitute-key-definition':
    remap/substitute _all_ bindings. This is especially important since I
    apparently have no control over which single binding gets
    remapped - that is, only one binding of the command seems to be
remapped,
    and I don't know how to pick which one.

    Similarly,

    (where-is-internal 'my-help
                       (list minibuffer-local-completion-map))

    returns ([remap help-command]). That suggests that `help-command' was
    remapped, but using `C-h' in the minibuffer does not invoke `my-help'.
    (Why?)

    If I use `substitute-key-definition', providing `global-map' as
    the OLDMAP arg, it works perfectly, but the performance is unacceptable
    in Emacs 22. There must be some way to do something equivalent using
    command remapping(?).

    Anyone have a suggestion on how to proceed?



    _______________________________________________
    Emacs-devel mailing list
    Emacs-devel@gnu.org
    http://lists.gnu.org/mailman/listinfo/emacs-devel