bug#51390: 29.0.50; repeat-mode: Fails to repeat keys in global-map(?)

bug#51390: 29.0.50; repeat-mode: Fails to repeat keys in global-map(?)

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

Hello,

I'm trying to make next/previous-line repeatable by using the follow
code snippet,

        (defvar teest
          (let ((map (make-sparse-keymap)))
            (define-key map "n" #'next-line)
            (define-key map "p" #'previous-line)
            map))

        (put 'next-line 'repeat-map 'teest)
        (put 'previous-line 'repeat-map 'teest)

However, next-line triggers the repeat map only when it is run in the
last line of the buffer, and similarly previous-line triggers the repeat
map only when it is run in the first line of the buffer.

A similar behaviour is observed when replacing next-line and
previous-line with forward-char at BOB and backward-char at EOB
respectively.  If I make move-end/beginning-of-line repeatable instead,
 the repeat map does not get triggered at all (regardless of where the 
point is).

To reproduce the issue,

1. emacs -Q
2. Evaluate the expressions in this message.  Turn on repeat-mode.
3. Switch to the *scratch* buffer and press M-<.
4. Type C-n.  Notice that it does not trigger the repeat map.
5. Type C-p twice.  The repeat map gets triggered in the second keypress
i.e., when the point is at the first line.

I can reproduce this issue in the master branch and in an Emacs 28 build
with emacs-repository-version fc8df2561b8e37089463d0d4d008d73e23cb2dc5.

Regards.

In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.27, cairo version 1.16.0)
Repository revision: 709e1e59f0f4db24580566f5ca661e730afbf9a2
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12012000
System Description: NixOS 21.11 (Porcupine)

Configured using:
'configure
--prefix=/nix/store/w1fmhydqpvjl9lz9frqsc8203d0nqd76-emacs-git-20211025.0
--disable-build-details --with-modules --with-x-toolkit=gtk3 --with-xft
--with-cairo'

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

Important settings:
  value of $EMACSLOADPATH:
  value of $EMACSNATIVELOADPATH: /nix/store/llq9dy2f8zmf697jwrnly37g66pwwq1y-emacs-packages-deps/share/emacs/native-lisp::
  value of $LANG: en_GB.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  repeat-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-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
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg rfc6068 epg-config gnus-util rmail
rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json map text-property-search mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils edebug
backtrace pulse color thingatpt xref project ring jka-compr find-func
cl-print dabbrev kmacro facemenu two-column time-date cl-extra seq gv
subr-x byte-opt bytecomp byte-compile cconv help-fns radix-tree
cus-start cus-load repeat misearch multi-isearch help-mode cl-loaddefs
cl-lib iso-transl tooltip eldoc paren electric uniquify ediff-hook
vc-hooks lisp-float-type elisp-mode 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 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 emoji-zwj 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
dynamic-setting system-font-setting font-render-setting cairo
move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 106524 8571)
(symbols 48 9251 1)
(strings 32 25944 1615)
(string-bytes 1 863874)
(vectors 16 20434)
(vector-slots 8 465587 10211)
(floats 8 124 87)
(intervals 56 716 1127)
(buffers 992 14))

bug#51390: 29.0.50; repeat-mode: Fails to repeat keys in global-map(?)

[Juri Linkov]

> I'm trying to make next/previous-line repeatable by using the follow
> code snippet,
>
>         (defvar teest
>           (let ((map (make-sparse-keymap)))
>             (define-key map "n" #'next-line)
>             (define-key map "p" #'previous-line)
>             map))
>
> To reproduce the issue,
>
> 1. emacs -Q
> 2. Evaluate the expressions in this message.  Turn on repeat-mode.
> 3. Switch to the *scratch* buffer and press M-<.
> 4. Type C-n.  Notice that it does not trigger the repeat map.
> 5. Type C-p twice.  The repeat map gets triggered in the second keypress
> i.e., when the point is at the first line.

This is because currently only the last character of the initial
key sequence is allowed to be repeated.  The initial key was "C-n"
and the repeat key is "n" - it's not the same key.  This condition
was added to repeat only such key sequences 'C-x u  u u u ...',
but not 'C-/  u u u u ...'.  Now addition of a new option is underway.
It will allow customization of such preference.

bug#51390: 29.0.50; repeat-mode: Fails to repeat keys in global-map(?)

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

25 Oct 2021, 22:46 by juri@linkov.net:

Hello Juri,

>> [...]
> This is because currently only the last character of the initial
> key sequence is allowed to be repeated.  The initial key was "C-n"
> and the repeat key is "n" - it's not the same key.  This condition
> was added to repeat only such key sequences 'C-x u  u u u ...',
> but not 'C-/  u u u u ...'. 
>

That explains why I can't repeat C-n, but what makes repeat-mode
repeat C-n when at the first line?  That really perplexes me and I'm
curious to know the reason.  


>  Now addition of a new option is underway.
> It will allow customization of such preference.
>

Thank you for looking into this!

bug#51390: 29.0.50; repeat-mode: Fails to repeat keys in global-map(?)

[Juri Linkov]

>> This is because currently only the last character of the initial
>> key sequence is allowed to be repeated.  The initial key was "C-n"
>> and the repeat key is "n" - it's not the same key.  This condition
>> was added to repeat only such key sequences 'C-x u  u u u ...',
>> but not 'C-/  u u u u ...'.
>
> That explains why I can't repeat C-n, but what makes repeat-mode
> repeat C-n when at the first line?  That really perplexes me and I'm
> curious to know the reason.

It seems you found a bug.  When typing C-p at the beginning of the
buffer it signals an error "Beginning of buffer" (this is correct).

But in this case '(this-command-keys-vector)' used by repeat-mode
returns [].  This is an unexpected value.

bug#51390: 29.0.50; repeat-mode: Fails to repeat keys in global-map(?)

[Juri Linkov]

>>> This is because currently only the last character of the initial
>>> key sequence is allowed to be repeated.  The initial key was "C-n"
>>> and the repeat key is "n" - it's not the same key.  This condition
>>> was added to repeat only such key sequences 'C-x u  u u u ...',
>>> but not 'C-/  u u u u ...'.
>>
>> That explains why I can't repeat C-n, but what makes repeat-mode
>> repeat C-n when at the first line?  That really perplexes me and I'm
>> curious to know the reason.
>
> It seems you found a bug.  When typing C-p at the beginning of the
> buffer it signals an error "Beginning of buffer" (this is correct).
>
> But in this case '(this-command-keys-vector)' used by repeat-mode
> returns [].  This is an unexpected value.

Or maybe this is not a bug: since an error stops executing a keyboard macro,
it makes sense to stop a repeating sequence on error as well
(this logic will be applied after fixing the reported bug).

bug#51390: 29.0.50; repeat-mode: Fails to repeat keys in global-map(?)

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

16 Nov 2021, 00:24 by juri@linkov.net:

Hi Juri,
> Or maybe this is not a bug: since an error stops executing a keyboard macro,
> it makes sense to stop a repeating sequence on error as well
> (this logic will be applied after fixing the reported bug).
>

I think implementing this will actually end up making certain repeat-maps
tedious to use.  One example that comes to mind is
`outline-navigation-repeat-map' where it is quite easy to misfire f/b
when you actually want n/p.  Starting the map again with C-c @ C-n is
quite tedious.  I hope you reconsider this, or make the current
behaviour opt-in.

Although triggering repeat-map on error is strange for the scenario in
OP, I hope the above convinces you regardless.  I only noticed the
behaviour on error is desirable after I started using the outline functions
a bit more.

bug#51390: 29.0.50; repeat-mode: Fails to repeat keys in global-map(?)

[Juri Linkov]

> I think implementing this will actually end up making certain repeat-maps
> tedious to use.  One example that comes to mind is
> `outline-navigation-repeat-map' where it is quite easy to misfire f/b
> when you actually want n/p.  Starting the map again with C-c @ C-n is
> quite tedious.  I hope you reconsider this, or make the current
> behaviour opt-in.

Please clarify how can you misfire f/b when you intended n/p.
What keys does your keymap contain?

> Although triggering repeat-map on error is strange for the scenario in
> OP, I hope the above convinces you regardless.  I only noticed the
> behaviour on error is desirable after I started using the outline functions
> a bit more.

Triggering repeat-map on error is a bug that will be fixed.
But it will be fixed in such a way that the error will exit
the repeating sequence.

bug#51390: 29.0.50; repeat-mode: Fails to repeat keys in global-map(?)

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

Hi Juri,

17 Nov 2021, 01:48 by juri@linkov.net:
>>I think implementing this will actually end up making certain repeat-maps
>>tedious to use.  One example that comes to mind is
>>`outline-navigation-repeat-map' where it is quite easy to misfire f/b
>>when you actually want n/p.  Starting the map again with C-c @ C-n is
>>quite tedious.  I hope you reconsider this, or make the current
>>behaviour opt-in.
>
>Please clarify how can you misfire f/b when you intended n/p.
>What keys does your keymap contain?

From M-x describe-repeat-maps,

‘outline-navigation-repeat-map’ keymap is repeatable by these commands:
‘outline-backward-same-level’ (f)
‘outline-forward-same-level’ (b)
‘outline-next-visible-heading’ (n)
‘outline-previous-visible-heading’ (p)
‘outline-up-heading’ (u)

When you do not know the structure of the outline headings beforehand,
it can so happen that you press f/b anticipating that there's a heading
on the same level but that might not be case.  If f/b `error's, then you
have to press n/p to continue navigating.  This is what I meant by
"misfiring."

If repeat-mode decides to end the repeating sequence, I'd have to start
again with C-c @ C-n.  IMO, this isn't a friendly interface.

>>Although triggering repeat-map on error is strange for the scenario in
>>OP, I hope the above convinces you regardless.  I only noticed the
>>behaviour on error is desirable after I started using the outline functions
>>a bit more.
>
>Triggering repeat-map on error is a bug that will be fixed.
>But it will be fixed in such a way that the error will exit
>the repeating sequence.

My point is that sometimes it is desirable to not end the sequence on
`error'.

bug#51390: 29.0.50; repeat-mode: Fails to repeat keys in global-map(?)

[Juri Linkov]

> When you do not know the structure of the outline headings beforehand,
> it can so happen that you press f/b anticipating that there's a heading
> on the same level but that might not be case.  If f/b `error's, then you
> have to press n/p to continue navigating.  This is what I meant by
> "misfiring."
>
> If repeat-mode decides to end the repeating sequence, I'd have to start
> again with C-c @ C-n.  IMO, this isn't a friendly interface.
>
>>Triggering repeat-map on error is a bug that will be fixed.
>>But it will be fixed in such a way that the error will exit
>>the repeating sequence.
>
> My point is that sometimes it is desirable to not end the sequence on
> `error'.

Thanks, everything's clear now.  And no worries — a new option will allow
to not end the repeating sequence on error.

One problem I had with writing tests for such a feature — tests for repeat-mode
are based on ‘execute-kbd-macro’, but an error ends the keyboard macro.
So probably there will be no tests for this error-signaling repeatable commands.

bug#51390: 29.0.50; repeat-mode: Fails to repeat keys in global-map(?)

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

17 Nov 2021, 13:24 by juri@linkov.net:

Hi Juri,

>Thanks, everything's clear now. And no worries — a new option will allow
>to not end the repeating sequence on error.

Great, thanks!

>One problem I had with writing tests for such a feature — tests for repeat-mode
>are based on ‘execute-kbd-macro’, but an error ends the keyboard macro.
>So probably there will be no tests for this error-signaling repeatable commands.

I wonder if the new mechanism added to ERT by Lars could be help here?
(and used by the indentation tests)  But I suppose you still have to end
up using keyboard macros one way or another...

bug#51390: 29.0.50; repeat-mode: Fails to repeat keys in global-map(?)

[Juri Linkov]

>>One problem I had with writing tests for such a feature — tests for repeat-mode
>>are based on ‘execute-kbd-macro’, but an error ends the keyboard macro.
>>So probably there will be no tests for this error-signaling repeatable commands.
>
> I wonder if the new mechanism added to ERT by Lars could be help here?
> (and used by the indentation tests)  But I suppose you still have to end
> up using keyboard macros one way or another...

I don't know how buffer-based ERT fixtures could help to test repeatable
key sequences.  What I rather tried to do is to use ‘ert-simulate-command’
(after removing ‘(cl-assert (not unread-command-events) t)’) and
‘ert-simulate-keys’ (after adding ‘(noninteractive nil)’ let-binding),
to no avail.

bug#51390: 29.0.50; repeat-mode: Fails to repeat keys in global-map(?)

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

21 Nov 2021, 00:42 by juri@linkov.net:

Hi Juri,

>>>One problem I had with writing tests for such a feature — tests for repeat-mode
>>>are based on ‘execute-kbd-macro’, but an error ends the keyboard macro.
>>>So probably there will be no tests for this error-signaling repeatable commands.
>>
>> I wonder if the new mechanism added to ERT by Lars could be help here?
>> (and used by the indentation tests)  But I suppose you still have to end
>> up using keyboard macros one way or another...
>
> I don't know how buffer-based ERT fixtures could help to test repeatable
> key sequences. What I rather tried to do is to use ‘ert-simulate-command’
> (after removing ‘(cl-assert (not unread-command-events) t)’) and
> ‘ert-simulate-keys’ (after adding ‘(noninteractive nil)’ let-binding),
> to no avail.

I was thinking about grouping navigation commands that could `error'
(like in OP and the outline commands) in a repeatable keymap and making
use of Point-Char spec to test where the point ends up.
But I suppose this wouldn't get us anywhere since you still have to
"press" those keys somehow.

bug#51390: 29.0.50; repeat-mode: Fails to repeat keys in global-map(?)

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 1344 bytes --]

>         (defvar teest
>           (let ((map (make-sparse-keymap)))
>             (define-key map "n" #'next-line)
>             (define-key map "p" #'previous-line)
>             map))
>
>         (put 'next-line 'repeat-map 'teest)
>         (put 'previous-line 'repeat-map 'teest)
>...
> 4. Type C-n.  Notice that it does not trigger the repeat map.

I tried to implement what you asked to do, but got horrible results
caused too much damage.  Here is the lossage explaining the problem:

 C-<tab>           ;; tab-next
 o                 ;; tab-next
 n                 ;; gnus-group-next-unread-group

i.e. I typed C-<tab> to switch to the next tab with the text buffer
where I started to type text that begins with the letters "on..."

But instead of inserting letters to the buffer, the letter "o"
switched to the second next tab.  This tab contained the Gnus buffer
where typing the second letter "n" called the bound command
gnus-group-next-unread-group, and I lost all unread messages.

But I never had such a problem when the repeating sequence was
activated only by 'C-x t o ... o o ...' instead of 'C-<tab> o o o ...'
because 'C-<tab>' is a single key, there is no need to activate
other keys doing the same.

This means that by default this behavior should be disabled.
But maybe a new variable should allow to skip this check:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: repeat-foreign-key.patch --]
[-- Type: text/x-diff, Size: 1068 bytes --]

diff --git a/lisp/repeat.el b/lisp/repeat.el
index 4dcd353e34..03e5b032fe 100644
--- a/lisp/repeat.el
+++ b/lisp/repeat.el
@@ -360,6 +360,12 @@ repeat-keep-prefix
   :group 'convenience
   :version "28.1")
 
+(defcustom repeat-foreign-key nil
+  "Whether to check if the last key exists in the repeat map."
+  :type 'boolean
+  :group 'convenience
+  :version "28.1")
+
 (defcustom repeat-echo-function #'repeat-echo-message
   "Function to display a hint about available keys.
 Function is called after every repeatable command with one argument:
@@ -428,7 +434,8 @@ repeat-post-hook
                        (eq current-minibuffer-command (cdr repeat--prev-mb)))
                    ;; Exit when the last char is not among repeatable keys,
                    ;; so e.g. `C-x u u' repeats undo, whereas `C-/ u' doesn't.
-                   (or (lookup-key map (this-command-keys-vector))
+                   (or repeat-foreign-key
+                       (lookup-key map (vector last-nonmenu-event))
                        prefix-arg))
 
               ;; Messaging

bug#51390: 29.0.50; repeat-mode: Fails to repeat keys in global-map(?)

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

22 Nov 2021, 02:19 by juri@linkov.net:

>>         (defvar teest
>>           (let ((map (make-sparse-keymap)))
>>             (define-key map "n" #'next-line)
>>             (define-key map "p" #'previous-line)
>>             map))
>>
>>         (put 'next-line 'repeat-map 'teest)
>>         (put 'previous-line 'repeat-map 'teest)
>>
> >...
>
>> 4. Type C-n.  Notice that it does not trigger the repeat map.
>>
>
> I tried to implement what you asked to do, but got horrible results
> caused too much damage.  Here is the lossage explaining the problem:
>
>  C-<tab>           ;; tab-next
>  o                 ;; tab-next
>  n                 ;; gnus-group-next-unread-group
>
> i.e. I typed C-<tab> to switch to the next tab with the text buffer
> where I started to type text that begins with the letters "on..."
>
> But instead of inserting letters to the buffer, the letter "o"
> switched to the second next tab.  This tab contained the Gnus buffer
> where typing the second letter "n" called the bound command
> gnus-group-next-unread-group, and I lost all unread messages.
>
> But I never had such a problem when the repeating sequence was
> activated only by 'C-x t o ... o o ...' instead of 'C-<tab> o o o ...'
> because 'C-<tab>' is a single key, there is no need to activate
> other keys doing the same.
>
> This means that by default this behavior should be disabled.
> But maybe a new variable should allow to skip this check:
>

Hi Juri,

I am currently in the middle of exams, I will try out the patch in a couple

bug#51390: 29.0.50; repeat-mode: Fails to repeat keys in global-map(?)

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

22 Nov 2021, 09:14 by visuwesh@tutanota.com:

> 22 Nov 2021, 02:19 by juri@linkov.net:
>
>>>         (defvar teest
>>>           (let ((map (make-sparse-keymap)))
>>>             (define-key map "n" #'next-line)
>>>             (define-key map "p" #'previous-line)
>>>             map))
>>>
>>>         (put 'next-line 'repeat-map 'teest)
>>>         (put 'previous-line 'repeat-map 'teest)
>>>
>> >...
>>
>>> 4. Type C-n.  Notice that it does not trigger the repeat map.
>>>
>>
>> I tried to implement what you asked to do, but got horrible results
>> caused too much damage.  Here is the lossage explaining the problem:
>>
>> C-<tab>           ;; tab-next
>> o                 ;; tab-next
>> n                 ;; gnus-group-next-unread-group
>>
>> i.e. I typed C-<tab> to switch to the next tab with the text buffer
>> where I started to type text that begins with the letters "on..."
>>
>> But instead of inserting letters to the buffer, the letter "o"
>> switched to the second next tab.  This tab contained the Gnus buffer
>> where typing the second letter "n" called the bound command
>> gnus-group-next-unread-group, and I lost all unread messages.
>>
>> But I never had such a problem when the repeating sequence was
>> activated only by 'C-x t o ... o o ...' instead of 'C-<tab> o o o ...'
>> because 'C-<tab>' is a single key, there is no need to activate
>> other keys doing the same.
>>
>> This means that by default this behavior should be disabled.
>> But maybe a new variable should allow to skip this check:
>>
>
> Hi Juri,
> I am currently in the middle of exams, I will try out the patch in a couple
>
in a couple of days, that is.

I pressed the send key too quickly.  Sorry for the noise.

bug#51390: 29.0.50; repeat-mode: Fails to repeat keys in global-map(?)

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

22 Nov 2021, 02:19 by juri@linkov.net:

Hi Juri,

> I tried to implement what you asked to do, but got horrible results
> caused too much damage. Here is the lossage explaining the problem:
>
> C-<tab> ;; tab-next
> o ;; tab-next
> n ;; gnus-group-next-unread-group
>
> i.e. I typed C-<tab> to switch to the next tab with the text buffer
> where I started to type text that begins with the letters "on..."
>
> But instead of inserting letters to the buffer, the letter "o"
> switched to the second next tab. This tab contained the Gnus buffer
> where typing the second letter "n" called the bound command
> gnus-group-next-unread-group, and I lost all unread messages.
>
> But I never had such a problem when the repeating sequence was
> activated only by 'C-x t o ... o o ...' instead of 'C-<tab> o o o ...'
> because 'C-<tab>' is a single key, there is no need to activate
> other keys doing the same.
>
> This means that by default this behavior should be disabled.
> But maybe a new variable should allow to skip this check:

Yes,  you are right, it is disruptive.  Having tried the repeat-map I
had in the OP for a while now, it is biting me in the back in the most
unexpected times.  Maybe this is better left unimplemented?

bug#51390: 29.0.50; repeat-mode: Fails to repeat keys in global-map(?)

[Juri Linkov]

>> This means that by default this behavior should be disabled.
>> But maybe a new variable should allow to skip this check:
>
> Yes,  you are right, it is disruptive.  Having tried the repeat-map I
> had in the OP for a while now, it is biting me in the back in the most
> unexpected times.  Maybe this is better left unimplemented?

This feature of checking the last key could be enabled per every keymap
using symbol properties.  Then you can disable it for one keymap,
while keeping enabled for all remaining keymaps.

bug#51390: 29.0.50; repeat-mode: Fails to repeat keys in global-map(?)

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

25 Nov 2021, 13:24 by juri@linkov.net:

Hi Juri,
>>> This means that by default this behavior should be disabled.
>>> But maybe a new variable should allow to skip this check:
>>>
>>
>> Yes,  you are right, it is disruptive.  Having tried the repeat-map I
>> had in the OP for a while now, it is biting me in the back in the most
>> unexpected times.  Maybe this is better left unimplemented?
>>
>
> This feature of checking the last key could be enabled per every keymap
> using symbol properties.  Then you can disable it for one keymap,
> while keeping enabled for all remaining keymaps.
>

That indeed sounds like a good solution to the problem.  Thanks!

bug#51390: 29.0.50; repeat-mode: Fails to repeat keys in global-map(?)

[Juri Linkov]

close 51390 28.0.60
thanks

>> This feature of checking the last key could be enabled per every keymap
>> using symbol properties.  Then you can disable it for one keymap,
>> while keeping enabled for all remaining keymaps.
>
> That indeed sounds like a good solution to the problem.  Thanks!

This is fixed now, so your original case is supported,
as well as more cases reported in e.g.
https://lists.gnu.org/archive/html/emacs-devel/2021-04/msg00083.html
https://lists.gnu.org/archive/html/emacs-devel/2021-08/msg00962.html

The behavior can be customized by the new user option 'repeat-check-key'.
Also a command can have a symbol property with the same name
and two values: 't' checks the key when the variable is nil,
and 'no' doesn't check the key when the variable is t.

A special property 'no' is necessary instead of using 'nil',
because 'get' can't distinguish when the property has the
value 'nil' and when there is no property set on the symbol.
Also there is no function to delete a property from a plist,
so every package invents own wheel, e.g. map--plist-delete.
org-plist-delete-all, svg--plist-delete...

bug#51390: 29.0.50; repeat-mode: Fails to repeat keys in global-map(?)

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

1 Dec 2021, 00:39 by juri@linkov.net:

Hello, Juri

> [...]
> This is fixed now, so your original case is supported,
> as well as more cases reported in e.g.
> https://lists.gnu.org/archive/html/emacs-devel/2021-04/msg00083.html
> https://lists.gnu.org/archive/html/emacs-devel/2021-08/msg00962.html
>
> [...]

Thank you once again!