Re: Proposal: Remap interactive commands via keymaps

[Kim F. Storm]

Richard Stallman <address@hidden> writes:

>     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.
> 
> I don't agree--I think that call-interactively should not do this.

Regarding call-interactively, you are probably right.

But IMO it shall be done in both command_loop_1 *and* in
execute-extended-command.  

Please consider the arguments and the examples I've provided below.
If that still cannot convince you, I'll bow my head and shut up.

> 
> I am convinced that the remapping of commands should NOT apply
> to command names that you specify with M-x.  Please consider that
> a closed question.
> 
> This remapping feature should be associated with keymap lookup,
> not with running a command.

Well, I'm sorry that is your view.  

As an real-life example, I have written cua.el which depends on both
examining this-command in the pre-command-hook and remapping commands
through a keymap (in a brute force manner), and it works fine as long
as the user doesn't use M-x to run any of the overloaded commands.  If
he does, things only go slightly wrong for some commands, utterly
wrong for other commands, whereas practically none of them works
correctly.

So the proposal I have made is based on actual experience writing and
using a fairly large package which can benefit a lot from the proposed
feature if it is implemented correctly (and not just half-way).

Personally, I don't see any reason why `M-x command' should not honour
command remapping if we have explicitly remapped `command' to do
something else when a specific minor (or major) mode is active.
After all, users would normally have decided to enable that mode
themselves anyway.


But during my almost 20 years of emacs usage, I obviously haven't been
aware that e.g. `M-x kill-line' deliberately had different semantics
than hitting C-k (bound to kill-line).

To me, M-x has always been just a different way to run a command,
which may or may not have a binding.

If I enter `M-x kill-line', emacs even tells me that I can run
kill-line with C-k, but now you tell me that I should be aware that
those two ways to run kill-line interactively are not identical.

In the current version of emacs, they really are different, since the
pre-command-hook is run with different values of this-command.
.. and that difference is the desired functionality?  Can you point
me to an example which relies on this difference in functionality?

And with the addition of command remapping, you want them to behave
even more differently.  I simply don't understand why you want their
functionality to diverge even more!


Let me give you another example:

Suppose I have enabled whizzy-mode - which modifies
lisp-complete-symbol in some whizzy fashion.  Actually, I enabled
whizzy-mode 3 years ago and forgot all about it; I just like the
way it modifies the lisp-complete-symbol command.

So, in a lisp interaction buffer, hitting ESC TAB will cause the
whizzy-lisp-complete-symbol function to be run.

But now I want to respond to an entry in gnu.emacs.bug, and would
like to complete a lisp symbol (in the whizzy way I'm used to).
What command should I enter?

ESC TAB does work - as it runs ispell-complete-word in a gnus message
buffer.

M-x lisp-complete-symbol does complete the symbok - but not in the
whizzy way I'm used to.

No, according to you and Jason, I (and any novice user like me) have
to explicitly know that although I enabled whizzy-mode, I need to
enter M-x whizzy-lisp-complete-symbol to get the behaviour I want.

IMO, that is *not* user friendly.


I think I have provided several arguments in favour of having M-x
commands remapped (i.e. shown you things that will break if M-x does
not remap commands), while neither you nor Jason has provided any
arguments against it!


> 
>     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 is ok, because they are run before the M-x command itself.
> And before the RET that terminates the minibuffer and leads
> to execution of the specified command.

Try the following:

emacs -q
M-x delete-selection-mode
M-< C-f C-f C-f C-SPC C-M-f M-w  (copy `This')
C-M-f C-f C-SPC C-M-f  (highlight `is')
C-y  (replaces `is' with `This')

Now do exactly the same, except instead of C-y do
M-x yank  (inserts `This' after `is')

This is a consequence of the delete-selection-pre-hook being
run with this-command equal to execute-extended-command rather
than yank (which is the actual command being executed).

Why do you think than an average user would expect yank and yank to
behave differently whether he runs it via C-y or M-x yank ?
I simply cannot understand how you can say this is the correct
behaviour!
 
> 
>     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.
> 
> I don't see a need for this change.
> 

I hope I have demonstrated why delaying the execution of the
pre-command-hook makes sense (whereas I don't see any reason to insist
on retaininig the current behaviour).

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