bug#14084: 24.3.50; `substitute-command-keys': allow for expansion of <remap>...

bug#14084: 24.3.50; `substitute-command-keys': allow for expansion of <remap>...

[Drew Adams]

In a particular mode, suppose code remaps a command, such as
`reposition-window', to a command `foo'.  `substitute-command-keys'
shows that fact only this way:
 
 <remap> <reposition-window>     foo
 
That can be good information to show users, provided the currently
active bindings of `reposition-window' are known to them.  If not, it
just obscures things.
 
And `substitute-command-keys' might be called from a particular mode
(and several minor modes might be current etc.), so that it might not be
accurate or sufficient for a user to resort to `M-x where-is
reposition-window' to try to find out what <remap> corresponds to in the
context of the call to `substitute-command-keys'.
 

Please add an optional arg to `substitute-command-keys' that changes the
behavior.  Please allow for these 3 possibilities:
 
1. Follow the current behavior (it could be the default): show only the
<remap> entry.
 
2. Show instead a key binding entry for each actual-key binding caused
by the remapping.  IOW, expand <remap> into one or more actual-key
bindings.  Handle remap of remap the same way.  IOW, the output would
not show any <remap> entries, but would show only their expansions.
 
3. Show both the <remap> entries and their expansions, i.e., #1 + #2.
 
4. Alternatively, the <remap> entries could be links/buttons that when
followed expand to actual-key bindings (in place, within the same
overall list of bindings).  One difference (advantage & disadvantage)
with this approach would be the order of the keys in the buffer.
 
Note that with the introduction of things like <remap> we are now
farther afield from the claimed behavior (and the intention) of
`substitute-command-keys':
 
  \[COMMAND] is replaced by either a keystroke sequence that
  invokes COMMAND, or "M-x COMMAND"
 
<remap>... is technically a "keystroke sequence" in one sense (it is a
key binding, at least), but in another sense it is not what the user
expects.  When <remap> was added we more or less just punted wrt
`substitute-command-keys' - we didn't really finish the job.
 
 
 

In GNU Emacs 24.3.50.1 (i386-mingw-nt5.1.2600)
 of 2013-03-23 on VBOX
Bzr revision: 112115 eliz@gnu.org-20130323093300-rjs0dgskxm9u0ya4
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (4.7) --no-opt --enable-checking --cflags
 -IC:/emacs/libs/libXpm-3.5.10/include -IC:/emacs/libs/libXpm-3.5.10/src
 -IC:/emacs/libs/libpng-dev_1.4.3-1_win32/include
 -IC:/emacs/libs/zlib-dev_1.2.5-2_win32/include
 -IC:/emacs/libs/giflib-4.1.4-1-lib/include
 -IC:/emacs/libs/jpeg-6b-4-lib/include
 -IC:/emacs/libs/tiff-3.8.2-1-lib/include
 -IC:/emacs/libs/libxml2-2.7.8-w32-bin/include/libxml2
 -IC:/emacs/libs/gnutls-3.1.10-w32/include
 -IC:/emacs/libs/libiconv-1.14-2-mingw32-dev/include'
 

bug#14084: 24.3.50; `substitute-command-keys': allow for expansion of <remap>...

[Lars Ingebrigtsen]

"Drew Adams" <drew.adams@oracle.com> writes:

> In a particular mode, suppose code remaps a command, such as
> `reposition-window', to a command `foo'.  `substitute-command-keys'
> shows that fact only this way:
>
>  <remap> <reposition-window>     foo
>
> That can be good information to show users, provided the currently
> active bindings of `reposition-window' are known to them.  If not, it
> just obscures things.

This information is displayed in different ways in different contexts.
With this test case:

(keymap-local-set "C-c c" #'foo)

(keymap-local-set "<remap> <foo>" #'bar)

(defun foo ()
  (interactive)
  "Call with \\[foo]."
  (message "foo"))

(defun bar ()
  (interactive)
  "Call with \\[foo]."
  (message "bar"))

C-h b (for instance) says

<remap> <foo>	bar
C-c c		foo

while C-h f foo RET says

Its keys are remapped to ‘bar’.  Without this remapping, it would be
bound to C-c c.

I think the `C-h b' output could perhaps be reorganised, because bar and
foo frequently are displayed far apart, so the person looking for the
key for bar would have to look around.

We could, for instance, add an extra line here.

But did you have other contexts in mind?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#14084: 24.3.50; `substitute-command-keys': allow for expansion of <remap>...

[Drew Adams]

> This information is displayed in different ways in different contexts.
> With this test case:
> 
> (keymap-local-set "C-c c" #'foo)
> (keymap-local-set "<remap> <foo>" #'bar)
> 
> (defun foo ()
>   (interactive)
>   "Call with \\[foo]."
>   (message "foo"))
> 
> (defun bar ()
>   (interactive)
>   "Call with \\[foo]."
>   (message "bar"))
> 
> C-h b (for instance) says
> 
> <remap> <foo>	bar
> C-c c		foo
> 
> while C-h f foo RET says
> 
> Its keys are remapped to ‘bar’.  Without this remapping, it would be
> bound to C-c c.
> 
> I think the `C-h b' output could perhaps be reorganised, because bar
> and
> foo frequently are displayed far apart, so the person looking for the
> key for bar would have to look around.
> 
> We could, for instance, add an extra line here.
> 
> But did you have other contexts in mind?

1. Please reread the bug report.  It's specific about
   what behavior is requested - see below.

2. Please don't reply here using `keymap-*'.  If you
   want to communicate with me about key bindings,
   please use the standard, traditional functions.
   I don't have, and cannot use, Emacs 28, 29 etc.
   The bug/request was reported for Emacs 24.  It's
   still relevant, I believe.

Specific request, from the bug report - just please
modify `substitute-command' to add another arg that
provides for the behavior cited:

___
Please add an optional arg to `substitute-command-keys' that
changes the behavior.  Please allow for these 3 possibilities:
 
1. Follow the current behavior (it could be the default):
show only the <remap> entry.
 
2. Show instead a key binding entry for each actual-key binding caused
by the remapping.  IOW, expand <remap> into one or more actual-key
bindings.  Handle remap of remap the same way.  IOW, the output would
not show any <remap> entries, but would show only their expansions.
 
3. Show both the <remap> entries and their expansions, i.e., #1 + #2.
 
4. Alternatively, the <remap> entries could be links/buttons that when
followed expand to actual-key bindings (in place, within the same
overall list of bindings).  One difference (advantage & disadvantage)
with this approach would be the order of the keys in the buffer.
 
Note that with the introduction of things like <remap> we are now
farther afield from the claimed behavior (and the intention) of
`substitute-command-keys':
 
  \[COMMAND] is replaced by either a keystroke sequence that
  invokes COMMAND, or "M-x COMMAND"
 
<remap>... is technically a "keystroke sequence" in one sense (it is a
key binding, at least), but in another sense it is not what the user
expects.  When <remap> was added we more or less just punted wrt
`substitute-command-keys' - we didn't really finish the job.

bug#14084: 24.3.50; `substitute-command-keys': allow for expansion of <remap>...

[Lars Ingebrigtsen]

Drew Adams <drew.adams@oracle.com> writes:

> Specific request, from the bug report - just please
> modify `substitute-command' to add another arg that
> provides for the behavior cited:
>
> ___
> Please add an optional arg to `substitute-command-keys' that
> changes the behavior.  Please allow for these 3 possibilities:

I asked for an explanation of what the circumstances you wanted to see
the different expansions were.  Restating the original bug report
doesn't help here, but that's par for the course with your responses, of
course, so that's OK.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#14084: 24.3.50; `substitute-command-keys': allow for expansion of <remap>...

[Drew Adams]

> > Specific request, from the bug report - just please
> > modify `substitute-command' to add another arg that
> > provides for the behavior cited:
> >
> > ___
> > Please add an optional arg to `substitute-command-keys' that
> > changes the behavior.  Please allow for these 3 possibilities:
> 
> I asked for an explanation of what the circumstances you wanted to see
> the different expansions were.  Restating the original bug report
> doesn't help here, but that's par for the course with your responses,
> of course, so that's OK.

It doesn't matter for what circumstances someone
would want to use the new arg to specify any of
the 3 possible behaviors it should provide.

It's up to _callers_ to choose which of those
behaviors to specify.  The new arg should allow
a caller to get any of the 3 behaviors - that's
the request.

The enhancement specifies what's requested.  How
or where Emacs itself might choose to use one
of the behaviors is irrelevant to the request,
and thus beyond its scope.  If you want to change
any callers in Emacs's own code, that's up to you.

My concern is for use of the function by users.
That's why I made the request.

Your apparent confusion about the idea of users
using Elisp functions is perhaps par for the
course.  But yes, Elisp, and Emacs generally, is
for _users_.

bug#14084: 24.3.50; `substitute-command-keys': allow for expansion of <remap>...

[Lars Ingebrigtsen]

Drew Adams <drew.adams@oracle.com> writes:

> It doesn't matter for what circumstances someone
> would want to use the new arg to specify any of
> the 3 possible behaviors it should provide.

I get it; you don't have a specific use case in mind, but just want this
because you want it.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#14084: 24.3.50; `substitute-command-keys': allow for expansion of <remap>...

[Drew Adams]

> > It doesn't matter for what circumstances someone
> > would want to use the new arg to specify any of
> > the 3 possible behaviors it should provide.
> 
> I get it; you don't have a specific use case in mind,

That doesn't follow at all.  Each behavior is
useful.  I wouldn't have proposed 3 specific
behaviors if I didn't think each was useful.

> but just want this because you want it.

I think it's useful and makes sense.  But I
have no illusions that you'll find it so, i.e.,
that you'll "get it".

The original request stated the motivation/need:

 <remap> <reposition-window>     foo

 just obscures things, if a user doesn't know the
 currently active bindings of `reposition-window'.

That's the problem to fix.  I saw 3 alternative
ways it can make sense to address the problem,
and I specified them.

If you want to be constructive, maybe think about
those 3 ways or suggest alternative solutions.

Or not.  As is your wont, just close the bug as
wont-fix, if you don't agree there's a problem
to fix.

To me, the solution to the problem involves, as
the Subject line says, expanding the <remap>.

How to expand it?  What do you propose?  I think
different callers might want different expansions.
What do you think?

bug#14084: 24.3.50; `substitute-command-keys': allow for expansion of <remap>...

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I think the `C-h b' output could perhaps be reorganised, because bar and
> foo frequently are displayed far apart, so the person looking for the
> key for bar would have to look around.
>
> We could, for instance, add an extra line here.
>
> But did you have other contexts in mind?

Apparently not, so I've now added code to Emacs 29 that results in this
sort of display:


<remap> <display-buffer>                ido-display-buffer
C-x 4 C-o                               display-buffer
<remap> <display-buffer-other-frame>    ido-display-buffer-other-frame
C-x 5 C-o                               display-buffer-other-frame
<remap> <insert-buffer>                 ido-insert-buffer
C-x x i                                 insert-buffer
<remap> <kill-buffer>                   ido-kill-buffer
C-x k                                   kill-buffer
<remap> <switch-to-buffer>              ido-switch-buffer
C-x b                                   switch-to-buffer
<remap> <switch-to-buffer-other-frame>  ido-switch-buffer-other-frame
C-x 5 b                                 switch-to-buffer-other-frame
<remap> <switch-to-buffer-other-window> ido-switch-buffer-other-window
C-x 4 b                                 switch-to-buffer-other-window


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#14084: 24.3.50; `substitute-command-keys': allow for expansion of <remap>...

[Drew Adams]

> > I think the `C-h b' output could perhaps be reorganised, 
> > because bar and foo frequently are displayed far apart,
> > so the person looking for the key for bar would have to look around.
> >
> > We could, for instance, add an extra line here.
> > But did you have other contexts in mind?
> 
> Apparently not, so I've now added code to Emacs 29
> that results in this sort of display:
> 
> <remap> <display-buffer> ido-display-buffer
> C-x 4 C-o                display-buffer


The request was to please add an optional arg to
`substitute-command-keys' that changes the behavior.
IOW, give code control - and in the ways suggested.  

So ... "won't fix".  You ignored the request and did
what you wanted from the beginning for a different
problem you saw: just foo and bar being far apart.