Re: Proposal: Remap interactive commands via keymaps

[Kim F. Storm]

Richard Stallman <address@hidden> writes:

>     >     (define-key x-mode-map [self-insert-command] 'x-self-insert-command)
> 
>     How is this different from substitute-key-definition?  What am I
>     missing?
> 
> You might be able to get the same jobs done with
> substitute-key-definition, but this is a lot more elegant--the code
> and the data structures would be simpler.  And this is more robust
> in its handling of subsequent rebinding of the other keymap.
> 
> I think this is a great idea.
> 

Ok, I started to look into how this should actually work in practice,
and how to implement it.

One of the goals was that all interactive commands should be remapped,
so the proper place to do the actual remapping would be in call-interactively.

This means that besides the `truely' interactive commands which the user
enters via normal key bindings or via M-x, all commands executed via
command-execute and call-interactively will also be remapped.

Although this may seem a little strange at first, it really seems to
be the only way to ensure a consistent behaviour of remapping commands
like this.

It is also the simplest way to implement it.

However, I found that this has the unfortunate effect that the
pre-command-hooks will be called with the original command in 
this-command - since command_loop_1 runs the pre-command-hooks
before the call to Fcommand_execute :-(

To avoid this inconsistency, the remapping should really happen
in command_loop_1 before running the pre-command-hooks.  But if
we do the remapping there - and also in call-interactively -
we will do the remapping twice!

To correct that problem, Fcommand_execute and Fcall_interactively
could both be given an additional optional argument NO_REMAP which
will inhibit remapping if non-nil (to be set when calling
Fcommand_execute from command_loop_1).  This may also be useful for
calls to those functions which explicitly want to avoid the remapping.

Besides testing the already proposed variable `remap-interactive-commands',
I would set the variable `this-original-command' to the original command
returned by read_key_sequence.  It would be nil if the command was not
remapped.

Now, I wonder whether it makes sense to continue looking up the
remapped commands as long as the lookup succeeds.  Formally, it is
probably the correct thing to do, but I don't think it is necessary,
since the variuos modes which would like to remap a command should
remap the original command - rather than remapping the `modified'
function of another mode.  So I think just doing a single lookup will
be sufficient in practice.

But then I noticed another - more fundamental - problem with the
current sequence of executing the pre-command-hooks when doing
M-x ...  :

When I do, `M-x actual-command', the pre-command-hooks are run with
this-command set to `execute-extended-command' rather than
`actual-command'.  So in this case, the pre-command-hooks are
not run at all for the actual commands when M-x is used.

This may break some packages (like delete-selection-mode) which relies
on being able to make decisions based on the actual command in the
mode's pre-command hook.  This obviously doesn't work as intended when
the hook isn't run if the command happens to be executed via M-x!

I would therefore suggest that when M-x is used, the execution of the
pre-command-hook is postponed until the actual command has been read.

This can be done by having command_loop_1 check explicitly for
this-command != Sexecute_extended_command (if that's the proper way to
do it?) before running the hooks, and then explicitly run the hooks in
Fexecute_extended_command before it calls Fcommand_execute.

If you think this makes sense, I volounteer to make the necessary
changes to add the new feature - and fix the problem with M-x described
above.

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