GNU bug report logs -
#59539
29.0.50; Commands created with `insert-kbd-macro` are NOT getting repeated.
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 59539 in the body.
You can then email your comments to 59539 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#59539
; Package
emacs
.
(Thu, 24 Nov 2022 11:00:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Ramesh Nedunchezian <rameshnedunchezian <at> outlook.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Thu, 24 Nov 2022 11:00:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Commands created with `insert-kbd-macro` are NOT getting repeated. Can this limitation be lifted?
For example, down below `my-cmd-a' and `my-cmd-b' are kbd macro commands bound to `<f12> a' and `<f12> b' respectively.
With `repeat-mode' ON, I would expect that `a' and `b' keys to be repeatable .
That is I am expecting that
<f12> a a
<f12> a b
will move the cursor and NOT modify the buffer.
Can `repeat-mode' be enhanced to make `a' and `b' keys repeatable.
Sometimes I do complex edits, and it is fairly common in my case to alternate between MANY kbd macro commands to quickly "fixup" things that I am editing. F
WIW, the text files that I edit are txt files created with pdftotext, and the PDF files are usually books, or handouts which I want to read in epub format.
So, I have multiple kbd macros in my init file that remove headers, and footers, removes indentation, changes bullets, remove hyphenation, linearize columnar text etc. It would be convenient if these kbd macro commands are repeatable.
(defalias 'my-cmd-a
(kmacro "C-f C-f"))
(defalias 'my-cmd-b
(kmacro "C-b C-b"))
(define-prefix-command 'my-kmacro-keymap)
(define-key my-kmacro-keymap (kbd "a") #'my-cmd-a)
(define-key my-kmacro-keymap (kbd "b") #'my-cmd-b)
(put 'my-cmd-a 'repeat-map 'my-kmacro-keymap)
(put 'my-cmd-b 'repeat-map 'my-kmacro-keymap)
(global-set-key (kbd "<f12>")
my-kmacro-keymap)
(repeat-mode -1)
(repeat-mode +1)
In GNU Emacs 29.0.50 (build 3, x86_64-pc-linux-gnu, GTK+ Version
3.24.34, cairo version 1.16.0) of 2022-11-19 built on debian
Repository revision: a6ae13af42ede6618c326855ea4c95e0298fb75b
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101004
System Description: Debian GNU/Linux bookworm/sid
Severity set to 'wishlist' from 'normal'
Request was from
Stefan Kangas <stefankangas <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Thu, 24 Nov 2022 23:28:03 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#59539
; Package
emacs
.
(Wed, 14 Dec 2022 17:14:02 GMT)
Full text and
rfc822 format available.
Message #10 received at 59539 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Thu, 24 Nov 2022 16:28:47 +0530, Ramesh Nedunchezian <rameshnedunchezian <at> outlook.com> said:
Ramesh> (defalias 'my-cmd-a
Ramesh> (kmacro "C-f C-f"))
Ramesh> (defalias 'my-cmd-b
Ramesh> (kmacro "C-b C-b"))
Ramesh> (define-prefix-command 'my-kmacro-keymap)
Ramesh> (define-key my-kmacro-keymap (kbd "a") #'my-cmd-a)
Ramesh> (define-key my-kmacro-keymap (kbd "b") #'my-cmd-b)
Ramesh> (put 'my-cmd-a 'repeat-map 'my-kmacro-keymap)
Ramesh> (put 'my-cmd-b 'repeat-map 'my-kmacro-keymap)
Ramesh> (global-set-key (kbd "<f12>")
Ramesh> my-kmacro-keymap)
Ramesh> (repeat-mode -1)
Ramesh> (repeat-mode +1)
Hmm, with your recipe on emacs master, "<f12> b" repeats, but "<f12>
a" doesnʼt. I have no clue why, they call the same underlying
infrastructure.
If I use the following instead:
(defun my-cmd-a ()
(interactive)
(forward-char 2))
(defun my-cmd-b ()
(interactive)
(backward-char 2))
it all works as expected, but Iʼm guessing you have a bunch of macros
defined already.
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#59539
; Package
emacs
.
(Thu, 15 Dec 2022 07:32:01 GMT)
Full text and
rfc822 format available.
Message #13 received at 59539 <at> debbugs.gnu.org (full text, mbox):
> Ramesh> (defalias 'my-cmd-a
> Ramesh> (kmacro "C-f C-f"))
>
> Ramesh> (defalias 'my-cmd-b
> Ramesh> (kmacro "C-b C-b"))
>
> Ramesh> (define-key my-kmacro-keymap (kbd "a") #'my-cmd-a)
> Ramesh> (define-key my-kmacro-keymap (kbd "b") #'my-cmd-b)
>
> Hmm, with your recipe on emacs master, "<f12> b" repeats, but "<f12>
> a" doesnʼt. I have no clue why, they call the same underlying
> infrastructure.
Sorry, I missed this bug report. This is because 'repeat-check-key'
is t by default so that unrelated key sequences, for example, 'C-_'
should not activate the repeat map for 'undo', only 'C-x u' should.
When the user types 'a', the real key from kmacro is 'C-f'.
There is no 'f' in the keymap above, so it's ignored,
when 'repeat-check-key' is not customized to nil.
Do you have an idea how to do the right thing and to guess the user's
intention without checking if there are the same keys in the keymap?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#59539
; Package
emacs
.
(Thu, 15 Dec 2022 09:46:02 GMT)
Full text and
rfc822 format available.
Message #16 received at 59539 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Thu, 15 Dec 2022 09:20:31 +0200, Juri Linkov <juri <at> linkov.net> said:
Ramesh> (defalias 'my-cmd-a
Ramesh> (kmacro "C-f C-f"))
>>
Ramesh> (defalias 'my-cmd-b
Ramesh> (kmacro "C-b C-b"))
>>
Ramesh> (define-key my-kmacro-keymap (kbd "a") #'my-cmd-a)
Ramesh> (define-key my-kmacro-keymap (kbd "b") #'my-cmd-b)
>>
>> Hmm, with your recipe on emacs master, "<f12> b" repeats, but "<f12>
>> a" doesnʼt. I have no clue why, they call the same underlying
>> infrastructure.
Juri> Sorry, I missed this bug report. This is because 'repeat-check-key'
Juri> is t by default so that unrelated key sequences, for example, 'C-_'
Juri> should not activate the repeat map for 'undo', only 'C-x u' should.
Juri> When the user types 'a', the real key from kmacro is 'C-f'.
Juri> There is no 'f' in the keymap above, so it's ignored,
Juri> when 'repeat-check-key' is not customized to nil.
That explains why '<f12> b' works
Juri> Do you have an idea how to do the right thing and to guess the user's
Juri> intention without checking if there are the same keys in the keymap?
I guess it should be possible to find out what the 'original' key
pressed was. <time passes> How about the below? I guess it changes the
behaviour when you have a command bound to two keys in the same repeat
map, and you use the 'wrong' one to repeat (but I could argue that
people creating such keymaps should use the 'repeat-check-key'
property)
Ramesh,
(put 'my-cmd-a 'repeat-check-key 'no)
(put 'my-cmd-b 'repeat-check-key 'no)
should do the right thing for you regardless of whether we change
Emacs.
Robert
--
diff --git a/lisp/repeat.el b/lisp/repeat.el
index 33e8d98ce3..05bdb5dfd1 100644
--- a/lisp/repeat.el
+++ b/lisp/repeat.el
@@ -458,8 +458,11 @@ repeat-post-hook
(when rep-map
(when (and (symbolp rep-map) (boundp rep-map))
(setq rep-map (symbol-value rep-map)))
- (let ((map (copy-keymap rep-map)))
-
+ (let* ((map (copy-keymap rep-map))
+ (internal (where-is-internal real-this-command (list map) t))
+ (real-key last-command-event))
+ (when internal
+ (setq real-key (aref internal 0)))
(when (and
;; Detect changes in the minibuffer state to allow repetitions
;; in the same minibuffer, but not when the minibuffer is activated
@@ -467,7 +470,7 @@ repeat-post-hook
(or (< (minibuffer-depth) (car repeat--prev-mb))
(eq current-minibuffer-command (cdr repeat--prev-mb)))
(or (not repeat-keep-prefix) prefix-arg)
- (repeat-check-key last-command-event map))
+ (repeat-check-key real-key map))
;; Messaging
(unless prefix-arg
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#59539
; Package
emacs
.
(Sat, 17 Dec 2022 17:28:02 GMT)
Full text and
rfc822 format available.
Message #19 received at 59539 <at> debbugs.gnu.org (full text, mbox):
>> Do you have an idea how to do the right thing and to guess the user's
>> intention without checking if there are the same keys in the keymap?
>
> I guess it should be possible to find out what the 'original' key
> pressed was. <time passes> How about the below? I guess it changes the
> behaviour when you have a command bound to two keys in the same repeat
> map, and you use the 'wrong' one to repeat
I tested your patch, but then 'C-_' starts the key sequence
'C-_ u u u', whereas we had the users' requests that only 'C-x u'
should start the repeatable sequence by default with 'C-x u u u'.
> (but I could argue that people creating such keymaps should use the
> 'repeat-check-key' property)
For more fine-grained control than 'repeat-check-key', we could support
more properties, for example, define separately only keys that enter
the repeatable sequence, or keys that exit it:
(put 'undo 'repeat-enter-keys '([?\C-x ?u]))
(put 'undo 'repeat-exit-keys '([?\C-_]))
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#59539
; Package
emacs
.
(Tue, 27 Dec 2022 09:20:02 GMT)
Full text and
rfc822 format available.
Message #22 received at 59539 <at> debbugs.gnu.org (full text, mbox):
On 15/12/22 12:50, Juri Linkov wrote:
>> Ramesh> (defalias 'my-cmd-a
>> Ramesh> (kmacro "C-f C-f"))
>>
>> Ramesh> (defalias 'my-cmd-b
>> Ramesh> (kmacro "C-b C-b"))
>>
>> Ramesh> (define-key my-kmacro-keymap (kbd "a") #'my-cmd-a)
>> Ramesh> (define-key my-kmacro-keymap (kbd "b") #'my-cmd-b)
>>
>> Hmm, with your recipe on emacs master, "<f12> b" repeats, but "<f12>
>> a" doesnʼt. I have no clue why, they call the same underlying
>> infrastructure.
>
> Sorry, I missed this bug report. This is because 'repeat-check-key'
> is t by default so that unrelated key sequences, for example, 'C-_'
> should not activate the repeat map for 'undo', only 'C-x u' should.
>
> When the user types 'a', the real key from kmacro is 'C-f'.
> There is no 'f' in the keymap above, so it's ignored,
> when 'repeat-check-key' is not customized to nil.
>
> Do you have an idea how to do the right thing and to guess the user's
> intention without checking if there are the same keys in the keymap?
`repeat-check-key` suggestion works for me.
Reply sent
to
Juri Linkov <juri <at> linkov.net>
:
You have taken responsibility.
(Tue, 27 Dec 2022 18:15:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Ramesh Nedunchezian <rameshnedunchezian <at> outlook.com>
:
bug acknowledged by developer.
(Tue, 27 Dec 2022 18:15:03 GMT)
Full text and
rfc822 format available.
Message #27 received at 59539-done <at> debbugs.gnu.org (full text, mbox):
> `repeat-check-key` suggestion works for me.
Thanks for confirming. So closing this bug report.
For more improvements а new feature request could be created.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Wed, 25 Jan 2023 12:24:06 GMT)
Full text and
rfc822 format available.
This bug report was last modified 2 years and 159 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.