RE: command remapping problem

[Drew Adams]

    > I'm not sure what you mean. Command remapping for
    > `self-insert-command' is
    > not the problem - that works fine. As I said, I do, as a
    > workaround, use
    > command remapping for `self-insert-command' and
    > `substitute-key-definition'
    > for all other commands. This is a workaround because it requires
    > special-casing `self-insert-command'.

    If remapping works for self-insert-command, why can't you use it for
    other commands?

Please read the previous posts to the thread. You and I discussed this
already. The answer is: because I cannot pass an OLDMAP arg for command
remapping. I want to pick up all of the global-map bindings for the
remapping, but some are shadowed (so, missing) locally, so they are not
taken into account by remapping. As we discussed, "`define-key' works only
with the bindings that are accessible from its MAP arg, not the `global-map'
bindings." Or, as you put it: "you cannot get OLDMAP behaviour with command
remapping".

As luck would have it, the shadowing problem did not exist in this context
for `self-insert-command'. So, I was able to get around the problem by
remapping `self-insert-command' (and using `substitute-key-definition' for
the other commands).

    > The problem is that I tried also using command remapping for
    > other commands that have multiple bindings and, as you pointed out,
    > bindings that are different in different maps. Because there is
    > no OLDMAP arg for command remapping, I cannot use it to substitute
    > for the use case of `substitute-key-definition' with OLDMAP.

    I don't follow ... if command remapping doesn't work becuase bindings
    are different in different maps, why does substitute-key-definition
    work in those cases?

I can supply arg OLDMAP to `substitute-key-definition'; I cannot supply it
for command remapping. With `substitute-key-definition', I can use
`global-map' as OLDMAP to be sure to pick up all global bindings, even those
that are (currently) shadowed locally.

    > I was hoping for a general solution that someone can use for
    > all commands.

    That general solution could be remapping, perhaps combined with a
    minor mode keymap that will take precedence over other keymaps
    (depending on what you try to achieve, emulation-mode-map-alists
    may be useful).

Sorry, I don't know anything about emulation-mode-map-alists (and your
solution description is a bit incomplete, to me). I can try to look into
using emulation-mode-map-alists, but for now I already have a very workable
workaround. I wasn't really looking for another one. If what you are
describing is not a workaround, but a general solution, perhaps you could
document it more carefully, and that doc could serve users generally. Of
course, if the bug gets fixed, there might not be any need for such
documentation.

My point is a general one: `substitute-key-definition' has lost effective
functionality because of the performance hit for `self-insert-command'.

Alternatively, _if_ command remapping were intended as a complete, general
substitute for `substitute-key-definition' (you've confirmed that it is
not), then it would be incomplete, because it does not let you specify an
OLDMAP arg.

Either way you look at it, you cannot do in Emacs 22 (with reasonable
performance) what you could do before.

Before, you did not need to have any knowledge of which commands were
involved; you could even loop over all commands (if you wanted to),
substituting their bindings from some OLDMAP. Now, you must know about and
treat `self-insert-command' specially, or take an unacceptable performance
hit.

And, if `self-insert-command' happens to not have some bindings in the
current map that it has in the global-map, then, IIUC, you are up the creek
without a paddle - you cannot pick up those global bindings using command
remapping. I was lucky wrt `self-insert-command': I was able to get away
with using command remapping for it, without losing any global bindings.