Re: command remapping problem

[Kim F. Storm]

"Drew Adams" <address@hidden> writes:

>
>     3. Example: emacs -q
>
>     (define-key my-map [remap scroll-up] my-scroll-up)
>
>     The `scroll-up' binding for `C-v' is remapped to `my-scroll-up', but
>     the `scroll-up' binding for [next] is not remapped to `my-scroll-up'.
>
>     Similarly, (define-key my-map [remap help-command] my-help-command)
>     does not remap `C-h' to `my-help-command'.
>
>     My tests were done with map = `minibuffer-local-completion-map', but
>     probably the same problem exists for other maps.

Sure -- if those maps bind next to something other than scroll-up, e.g.

(lookup-key minibuffer-local-completion-map [next])
next-history-element

So:
 C-v ==lookup==> scroll-up ==remap==> my-scroll-ip
 next ==lookup==> next-history-element ==remap==> next-history-element


>     `minibuffer-local-completion-map', I want to substitute (remap,
>     whatever) all key sequences that are bound in `global-map' to certain
>     commands, to other commands, for use in minibuffer completion. Using
>     `global-map' as the OLDMAP parameter of `substitute-key-definition'
>     works perfectly for this (modulo performance); command remapping does
>     not.

If other maps override bindings in global-map, remapping the original
commands from global-map (obviously) have no effect ... 


>
>     I'm guessing that the problem is that `define-key' works only with the
>     bindings that are accessible from its MAP arg, not `global-map'
>     bindings - for example, [next] is not bound to `scroll-up' in
>     `minibuffer-local-map', so it is not remapped.

Oh, you already knew the answer...

>     If this is the explanation, and this is not simply a bug, then I guess
>     that would mean that there is no way to get the behavior of
>     `substitute-key-definition's OLDMAP argument.  

What do you mean?  
That you cannot get OLDMAP behaviour with command remapping. True!
But substitute-key-definition still has the OLDMAP arg.

>                                                    In that case, we have
>     lost functionality in going to Emacs 22, because
>     `substitute-key-definition' is unusable (at least with
>     `self-insert-command'), for performance reasons.

That is not a problem with command remapping, so don't blame command
remapping of being inadequate as a substitute for some other feature
it was not designed to replace (entirely).

As I see it, command remapping works just fine for what it is designed
to do (and I use it a lot).

In any case, why don't you just remap the self-insert-command in the
buffer local map (e.g. minibuffer-local-completion-map) rather than
in global map?  That should work just fine!

-- 
Kim F. Storm <address@hidden> http://www.cua.dk