bug#49265: 28.0.50; repeat mode feature request

bug#49265: 28.0.50; repeat mode feature request

[Ergus via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Is it possible to add a command to get information about the commands
that have a repeat map? Basically something to know the commands with
some associated repeat like list-repeat-commands or describe-repeat or
so?


In GNU Emacs 28.0.50 (build 50, x86_64-pc-linux-gnu, GTK+ Version 3.24.29, cairo version 1.17.4)
 of 2021-06-26 built on Ergus
Repository revision: b8f9e58ef72402e69a1f0960816184d52e5d2d29
Repository branch: master
System Description: Arch Linux

Configured using:
 'configure --prefix=/home/ergo/.local/ --with-mailutils --with-json
 --with-x-toolkit=gtk3 --with-xft --with-wide-int --with-modules
 --with-cairo --with-harfbuzz --with-native-compilation'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER
PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS X11 XDBE XIM XPM
GTK3 ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: C++//law

Minor modes in effect:
  global-git-commit-mode: t
  magit-auto-revert-mode: t
  diff-hl-margin-mode: t
  windmove-mode: t
  subword-mode: t
  hide-ifdef-mode: t
  preproc-font-lock-mode: t
  shell-dirtrack-mode: t
  show-paren-mode: t
  global-auto-revert-mode: t
  xclip-mode: t
  yas-global-mode: t
  yas-minor-mode: t
  electric-pair-mode: t
  flyspell-mode: t
  company-mode: t
  flycheck-mode: t
  counsel-mode: t
  ivy-mode: t
  composable-mark-mode: t
  composable-mode: t
  repeat-mode: t
  xterm-mouse-mode: t
  winner-mode: t
  save-place-mode: t
  which-key-mode: t
  override-global-mode: t
  delete-selection-mode: t
  savehist-mode: t
  global-display-fill-column-indicator-mode: t
  display-fill-column-indicator-mode: t
  global-display-line-numbers-mode: t
  display-line-numbers-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  size-indication-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t
  abbrev-mode: t

Load-path shadows:
/usr/share/emacs/site-lisp/cmake-mode hides /home/ergo/.emacs.d/elpa/cmake-mode-20210104.1831/cmake-mode
/usr/share/emacs/site-lisp/notmuch-crypto hides /home/ergo/.emacs.d/elpa/notmuch-20210627.1741/notmuch-crypto
/usr/share/emacs/site-lisp/notmuch-compat hides /home/ergo/.emacs.d/elpa/notmuch-20210627.1741/notmuch-compat
/usr/share/emacs/site-lisp/notmuch-hello hides /home/ergo/.emacs.d/elpa/notmuch-20210627.1741/notmuch-hello
/usr/share/emacs/site-lisp/notmuch hides /home/ergo/.emacs.d/elpa/notmuch-20210627.1741/notmuch
/usr/share/emacs/site-lisp/notmuch-show hides /home/ergo/.emacs.d/elpa/notmuch-20210627.1741/notmuch-show
/usr/share/emacs/site-lisp/notmuch-maildir-fcc hides /home/ergo/.emacs.d/elpa/notmuch-20210627.1741/notmuch-maildir-fcc
/usr/share/emacs/site-lisp/coolj hides /home/ergo/.emacs.d/elpa/notmuch-20210627.1741/coolj
/usr/share/emacs/site-lisp/notmuch-draft hides /home/ergo/.emacs.d/elpa/notmuch-20210627.1741/notmuch-draft
/usr/share/emacs/site-lisp/notmuch-tree hides /home/ergo/.emacs.d/elpa/notmuch-20210627.1741/notmuch-tree
/usr/share/emacs/site-lisp/notmuch-parser hides /home/ergo/.emacs.d/elpa/notmuch-20210627.1741/notmuch-parser
/usr/share/emacs/site-lisp/notmuch-lib hides /home/ergo/.emacs.d/elpa/notmuch-20210627.1741/notmuch-lib
/usr/share/emacs/site-lisp/notmuch-mua hides /home/ergo/.emacs.d/elpa/notmuch-20210627.1741/notmuch-mua
/usr/share/emacs/site-lisp/notmuch-message hides /home/ergo/.emacs.d/elpa/notmuch-20210627.1741/notmuch-message
/usr/share/emacs/site-lisp/notmuch-address hides /home/ergo/.emacs.d/elpa/notmuch-20210627.1741/notmuch-address
/usr/share/emacs/site-lisp/notmuch-wash hides /home/ergo/.emacs.d/elpa/notmuch-20210627.1741/notmuch-wash
/usr/share/emacs/site-lisp/notmuch-tag hides /home/ergo/.emacs.d/elpa/notmuch-20210627.1741/notmuch-tag
/usr/share/emacs/site-lisp/notmuch-print hides /home/ergo/.emacs.d/elpa/notmuch-20210627.1741/notmuch-print
/usr/share/emacs/site-lisp/notmuch-query hides /home/ergo/.emacs.d/elpa/notmuch-20210627.1741/notmuch-query
/usr/share/emacs/site-lisp/notmuch-jump hides /home/ergo/.emacs.d/elpa/notmuch-20210627.1741/notmuch-jump
/usr/share/emacs/site-lisp/notmuch-company hides /home/ergo/.emacs.d/elpa/notmuch-20210627.1741/notmuch-company
/home/ergo/.emacs.d/elpa/transient-20210619.1100/transient hides /home/ergo/.local/share/emacs/28.0.50/lisp/transient

Features:
(gnutls epa-file network-stream nsm mailalias smtpmail shadow sort
notmuch-company notmuch-lib notmuch-version notmuch-compat mm-view
mml-smime smime dig mail-extr emacsbug sendmail magit-extras hi-lock
magit-bookmark magit-submodule magit-obsolete magit-blame magit-stash
magit-reflog magit-bisect magit-push magit-pull magit-fetch magit-clone
magit-remote magit-commit magit-sequence magit-notes magit-worktree
magit-tag magit-merge magit-branch magit-reset magit-files magit-refs
magit-status magit package browse-url url url-proxy url-privacy
url-expand url-methods url-history url-cookie url-domsuf url-util
mailcap url-handlers magit-repos magit-apply magit-wip magit-log
which-func imenu magit-diff smerge-mode diff git-commit log-edit message
rmc puny rfc822 mml mml-sec epa derived epg epg-config gnus-util rmail
rmail-loaddefs mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047
rfc2045 mm-util ietf-drums mail-prsvr mailabbrev mail-utils gmm-utils
mailheader add-log magit-core magit-autorevert magit-margin
magit-transient magit-process with-editor server magit-mode transient
magit-git magit-section magit-utils crm tramp-cmds global-tags ht
generator async counsel-gtags pulse mc-separate-operations mc-edit-lines
mc-hide-unmatched-lines-mode mc-mark-more mc-cycle-cursors
multiple-cursors-core rect move-dup diff-hl-margin eieio-opt speedbar
ezimage dframe shortdoc help-fns radix-tree vc-annotate amx s windmove
misearch multi-isearch ffap url-parse url-vars face-remap vc-hg
macrostep-c cmacexp macrostep cap-words superword subword hideif
preproc-font-lock cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles
cc-align cc-engine cc-vars cc-defs dired-aux diff-hl-dired diff-hl
log-view pcvs-util vc-dir ewoc vc tramp-cache tramp-sh tramp
tramp-loaddefs trampver tramp-integration files-x tramp-compat shell
pcomplete parse-time iso8601 time-date ls-lisp format-spec auth-source
password-cache thingatpt vc-git diff-mode vc-dispatcher bookmark pp
paren autorevert filenotify xclip yasnippet-snippets yasnippet elec-pair
flyspell-correct-ivy flyspell-correct flyspell ispell company-keywords
company-gtags company-dabbrev-code company-dabbrev company-files
company-semantic company-template company-capf company flycheck json map
find-func dash counsel xdg xref project dired-x dired dired-loaddefs
compile text-property-search comint ansi-color swiper ivy-avy avy ivy
flx ivy-faces ivy-overlay colir pcase term/tmux term/xterm xterm
jka-compr init composable composable-mark powerline comp comp-cstr
warnings subr-x powerline-separators color powerline-themes repeat
xt-mouse simple-16-theme winner ring saveplace diminish edmacro kmacro
which-key advice configmail cl-extra help-mode use-package
use-package-ensure use-package-delight use-package-diminish
use-package-bind-key bind-key use-package-core disp-table delsel
savehist easy-mmode display-fill-column-indicator display-line-numbers
info ede/auto eieio-base cl-seq seq eieio byte-opt bytecomp byte-compile
cconv eieio-core cl-macs gv eieio-loaddefs cl-loaddefs cl-lib tex-site
rx slime-autoloads early-init iso-transl tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button
loaddefs faces cus-face macroexp files window text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote threads dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting cairo
move-toolbar gtk x-toolkit x multi-tty make-network-process
native-compile emacs)

Memory information:
((conses 16 823166 101330)
 (symbols 48 30979 0)
 (strings 32 108313 15470)
 (string-bytes 1 4432716)
 (vectors 16 58052)
 (vector-slots 8 1336021 43503)
 (floats 8 348 1228)
 (intervals 56 54166 1667)
 (buffers 992 38))

bug#49265: 28.0.50; repeat mode feature request

[Juri Linkov]

> Is it possible to add a command to get information about the commands
> that have a repeat map? Basically something to know the commands with
> some associated repeat like list-repeat-commands or describe-repeat or
> so?

I thought that such a command could have the same prefix like 'repeat-help',
but prefixes 'list-' and 'describe-' are also fine.  Maybe it should be
similar to 'describe-bindings' or better 'describe-keymap'.

bug#49265: [External] : bug#49265: 28.0.50; repeat mode feature request

[Drew Adams]

> > Is it possible to add a command to get information about the commands
> > that have a repeat map? Basically something to know the commands with
> > some associated repeat like list-repeat-commands or describe-repeat or
> > so?
> 
> I thought that such a command could have the same prefix like 'repeat-help',
> but prefixes 'list-' and 'describe-' are also fine.  Maybe it should be
> similar to 'describe-bindings' or better 'describe-keymap'.

I thought the question was whether Emacs automatically,
or already in some way, provides some a way of
determining (e.g. using Lisp code) whether a given
command is repeatable (i.e., by just holding down a key
that it's bound to).

If that's the question then I think the answer is no.
(Is that right?)
___

If the question is instead just whether there is some
naming convention for such repeatable commands, or if
it is just a suggestion to have such a convention, then
I'll offer the naming pattern I use for such commands:

I append `+' to the command name.

For example, I use `end-of-line+' as the name of my
repeatable version of `end-of-line'.

  If called interactively with no prefix arg:
     If the previous command was also `end-of-line+',
     then move to the end of the next line.  Else, move
     to the end of the current line.
  Otherwise, move to the end of the Nth next line (Nth
     previous line if N<0).  Command `end-of-line', by
     contrast, moves to the end of the (N-1)th next line.

Similarly, repeatable command `doremi-bg+' changes a
frame's background color incrementally.

IMO, it makes much more sense to use a suffix for a
"repeatable" indication than to use a prefix.  And
there's no need for a long (pre|suf)fix, such as
`repeat-'.

Emphasis should be on the actual command name, and not
on the fact that it's repeatable.  One char (or at most
`-' followed by a single char) should suffice.
___

The other part of the request is to have a command
that shows, describes, etc. only repeatable commands.
With my naming that trivially amounts to typing a
pattern that matches `+'.

Even if your completion method doesn't let you limit
matches to `+' only at the end of the name, you'll
likely get only repeatable commands, as there aren't
many existing commands with `+' in the name.

And of course it's easy to define a command that
matches only command names with `+' at the end.
And such a command could do anything you like with
the result (describe all matching commands, return
nil or non-nil for a given command-name arg,...).

bug#49265: 28.0.50; repeat mode feature request

[Juri Linkov]

>> Is it possible to add a command to get information about the commands
>> that have a repeat map? Basically something to know the commands with
>> some associated repeat like list-repeat-commands or describe-repeat or
>> so?
>
> I thought that such a command could have the same prefix like 'repeat-help',
> but prefixes 'list-' and 'describe-' are also fine.  Maybe it should be
> similar to 'describe-bindings' or better 'describe-keymap'.

Now a new command named 'describe-repeat' was pushed to master.  Please try it.
If everything is right, this request could be closed.

bug#49265: [External] : bug#49265: 28.0.50; repeat mode feature request

[Juri Linkov]

> I thought the question was whether Emacs automatically,
> or already in some way, provides some a way of
> determining (e.g. using Lisp code) whether a given
> command is repeatable (i.e., by just holding down a key
> that it's bound to).
>
> If that's the question then I think the answer is no.
> (Is that right?)

The request was to create a new command that lists all repeatable
commands and keymaps.

bug#49265: [External] : bug#49265: 28.0.50; repeat mode feature request

[Drew Adams]

> > I thought the question was whether Emacs automatically,
> > or already in some way, provides some a way of
> > determining (e.g. using Lisp code) whether a given
> > command is repeatable (i.e., by just holding down a key
> > that it's bound to).
> >
> > If that's the question then I think the answer is no.
> > (Is that right?)
> 
> The request was to create a new command that lists all
> repeatable commands and keymaps.

Which amounts to the same thing: determining whether
a given command is repeatable.  I don't think Emacs has
a way of determining that.  (It would even seem to be
undecidable...)

(Though I don't know what you might mean by "and keymaps".
Repeatable keymaps?)

bug#49265: [External] : bug#49265: 28.0.50; repeat mode feature request

[Drew Adams]

> Now a new command named 'describe-repeat' was pushed to master.  Please try
> it.  If everything is right, this request could be closed.

Where was it added to master?  I downloaded the latest
help-fns.el, and I don't see it there.  Could you perhaps
post the code here?  Could you perhaps say, here, just
what it does?  Thx.

bug#49265: [External] : bug#49265: 28.0.50; repeat mode feature request

[Robert Pluim]

>>>>> On Tue, 29 Jun 2021 21:28:44 +0000, Drew Adams <drew.adams@oracle.com> said:

    >> > I thought the question was whether Emacs automatically,
    >> > or already in some way, provides some a way of
    >> > determining (e.g. using Lisp code) whether a given
    >> > command is repeatable (i.e., by just holding down a key
    >> > that it's bound to).
    >> >
    >> > If that's the question then I think the answer is no.
    >> > (Is that right?)
    >> 
    >> The request was to create a new command that lists all
    >> repeatable commands and keymaps.

    Drew> Which amounts to the same thing: determining whether
    Drew> a given command is repeatable.  I don't think Emacs has
    Drew> a way of determining that.  (It would even seem to be
    Drew> undecidable...)

(mapatoms (lambda (sym)
            (and (commandp sym)
                 (get sym 'repeat-map)
                 (message "repeatable %s" sym))))

gets you the potentially repeatable commands. Whether theyʼre actually
repeatable depends on whether 'repeat-mode' is active.

    Drew> (Though I don't know what you might mean by "and keymaps".
    Drew> Repeatable keymaps?)

Bindings to repeatable commands maybe?

Robert
-- 

bug#49265: [External] : bug#49265: 28.0.50; repeat mode feature request

[Robert Pluim]

>>>>> On Tue, 29 Jun 2021 21:33:07 +0000, Drew Adams <drew.adams@oracle.com> said:

    >> Now a new command named 'describe-repeat' was pushed to master.  Please try
    >> it.  If everything is right, this request could be closed.

    Drew> Where was it added to master?  I downloaded the latest
    Drew> help-fns.el, and I don't see it there.  Could you perhaps
    Drew> post the code here?  Could you perhaps say, here, just
    Drew> what it does?  Thx.

Itʼs in repeat.el (and it does what I described 30 seconds ago, but
better :-) )

Iʼm not sure what the use of showing the keymaps is though. Theyʼre an
internal implementation detail, showing the potential bindings would
be more useful.

(defun describe-repeat ()
  "Describe repeatable commands and keymaps."
  (interactive)
  (help-setup-xref (list #'describe-repeat)
                   (called-interactively-p 'interactive))
  (let ((keymaps nil))
    (all-completions
     "" obarray (lambda (s)
                  (and (commandp s)
                       (get s 'repeat-map)
                       (push s (alist-get (get s 'repeat-map) keymaps)))))
    (with-help-window (help-buffer)
      (with-current-buffer standard-output
        (princ "This is a list of repeatable keymaps and commands.\n\n")

        (dolist (keymap (sort keymaps (lambda (a b) (string-lessp (car a) (car b)))))
          (princ (format-message "`%s' keymap is repeatable by these commands:\n"
                                 (car keymap)))
          (dolist (command (sort (cdr keymap) 'string-lessp))
            (princ (format-message " `%s'\n" command)))
          (princ "\n"))))))


Robert
-- 

bug#49265: [External] : bug#49265: 28.0.50; repeat mode feature request

[Drew Adams]

>     >> > I thought the question was whether Emacs automatically,
>     >> > or already in some way, provides some a way of
>     >> > determining (e.g. using Lisp code) whether a given
>     >> > command is repeatable (i.e., by just holding down a key
>     >> > that it's bound to).
>     >> >
>     >> > If that's the question then I think the answer is no.
>     >> > (Is that right?)
>     >>
>     >> The request was to create a new command that lists all
>     >> repeatable commands and keymaps.
> 
>     Drew> Which amounts to the same thing: determining whether
>     Drew> a given command is repeatable.  I don't think Emacs has
>     Drew> a way of determining that.  (It would even seem to be
>     Drew> undecidable...)
> 
> (mapatoms (lambda (sym)
>             (and (commandp sym)
>                  (get sym 'repeat-map)
>                  (message "repeatable %s" sym))))
> 
> gets you the potentially repeatable commands. Whether theyʼre
> actually repeatable depends on whether 'repeat-mode' is active.

I see.  But `repeat-map' and the code supporting the code
you show are not in any Emacs release.  They're not even
in Emacs 28 code from earlier this year.  They're in the
repeat.el I just downloaded from Master - OK.

But it's possible to define repeatable commands that
don't use repeat.el at all.

I think my general statement stands, that it's impossible
for this check to be fully accurate/complete.  At the
very least, its doc should make clear that it makes sense
only (1) starting with Emacs 28 and (2) only for repeatable
commands defined using repeat.el code.

(Of course, for Emacs 28 we need not say it's only for
Emacs 28 or later.  But some communication of that fact
would help users.)

>   Drew> (Though I don't know what you might mean by "and keymaps".
>   Drew> Repeatable keymaps?)
> 
> Bindings to repeatable commands maybe?

Maybe; who knows?  A binding to a command is not a
keymap, and vice versa.  (A key can be bound to a
keymap, however.)

bug#49265: [External] : bug#49265: 28.0.50; repeat mode feature request

[Drew Adams]

>   >> Now a new command named 'describe-repeat' was pushed to master.
>   >> Please try it.  If everything is right, this request could be
>   >> closed.
> 
>   Drew> Where was it added to master?  I downloaded the latest
>   Drew> help-fns.el, and I don't see it there.  Could you perhaps
>   Drew> post the code here?  Could you perhaps say, here, just
>   Drew> what it does?  Thx.
> 
> Itʼs in repeat.el (and it does what I described 30 seconds ago, but
> better :-) )
> 
> Iʼm not sure what the use of showing the keymaps is though. Theyʼre an
> internal implementation detail, showing the potential bindings would
> be more useful.
> 
> (defun describe-repeat ()
>   "Describe repeatable commands and keymaps."

Again, that's wrong.  "Repeatable keymaps" doesn't
mean anything (to me, anyway).  If you mean describe
the keys bound to repeatable commands then say that.

>   (interactive)
>   (help-setup-xref (list #'describe-repeat)
>                    (called-interactively-p 'interactive))
>   (let ((keymaps nil))
>     (all-completions
>      "" obarray (lambda (s)
>                   (and (commandp s)
>                        (get s 'repeat-map)
>                        (push s (alist-get
>                                  (get s 'repeat-map)
>                                  keymaps)))))
>     (with-help-window (help-buffer)
>       (with-current-buffer standard-output
>         (princ "This is a list of repeatable keymaps and commands.\n\n")

Again, "repeatable keymaps" is a misnomer.

>         (dolist (keymap (sort keymaps (lambda (a b) (string-lessp (car a)
> (car b)))))
>           (princ (format-message "`%s' keymap is repeatable by these
> commands:\n"

How is a _keymap_ "repeatable"?

bug#49265: [External] : bug#49265: 28.0.50; repeat mode feature request

[Juri Linkov]

> Iʼm not sure what the use of showing the keymaps is though. Theyʼre an
> internal implementation detail, showing the potential bindings would
> be more useful.

I agree, keybindings could be added as well.

bug#49265: [External] : bug#49265: 28.0.50; repeat mode feature request

[Juri Linkov]

>>   "Describe repeatable commands and keymaps."
>
> Again, that's wrong.  "Repeatable keymaps" doesn't
> mean anything (to me, anyway).  If you mean describe
> the keys bound to repeatable commands then say that.

Repeatable keymaps are keymaps with repeatable commands.

bug#49265: [External] : bug#49265: 28.0.50; repeat mode feature request

[Drew Adams]

> >>   "Describe repeatable commands and keymaps."
> >
> > Again, that's wrong.  "Repeatable keymaps" doesn't
> > mean anything (to me, anyway).  If you mean describe
> > the keys bound to repeatable commands then say that.
> 
> Repeatable keymaps are keymaps with repeatable commands.

Why?  Do we define that term anywhere?  A keymap is,
itself, not something that can be repeated in any way.

And what constitutes a keymap with repeatable commands?
Is a keymap with one repeatable command repeatable, even
if it also has bindings for commands that are not
repeatable?

What's the use in listing such keymaps?  And what does
it mean to describe them?  `describe-keymap' lists the
bindings of a keymap.  But your reply to Robert, saying
that "keybindings could be added as well", suggests that
you mean something different by describing a keymap than
what `describe-keymap' does, which is to list a keymap's
key bindings.

bug#49265: [External] : bug#49265: 28.0.50; repeat mode feature request

[Juri Linkov]

>> >>   "Describe repeatable commands and keymaps."
>> >
>> > Again, that's wrong.  "Repeatable keymaps" doesn't
>> > mean anything (to me, anyway).  If you mean describe
>> > the keys bound to repeatable commands then say that.
>
> And what constitutes a keymap with repeatable commands?
> Is a keymap with one repeatable command repeatable, even
> if it also has bindings for commands that are not
> repeatable?

I don't see where is "Repeatable keymaps" used?
The above docstring is

  "Describe repeatable commands and keymaps."

i.e. "repeatable commands" and also their "keymaps".

bug#49265: [External] : bug#49265: 28.0.50; repeat mode feature request

[Drew Adams]

> >> >>   "Describe repeatable commands and keymaps."
> >> >
> >> > Again, that's wrong.  "Repeatable keymaps" doesn't
> >> > mean anything (to me, anyway).  If you mean describe
> >> > the keys bound to repeatable commands then say that.
> >
> > And what constitutes a keymap with repeatable commands?
> > Is a keymap with one repeatable command repeatable, even
> > if it also has bindings for commands that are not
> > repeatable?
> 
> I don't see where is "Repeatable keymaps" used?
> The above docstring is
> 
>   "Describe repeatable commands and keymaps."
> 
> i.e. "repeatable commands" and also their "keymaps".

The text is ambiguous.  If that's what you mean,
please reword it.  For example, this unambiguously
applies "repeatable" only to "commands":

  Describe keymaps and repeatable commands.

But is "describe keymaps" appropriate?  Or are the
keymaps that are described here only certain ones?

bug#49265: [External] : bug#49265: 28.0.50; repeat mode feature request

[Robert Pluim]

>>>>> On Sun, 4 Jul 2021 21:09:24 +0000, Drew Adams <drew.adams@oracle.com> said:

    >> >> >>   "Describe repeatable commands and keymaps."
    >> >> >
    >> >> > Again, that's wrong.  "Repeatable keymaps" doesn't
    >> >> > mean anything (to me, anyway).  If you mean describe
    >> >> > the keys bound to repeatable commands then say that.
    >> >
    >> > And what constitutes a keymap with repeatable commands?
    >> > Is a keymap with one repeatable command repeatable, even
    >> > if it also has bindings for commands that are not
    >> > repeatable?
    >> 
    >> I don't see where is "Repeatable keymaps" used?
    >> The above docstring is
    >> 
    >> "Describe repeatable commands and keymaps."
    >> 
    >> i.e. "repeatable commands" and also their "keymaps".

    Drew> The text is ambiguous.  If that's what you mean,
    Drew> please reword it.  For example, this unambiguously
    Drew> applies "repeatable" only to "commands":

    Drew>   Describe keymaps and repeatable commands.

    Drew> But is "describe keymaps" appropriate?  Or are the
    Drew> keymaps that are described here only certain ones?

It only describes keymaps that have bindings to repeatable commands in
them. I still think we should not mention keymaps at all, only bindings.

Robert
-- 

bug#49265: [External] : bug#49265: 28.0.50; repeat mode feature request

[Drew Adams]

>     Drew> The text is ambiguous.  If that's what you mean,
>     Drew> please reword it.  For example, this unambiguously
>     Drew> applies "repeatable" only to "commands":
> 
>     Drew>   Describe keymaps and repeatable commands.
> 
>     Drew> But is "describe keymaps" appropriate?  Or are the
>     Drew> keymaps that are described here only certain ones?
> 
> It only describes keymaps that have bindings to
> repeatable commands in them.

Yes, that's what I understood.  So the proposed doc
misleads.  (And it doesn't describe all such keymaps,
because it doesn't consider all repeatable commands -
see next.)

> I still think we should not mention keymaps at all, only bindings.

I agree.

And as I mentioned earlier, it should be made clear
in the doc that "repeatable" here means only commands
defined using `repeat.el'.

There are other ways to define repeatable commands,
and those commands aren't represented by this
describe feature.

(It's not even clear to me that this feature really
helps users.  A naming convention (combined with
`commandp', of course) makes more sense to me.)

bug#49265: [External] : bug#49265: 28.0.50; repeat mode feature request

[Juri Linkov]

>     Drew>   Describe keymaps and repeatable commands.
>
>     Drew> But is "describe keymaps" appropriate?  Or are the
>     Drew> keymaps that are described here only certain ones?
>
> It only describes keymaps that have bindings to repeatable commands in
> them. I still think we should not mention keymaps at all, only bindings.

I checked again, and it seems everything is already correct:
currently the Help buffer groups repeatable commands
by the keymap that is activated in post-command-hook.

Then keymap names have links to the Help buffer that
shows information about the keymap: all its keybindings, etc.
using `describe-keymap'.
Also every command has a link to the Help buffer
that describes that command.

Indeed, there is text "keymap is repeatable by these commands"
in the sense that the keymap is activated for repetition
in post-command-hook.

Maybe Drew could suggest a better text?

One thing I see that could be improved is a too ambiguous name `describe-repeat'.
I propose to rename this command to `describe-repeat-mode'.

bug#49265: [External] : bug#49265: 28.0.50; repeat mode feature request

[Drew Adams]

> Indeed, there is text "keymap is repeatable by these commands"
> in the sense that the keymap is activated for repetition
> in post-command-hook.

I don't think the particular meaning you claim there
is suggested by that wording, i.e., that readers will
understand such an esoteric meaning of "repeatable"
as applied to a keymap.

> Maybe Drew could suggest a better text?

My suggestion would be to not say anything about the
keymaps involved.  What's the purpose in trying to do
that?  What additional help do you mean to provide
by it?

> One thing I see that could be improved is a too ambiguous
> name `describe-repeat'.

The problem isn't ambiguity, IMO.  It's that the name
and the description are overly general.  Only some
repeatable commands are covered by this (apparently).

> I propose to rename this command to `describe-repeat-mode'.

That sounds like it's a command that describes some
mode called `repeat-mode'.

I don't have a great suggestion for the name.  IIUC,
the command lists bindings of commands that are
defined using function `repeat'.

Maybe `list-repeat-commands', as OP suggested.  Or
maybe `describe-repeat-bindings', as it is bindings
that are listed/described.  I don't think it's
about describing the commands - their bindings are
listed.

(`repeat' vs `repeatable', since it's limited to
commands defined using repeat.el.)  

bug#49265: [External] : bug#49265: 28.0.50; repeat mode feature request

[Juri Linkov]

tags 49265 fixed
close 49265 28.0.50
thanks

>> Maybe Drew could suggest a better text?
>
> My suggestion would be to not say anything about the
> keymaps involved.  What's the purpose in trying to do
> that?  What additional help do you mean to provide
> by it?

But the keymaps are the essential part of this feature.

>> I propose to rename this command to `describe-repeat-mode'.
>
> That sounds like it's a command that describes some
> mode called `repeat-mode'.

This is correct, the mode is called `repeat-mode'.

> I don't have a great suggestion for the name.  IIUC,
> the command lists bindings of commands that are
> defined using function `repeat'.
>
> Maybe `list-repeat-commands', as OP suggested.  Or
> maybe `describe-repeat-bindings', as it is bindings
> that are listed/described.  I don't think it's
> about describing the commands - their bindings are
> listed.

Thanks for the suggestion, this helped to rename it
to the most proper name `describe-repeat-maps',
because this feature is based on `repeat-map' props.
Also did my best to fix text strings.

bug#49265: [External] : bug#49265: 28.0.50; repeat mode feature request

[Drew Adams]

> >> Maybe Drew could suggest a better text?
> >
> > My suggestion would be to not say anything about the
> > keymaps involved.  What's the purpose in trying to do
> > that?  What additional help do you mean to provide
> > by it?
> 
> But the keymaps are the essential part of this feature.

Sorry, I haven't understood that.  How so?
What does the doc/help tell us about their
importance for "this feature"?

> >> I propose to rename this command to `describe-repeat-mode'.
> >
> > That sounds like it's a command that describes some
> > mode called `repeat-mode'.
> 
> This is correct, the mode is called `repeat-mode'.

I see.  I don't see that in Emacs releases.
Presumably it is new for Emacs 28.  So does
this command describe the mode?  Or does it
just list key bindings (as `describe-keymap'
does)?

> > I don't have a great suggestion for the name.  IIUC,
> > the command lists bindings of commands that are
> > defined using function `repeat'.
> >
> > Maybe `list-repeat-commands', as OP suggested.  Or
> > maybe `describe-repeat-bindings', as it is bindings
> > that are listed/described.  I don't think it's
> > about describing the commands - their bindings are
> > listed.
> 
> Thanks for the suggestion, this helped to rename it
> to the most proper name `describe-repeat-maps',
> because this feature is based on `repeat-map' props.
> Also did my best to fix text strings.

So are there multiple repeat maps?  And what
about what you hinted above - that this command
describes `repeat-mode'?  Is there perhaps a
`repeat-mode-map', and is this about that?

Not clear to me (not that that matters).

Re: bug#49265: [External] : bug#49265: 28.0.50; repeat mode feature request

[Robert Pluim]

>>>>> On Sat, 23 Oct 2021 21:31:06 +0300, Juri Linkov <juri@linkov.net> said:

    >> Something like this for master? emacs-28 would be nice, but this is
    >> not a bugfix.
    >> 
    >> +            (princ (format-message " `%s' (bound to %s)\n" command
    >> +                                   (mapconcat
    >> +                                    (lambda (key)
    >> +                                      (format "'%s'" (key-description key)))
    >> + (where-is-internal command (symbol-value (car keymap)))
    >> +                                    " ,"))))

    Juri> Thanks, I tried this, but it shows global keybindings,
    Juri> not shorter repeatable keybindings from the repeat-map.
    Juri> For example,

    Juri>   ‘undo-repeat-map’ keymap is repeatable by these commands:
    Juri>    ‘undo’ (bound to 'u' ,'C-_' ,'<undo>' ,'C-/' ,'C-x u' ,'<menu-bar> <edit> <undo>')

    Juri> I expected that it will show only 'u' from ‘undo-repeat-map’.

Since somebody has liberally used 'defalias' in tab-bar.el, it becomes
this :-)

diff --git a/lisp/repeat.el b/lisp/repeat.el
index ac08952eaa..931615ed4c 100644
--- a/lisp/repeat.el
+++ b/lisp/repeat.el
@@ -516,7 +516,12 @@ describe-repeat-maps
           (princ (format-message "`%s' keymap is repeatable by these commands:\n"
                                  (car keymap)))
           (dolist (command (sort (cdr keymap) 'string-lessp))
-            (princ (format-message " `%s'\n" command)))
+            (let* ((info (help-fns--analyze-function command))
+                   (map (list (symbol-value (car keymap))))
+                   (desc (key-description
+                          (or (where-is-internal command map t)
+                              (where-is-internal (nth 3 info) map t)))))
+              (princ (format-message " `%s' (bound to '%s')\n" command desc))))
           (princ "\n"))))))
 
 (provide 'repeat)

Note that this doesnʼt find the bindings for 'O' in
other-window-repeat-map nor 'M' in tab-bar-move-repeat map, because
the commands theyʼre bound to donʼt have the 'repeat-map' property,
which we might want to fix.

Juri> PS: the long lines could be refilled, but this is a minor problem.

The lines should be short enough with the above.

Robert
-- 

Re: bug#49265: [External] : bug#49265: 28.0.50; repeat mode feature request

[Juri Linkov]

>     >> Something like this for master? emacs-28 would be nice, but this is
>     >> not a bugfix.
>     >>
>     >> +            (princ (format-message " `%s' (bound to %s)\n" command
>     >> +                                   (mapconcat
>     >> +                                    (lambda (key)
>     >> +                                      (format "'%s'" (key-description key)))
>     >> + (where-is-internal command (symbol-value (car keymap)))
>     >> +                                    " ,"))))
>
>     Juri> Thanks, I tried this, but it shows global keybindings,
>     Juri> not shorter repeatable keybindings from the repeat-map.
>     Juri> For example,
>
>     Juri>   ‘undo-repeat-map’ keymap is repeatable by these commands:
>     Juri>    ‘undo’ (bound to 'u' ,'C-_' ,'<undo>' ,'C-/' ,'C-x u' ,'<menu-bar> <edit> <undo>')
>
>     Juri> I expected that it will show only 'u' from ‘undo-repeat-map’.
>
> Since somebody has liberally used 'defalias' in tab-bar.el, it becomes
> this :-)

I fixed aliases for tab-bar.el some time ago, but was busy with fixing
other problems in repeat.el, so sorry for not pushing the fixes earlier.
Now I'll push them together with the unfinished test suite for repeat.el  :-)

> diff --git a/lisp/repeat.el b/lisp/repeat.el
> index ac08952eaa..931615ed4c 100644
> --- a/lisp/repeat.el
> +++ b/lisp/repeat.el
> @@ -516,7 +516,12 @@ describe-repeat-maps
>            (princ (format-message "`%s' keymap is repeatable by these commands:\n"
>                                   (car keymap)))
>            (dolist (command (sort (cdr keymap) 'string-lessp))
> -            (princ (format-message " `%s'\n" command)))
> +            (let* ((info (help-fns--analyze-function command))
> +                   (map (list (symbol-value (car keymap))))
> +                   (desc (key-description
> +                          (or (where-is-internal command map t)
> +                              (where-is-internal (nth 3 info) map t)))))
> +              (princ (format-message " `%s' (bound to '%s')\n" command desc))))
>            (princ "\n"))))))

Thanks, I tried this out, and everything looks nice.
I could push this in the next few days after trying to solve
remaining problems:

> Note that this doesnʼt find the bindings for 'O' in
> other-window-repeat-map nor 'M' in tab-bar-move-repeat map, because
> the commands theyʼre bound to donʼt have the 'repeat-map' property,
> which we might want to fix.

Maybe it would be sufficient just to say that a key is bound to a lambda?

> Juri> PS: the long lines could be refilled, but this is a minor problem.
>
> The lines should be short enough with the above.

I agree, a long repeat-map is too unusual.

Re: bug#49265: [External] : bug#49265: 28.0.50; repeat mode feature request

[Robert Pluim]

>>>>> On Sun, 24 Oct 2021 22:12:55 +0300, Juri Linkov <juri@linkov.net> said:
    Juri> I fixed aliases for tab-bar.el some time ago, but was busy with fixing
    Juri> other problems in repeat.el, so sorry for not pushing the fixes earlier.
    Juri> Now I'll push them together with the unfinished test suite for repeat.el  :-)

    >> diff --git a/lisp/repeat.el b/lisp/repeat.el
    >> index ac08952eaa..931615ed4c 100644
    >> --- a/lisp/repeat.el
    >> +++ b/lisp/repeat.el
    >> @@ -516,7 +516,12 @@ describe-repeat-maps
    >> (princ (format-message "`%s' keymap is repeatable by these commands:\n"
    >> (car keymap)))
    >> (dolist (command (sort (cdr keymap) 'string-lessp))
    >> -            (princ (format-message " `%s'\n" command)))
    >> +            (let* ((info (help-fns--analyze-function command))
    >> +                   (map (list (symbol-value (car keymap))))
    >> +                   (desc (key-description
    >> +                          (or (where-is-internal command map t)
    >> +                              (where-is-internal (nth 3 info) map t)))))
    >> +              (princ (format-message " `%s' (bound to '%s')\n" command desc))))
    >> (princ "\n"))))))

    Juri> Thanks, I tried this out, and everything looks nice.
    Juri> I could push this in the next few days after trying to solve
    Juri> remaining problems:

Thereʼs no rush

    >> Note that this doesnʼt find the bindings for 'O' in
    >> other-window-repeat-map nor 'M' in tab-bar-move-repeat map, because
    >> the commands theyʼre bound to donʼt have the 'repeat-map' property,
    >> which we might want to fix.

    Juri> Maybe it would be sufficient just to say that a key is bound to a lambda?

Iʼd rather have a real function name to refer to than a lambda, but
itʼs up to you, I guess.

Robert
-- 

Re: bug#49265: [External] : bug#49265: 28.0.50; repeat mode feature request

[Juri Linkov]

>     >> Note that this doesnʼt find the bindings for 'O' in
>     >> other-window-repeat-map nor 'M' in tab-bar-move-repeat map, because
>     >> the commands theyʼre bound to donʼt have the 'repeat-map' property,
>     >> which we might want to fix.
>
>     Juri> Maybe it would be sufficient just to say that a key is bound to a lambda?
>
> Iʼd rather have a real function name to refer to than a lambda, but
> itʼs up to you, I guess.

But this means adding a new command with a name e.g. 'other-window-backward'
that will cycle windows in the opposite direction.

Re: bug#49265: [External] : bug#49265: 28.0.50; repeat mode feature request

[Robert Pluim]

>>>>> On Mon, 25 Oct 2021 10:41:44 +0300, Juri Linkov <juri@linkov.net> said:

    >> >> Note that this doesnʼt find the bindings for 'O' in
    >> >> other-window-repeat-map nor 'M' in tab-bar-move-repeat map, because
    >> >> the commands theyʼre bound to donʼt have the 'repeat-map' property,
    >> >> which we might want to fix.
    >> 
    Juri> Maybe it would be sufficient just to say that a key is
    >> bound to a lambda?
    >> 
    >> Iʼd rather have a real function name to refer to than a lambda, but
    >> itʼs up to you, I guess.

    Juri> But this means adding a new command with a name e.g. 'other-window-backward'
    Juri> that will cycle windows in the opposite direction.

As I said: itʼs up to you.

BTW, I tried using 'substitute-command-keys' to do this, since itʼs
more elegant, but it gave an unusual result for undo:

    (substitute-command-keys "\\<undo-repeat-map>\\[undo]")
    =>#("C-x u" 0 5
      (font-lock-face help-key-binding face help-key-binding))

which is the global binding, not the repeat-map binding. Any ideas?

Robert
-- 

Re: bug#49265: [External] : bug#49265: 28.0.50; repeat mode feature request

[Stefan Kangas]

Robert Pluim <rpluim@gmail.com> writes:

> BTW, I tried using 'substitute-command-keys' to do this, since itʼs
> more elegant, but it gave an unusual result for undo:
>
>     (substitute-command-keys "\\<undo-repeat-map>\\[undo]")
>     =>#("C-x u" 0 5
>       (font-lock-face help-key-binding face help-key-binding))

That looks like a bug to me.

Re: bug#49265: [External] : bug#49265: 28.0.50; repeat mode feature request

[Robert Pluim]

>>>>> On Mon, 25 Oct 2021 11:21:50 +0200, Stefan Kangas <stefan@marxist.se> said:

    Stefan> Robert Pluim <rpluim@gmail.com> writes:
    >> BTW, I tried using 'substitute-command-keys' to do this, since itʼs
    >> more elegant, but it gave an unusual result for undo:
    >> 
    >> (substitute-command-keys "\\<undo-repeat-map>\\[undo]")
    >> =>#("C-x u" 0 5
    >> (font-lock-face help-key-binding face help-key-binding))

    Stefan> That looks like a bug to me.

Reported as bug#51384

Robert
-- 

Re: bug#49265: [External] : bug#49265: 28.0.50; repeat mode feature request

[Andreas Schwab]

On Okt 25 2021, Stefan Kangas wrote:

> Robert Pluim <rpluim@gmail.com> writes:
>
>> BTW, I tried using 'substitute-command-keys' to do this, since itʼs
>> more elegant, but it gave an unusual result for undo:
>>
>>     (substitute-command-keys "\\<undo-repeat-map>\\[undo]")
>>     =>#("C-x u" 0 5
>>       (font-lock-face help-key-binding face help-key-binding))
>
> That looks like a bug to me.

This is due to :advertised-binding.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: bug#49265: [External] : bug#49265: 28.0.50; repeat mode feature request

[Juri Linkov]

>>> BTW, I tried using 'substitute-command-keys' to do this, since itʼs
>>> more elegant, but it gave an unusual result for undo:
>>>
>>>     (substitute-command-keys "\\<undo-repeat-map>\\[undo]")
>>>     =>#("C-x u" 0 5
>>>       (font-lock-face help-key-binding face help-key-binding))
>>
>> That looks like a bug to me.
>
> This is due to :advertised-binding.

Maybe 'where-is-internal' should check if the map contains
the advertised binding, only then return it?

Re: bug#49265: [External] : bug#49265: 28.0.50; repeat mode feature request

[Juri Linkov]

>> But this means adding a new command with a name e.g.
>> 'other-window-backward' that will cycle windows in the opposite direction.
>
> As I said: itʼs up to you.

I think this command could be added only when someone will request it as
a standalone command useful on its own, without connection to repeat-mode.

Re: bug#49265: [External] : bug#49265: 28.0.50; repeat mode feature request

[Stefan Monnier]

Juri Linkov [2021-10-25 20:54:03] wrote:
>>>> BTW, I tried using 'substitute-command-keys' to do this, since itʼs
>>>> more elegant, but it gave an unusual result for undo:
>>>>
>>>>     (substitute-command-keys "\\<undo-repeat-map>\\[undo]")
>>>>     =>#("C-x u" 0 5
>>>>       (font-lock-face help-key-binding face help-key-binding))
>>>
>>> That looks like a bug to me.
>>
>> This is due to :advertised-binding.
>
> Maybe 'where-is-internal' should check if the map contains
> the advertised binding, only then return it?

The \\<...> doesn't override all other maps, so the `undo` command is
still found to be bound to `C-x u` in the global map.

But I agree that maybe `where-is-internal` could be told here to give
precedence to bindings found in the \\<...> map.


        Stefan

Re: bug#49265: [External] : bug#49265: 28.0.50; repeat mode feature request

[Robert Pluim]

>>>>> On Mon, 25 Oct 2021 14:08:42 -0400, Stefan Monnier <monnier@iro.umontreal.ca> said:

    Stefan> Juri Linkov [2021-10-25 20:54:03] wrote:
    >>>>> BTW, I tried using 'substitute-command-keys' to do this, since itʼs
    >>>>> more elegant, but it gave an unusual result for undo:
    >>>>> 
    >>>>> (substitute-command-keys "\\<undo-repeat-map>\\[undo]")
    >>>>> =>#("C-x u" 0 5
    >>>>> (font-lock-face help-key-binding face help-key-binding))
    >>>> 
    >>>> That looks like a bug to me.
    >>> 
    >>> This is due to :advertised-binding.
    >> 
    >> Maybe 'where-is-internal' should check if the map contains
    >> the advertised binding, only then return it?

    Stefan> The \\<...> doesn't override all other maps, so the `undo` command is
    Stefan> still found to be bound to `C-x u` in the global map.

Right. I think it should look *only* in the specified map, otherwise
what's the point of specifying it?

    Stefan> But I agree that maybe `where-is-internal` could be told here to give
    Stefan> precedence to bindings found in the \\<...> map.

`where-is-internal' is not the issue. If you pass it (list keymap) it
will look only in 'keymap'. But substitute-command-keys passes it
'keymap', which allows it to look in the global map as well.

Perhaps something like this?

diff --git a/lisp/help.el b/lisp/help.el
index 7e2e492a36..38ecde7f8f 100644
--- a/lisp/help.el
+++ b/lisp/help.el
@@ -1124,7 +1124,9 @@ substitute-command-keys
                 (delete-char 2)
                 (let* ((fun (intern (buffer-substring (point) (1- end-point))))
                        (key (with-current-buffer orig-buf
-                              (where-is-internal fun keymap t))))
+                              (or
+                               (where-is-internal fun (list keymap) t)
+                               (where-is-internal fun (list global-map) t)))))
                   ;; If this a command remap, we need to follow it.
                   (when (and (vectorp key)
                              (> (length key) 1)
@@ -1132,7 +1134,9 @@ substitute-command-keys
                              (symbolp (aref key 1)))
                     (setq fun (aref key 1))
                     (setq key (with-current-buffer orig-buf
-                                (where-is-internal fun keymap t))))
+                                (or
+                                 (where-is-internal fun (list keymap) t)
+                                 (where-is-internal fun (list global-map) t)))))
                   (if (not key)
                       ;; Function is not on any key.
                       (let ((op (point)))


Otherwise, extending 'substitute-command-keys' to allow '\(map)' to
mean "look only in map" is fairly trivial as well, but I donʼt see why
weʼd want to add more syntax when we could fix the existing one.

Robert
-- 

Re: bug#49265: [External] : bug#49265: 28.0.50; repeat mode feature request

[Stefan Monnier]

>     Stefan> The \\<...> doesn't override all other maps, so the `undo` command is
>     Stefan> still found to be bound to `C-x u` in the global map.
> Right. I think it should look *only* in the specified map, otherwise
> what's the point of specifying it?

The common case is to specify the keymap that will likely be active when
the command is used.

Maybe you're right that we shouldn't look elsewhere, but I'd be
surprised if there aren't docstrings that rely on the current behavior.

>     Stefan> But I agree that maybe `where-is-internal` could be told
>     Stefan> here to give precedence to bindings found in the
>     Stefan> \\<...> map.
>
> `where-is-internal' is not the issue. If you pass it (list keymap) it
> will look only in 'keymap'. But substitute-command-keys passes it
> 'keymap', which allows it to look in the global map as well.
>
> Perhaps something like this?

Sounds about right, tho it disregards other keymaps than `keymap` and
`global-map`.  Maybe we should do

    (or (where-is-internal fun (list keymap) t)
        (where-is-internal fun nil t))

instead to avoid this problem.


        Stefan

Re: bug#49265: [External] : bug#49265: 28.0.50; repeat mode feature request

[Robert Pluim]

>>>>> On Mon, 25 Oct 2021 16:57:19 -0400, Stefan Monnier <monnier@iro.umontreal.ca> said:

    Stefan> The \\<...> doesn't override all other maps, so the `undo` command is
    Stefan> still found to be bound to `C-x u` in the global map.
    >> Right. I think it should look *only* in the specified map, otherwise
    >> what's the point of specifying it?

    Stefan> The common case is to specify the keymap that will likely be active when
    Stefan> the command is used.

OK, so I guess that pleads for a fallback to the current behaviour.

    Stefan> Maybe you're right that we shouldn't look elsewhere, but I'd be
    Stefan> surprised if there aren't docstrings that rely on the current behavior.

That may be true, and I canʼt think of an easy way of finding them.

    Stefan> But I agree that maybe `where-is-internal` could be told
    Stefan> here to give precedence to bindings found in the
    Stefan> \\<...> map.
    >> 
    >> `where-is-internal' is not the issue. If you pass it (list keymap) it
    >> will look only in 'keymap'. But substitute-command-keys passes it
    >> 'keymap', which allows it to look in the global map as well.
    >> 
    >> Perhaps something like this?

    Stefan> Sounds about right, tho it disregards other keymaps than `keymap` and
    Stefan> `global-map`.  Maybe we should do

    Stefan>     (or (where-is-internal fun (list keymap) t)
    Stefan>         (where-is-internal fun nil t))

    Stefan> instead to avoid this problem.

I think the minimal change from the current behaviour would be this,
since 'keymap' starts out as 'overriding-local-map', but then can get
set to 'nil' or a specific keymap based on the contents of the string.

Or we could add an optional argument to 'substitute-command-keys' to
mean 'only look in MAPVAR'.

diff --git a/lisp/help.el b/lisp/help.el
index 9666ef9805..55e58e20e5 100644
--- a/lisp/help.el
+++ b/lisp/help.el
@@ -1124,7 +1124,9 @@ substitute-command-keys
                 (delete-char 2)
                 (let* ((fun (intern (buffer-substring (point) (1- end-point))))
                        (key (with-current-buffer orig-buf
-                              (where-is-internal fun keymap t))))
+                              (or
+                               (where-is-internal fun (list keymap) t)
+                               (where-is-internal fun keymap t)))))
                   ;; If this a command remap, we need to follow it.
                   (when (and (vectorp key)
                              (> (length key) 1)
@@ -1132,7 +1134,9 @@ substitute-command-keys
                              (symbolp (aref key 1)))
                     (setq fun (aref key 1))
                     (setq key (with-current-buffer orig-buf
-                                (where-is-internal fun keymap t))))
+                                (or
+                                 (where-is-internal fun (list keymap) t)
+                                 (where-is-internal fun keymap t)))))
                   (if (not key)
                       ;; Function is not on any key.
                       (let ((op (point)))

Robert
-- 

Re: bug#49265: [External] : bug#49265: 28.0.50; repeat mode feature request

[Robert Pluim]

>>>>> On Tue, 26 Oct 2021 12:06:28 +0200, Robert Pluim <rpluim@gmail.com> said:

    Robert> I think the minimal change from the current behaviour would be this,
    Robert> since 'keymap' starts out as 'overriding-local-map', but then can get
    Robert> set to 'nil' or a specific keymap based on the contents of the string.

Actually, no. Thatʼs a good way to break your Emacs. Back to the
drawing board.

Robert
-- 

Re: bug#49265: [External] : bug#49265: 28.0.50; repeat mode feature request

[Stefan Monnier]

> -                              (where-is-internal fun keymap t))))
> +                              (or
> +                               (where-is-internal fun (list keymap) t)
> +                               (where-is-internal fun keymap t)))))

I think this is right, except you need to check `(if keymap` before
using `(list keymap)`.


        Stefan "based on your subsequent statement that it breaks Emacs ;-)"

Re: bug#49265: [External] : bug#49265: 28.0.50; repeat mode feature request

[Robert Pluim]

>>>>> On Tue, 26 Oct 2021 08:39:48 -0400, Stefan Monnier <monnier@iro.umontreal.ca> said:

    >> -                              (where-is-internal fun keymap t))))
    >> +                              (or
    >> +                               (where-is-internal fun (list keymap) t)
    >> +                               (where-is-internal fun keymap t)))))

    Stefan> I think this is right, except you need to check `(if keymap` before
    Stefan> using `(list keymap)`.

Yes

    Stefan>         Stefan "based on your subsequent statement that it breaks Emacs ;-)"

Well, only if you byte-compile stuff. Interactively it works fine :-)

Robert
-- 

bug#49265: [External] : bug#49265: 28.0.50; repeat mode feature request

[Juri Linkov]

[Here is a link to the previous discussion:
https://lists.gnu.org/archive/html/emacs-devel/2021-10/msg01730.html ]

> >> Thanks, I tried this out, and everything looks nice.
> >> I could push this in the next few days after trying to solve
> >> remaining problems:

> Thereʼs no rush

Sorry for the delay.  Now your patch is pushed.

bug#49265: [External] : bug#49265: 28.0.50; repeat mode feature request

[Juri Linkov]

> [Here is a link to the previous discussion:
> https://lists.gnu.org/archive/html/emacs-devel/2021-10/msg01730.html ]
>
>> >> Thanks, I tried this out, and everything looks nice.
>> >> I could push this in the next few days after trying to solve
>> >> remaining problems:
>
>> Thereʼs no rush
>
> Sorry for the delay.  Now your patch is pushed.

I noticed one shortcoming: describe-repeat-maps prints
only one keybinding for every command.  But sometimes
the same command is bound to more than 1 key in the same keymap.

bug#49265: [External] : bug#49265: 28.0.50; repeat mode feature request

[Juri Linkov]

Hi Robert,

What do you think about using `map-keymap' in `describe-repeat-maps'
to fix the following problem?  Could it help to print all keys
bound to the same command?

> I noticed one shortcoming: describe-repeat-maps prints
> only one keybinding for every command.  But sometimes
> the same command is bound to more than 1 key in the same keymap.

bug#49265: [External] : bug#49265: 28.0.50; repeat mode feature request

[Robert Pluim]

>>>>> On Wed, 17 Nov 2021 19:01:37 +0200, Juri Linkov <juri@linkov.net> said:

    Juri> Hi Robert,
    Juri> What do you think about using `map-keymap' in `describe-repeat-maps'
    Juri> to fix the following problem?  Could it help to print all keys
    Juri> bound to the same command?

    >> I noticed one shortcoming: describe-repeat-maps prints
    >> only one keybinding for every command.  But sometimes
    >> the same command is bound to more than 1 key in the same keymap.

You donʼt need `map-keymap' for that:

diff --git a/lisp/repeat.el b/lisp/repeat.el
index 45201ad1aa..5458ff30e5 100644
--- a/lisp/repeat.el
+++ b/lisp/repeat.el
@@ -533,10 +533,11 @@ describe-repeat-maps
           (dolist (command (sort (cdr keymap) 'string-lessp))
             (let* ((info (help-fns--analyze-function command))
                    (map (list (symbol-value (car keymap))))
-                   (desc (key-description
-                          (or (where-is-internal command map t)
-                              (where-is-internal (nth 3 info) map t)))))
-              (princ (format-message " `%s' (bound to '%s')\n" command desc))))
+                   (desc (mapconcat (lambda (key)
+                                      (format "'%s'" (key-description key)))
+                                    (or (where-is-internal command map)
+                                        (where-is-internal (nth 3 info) map)) ", ")))
+              (princ (format-message " `%s' (bound to %s)\n" command desc))))
           (princ "\n"))))))
 
 (provide 'repeat)

bug#49265: [External] : bug#49265: 28.0.50; repeat mode feature request

[Juri Linkov]

>     Juri> Hi Robert,
>     Juri> What do you think about using `map-keymap' in `describe-repeat-maps'
>     Juri> to fix the following problem?  Could it help to print all keys
>     Juri> bound to the same command?
>
>     >> I noticed one shortcoming: describe-repeat-maps prints
>     >> only one keybinding for every command.  But sometimes
>     >> the same command is bound to more than 1 key in the same keymap.
>
> You donʼt need `map-keymap' for that:
>
> +                   (desc (mapconcat (lambda (key)
> +                                      (format "'%s'" (key-description key)))
> +                                    (or (where-is-internal command map)
> +                                        (where-is-internal (nth 3 info) map)) ", ")))
> +              (princ (format-message " `%s' (bound to %s)\n" command desc))))

Thanks, works nicely, so pushed it now.