Re: Proposal: Remap interactive commands via keymaps

[Kim F. Storm]

Richard Stallman <address@hidden> writes:

>     If this is implemented, I would propose to add a new variable named,
>     say, `remap-interactive-commands-p' (default t) to [temporarily]
>     disable this feature.  The purpose of this variable is two-fold:
> 
>     1) make it possible to disable the feature for some specific purpose
>        (which I cannot imagine, but just in case something will need it)
> 
> I don't see a need for that.

It depends on how it is implemented [see my long mailing on this issue
from yesterday].

If the remapping is done in call-interactively, then I have some code
where the remapped function would like to call the original function
(as a fallback), and in that case I want to be able to avoid remapping
the original command back to my command again...  [but for this
specific purpose, I could probably do that by temporarily disabling my
minor mode instead].

Or it can be done via the extra NO_REMAP argument to call-interactively
that I indicated could be necessary (to get around the problem with the
pre-command-hook problem for commands invoked via M-x).

Also, there has been some discussion on this list that it should be
possible for the user to easily invoke the original command and in
that case, it would be simple to write a function like this:

(defun execute-extended-command-no-remap ()
   (interactive)
   (let ((remap-interactive-commands nil))
      (call-interactively 'execute-extended-command)))

(define-key global-map "\e\ex" 'execute-extended-command-no-remap)

If call-interactively has a fourth argument, this could also be
written without the remap-interactive-commands variable as

(defun execute-extended-command-no-remap ()
   (interactive)
   (call-interactively 'execute-extended-command nil nil t))

but the first form will also work for calling a wrapper functions
which makes the interactive call during its operation.

So I do think there might be some code which can benefit from having
the remap-interactive-commands variable.  At least I don't see how it
can harm to provide it.

> 
>     2) so a package can test it using (boundp '...) to determine whether
>        this feature is available
> 
> The natural way to do this is to put something in the features list.

Of course!  I didn't think about that.

Currently, it contains mostly (or only?) features provided by loading
el files (where the feature name corresponds more or less to the name
of the file as set by provide in those files).

I suppose I could use (featurep 'remap-interactive-commands) although
it is quite long compated to the normal feature symbols.  The advantage
is that it shares the name of the variable which enables the feature.

If you don't like that, (featurep 'remap) would be shorter, but at
risk conflicting with some existing (or future) remap.el package.
Perhaps (featurep :remap) could be used to denote it as a built-in
feature?

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