bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#66998: 29.1; Regression for recursive keyboard macros + minibuffers


From: Alan Mackenzie
Subject: bug#66998: 29.1; Regression for recursive keyboard macros + minibuffers in (I think) Emacs 28
Date: Wed, 8 Nov 2023 12:53:13 +0000

Hello, Eli.

On Wed, Nov 08, 2023 at 14:36:56 +0200, Eli Zaretskii wrote:
> > From: Morgon Kanter <morgon.kanter@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?

Will do.

-- 
Alan Mackenzie (Nuremberg, Germany).





reply via email to

[Prev in Thread] Current Thread [Next in Thread]