GNU bug report logs - #66998
29.1; Regression for recursive keyboard macros + minibuffers in (I think) Emacs 28

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Morgon Kanter <morgon.kanter <at> gmail.com>, Alan Mackenzie <acm <at> muc.de>
Cc: 66998 <at> debbugs.gnu.org
Subject: bug#66998: 29.1; Regression for recursive keyboard macros + minibuffers in (I think) Emacs 28
Date: Wed, 08 Nov 2023 14:36:56 +0200

> From: Morgon Kanter <morgon.kanter <at> gmail.com>
> Date: Tue, 7 Nov 2023 22:29:22 -0500
> 
> I believe there is a regression, but possibly intentional, caused by this patch:
> https://github.com/emacs-mirror/emacs/commit/203e61ff837128b397eb313a5bb1b703f0eae0ec
> 
> This affects minibuffers created when (kbd-macro-query t) is called as
> part of the hook that runs when the (read-from-minibuffer) function is
> called. You get the error message "Not in most nested command loop". For
> example, this code here:
> https://www.emacswiki.org/emacs/KeyboardMacros#h5o-5
> 
> Or, pasting the code in question:
> 
>     (defun my-macro-query (arg)
>       "Prompt for input using minibuffer during kbd macro execution.
>     With prefix argument, allows you to select what prompt string to use.
>     If the input is non-empty, it is inserted at point."
>       (interactive "P")
>       (let* ((prompt (if arg (read-from-minibuffer "PROMPT: ") "Input: "))
>              (input (minibuffer-with-setup-hook (lambda () (kbd-macro-query t))
>                       (read-from-minibuffer prompt))))
>         (unless (string= "" input) (insert input))))
>     (global-set-key (kbd "C-x Q") 'my-macro-query)
> 
> If you attempt to start a keyboard macro via F3, then attempt to read a
> minibuffer with the above code via C-x Q, upon pressing ENTER to close
> the minibuffer, you get the following error message:
> "Not in most nested command loop"
> 
> You won't be able to close out the minibuffer, the only way I found to
> proceed was to C-] or multiple escapes, which canceled the keyboard
> macro creation. As a result, it appears we can't use the above method to
> read and set variables during keyboard macro creation. I'm not sure if
> this is intentional or not, or if there's a replacement for the above or
> not. But it appears to be a regression from before that series of patches.

Alan, can you please look into this?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.