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

Previous Next

Package: emacs;

Reported by: Morgon Kanter <morgon.kanter <at> gmail.com>

Date: Wed, 8 Nov 2023 06:18:02 UTC

Severity: normal

Tags: notabug

Found in version 29.1

Done: Alan Mackenzie <acm <at> muc.de>

Bug is archived. No further changes may be made.

Full log


Message #31 received at control <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: control <at> debbugs.gnu.org, Morgon Kanter <morgon.kanter <at> gmail.com>
Cc: acm <at> muc.de, eliz <at> gnu.org, 66998 <at> debbugs.gnu.org
Subject: Re: bug#66998: 29.1; Regression for recursive keyboard macros +
 minibuffers in (I think) Emacs 28
Date: Fri, 31 May 2024 10:16:37 +0000
tag 66998 + notabug
close 66998
quit

Hello, Morgon.

Sorry, I didn't get around to resolving this back in November.  So ....

On Thu, Nov 09, 2023 at 13:41:26 -0500, Morgon Kanter wrote:
> Hi Alan,

> tl;dr: you're right, not a bug, just user error :-)

> Trying this one more time, I rediscovered how to turn on "plain text
> mode". So I hope this one doesn't get garbled HTML.

> First, this was the original code that got garbled. It should be
> visible in the mailing list archive in a web browser. Pasted again
> here:

> > (defun config: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))))

> Your intuition was totally right. This isn't really a bug, and
> probably not a regression in behavior either. Use of C-M-c to exit the
> recursive edit before the minibuffer works as expected. The only
> "problem" is that you need to press C-M-c to terminate the minibuffer,
> rather than RET. That's a bit awkward and weird, but it's livable. I
> could probably temporarily rebind RET to make it more ergonomic. But
> the truth is that from Emacs's perspective this isn't even something
> that *should* be fixed -- you *should* be exiting the recursive edit
> before you exit the minibuffer, in that order!

> So this, at least, is WAI and this bug should be closed.

I'm closing the bug as "not a bug" with this post.  Thanks for taking
the trouble to report it!

> > So I think the error message "Not in most nested command loop" is
> > correct, even if its not very clear in this context.

> > What are you actually trying to achieve in your real Lisp code with this
> > recursive edit?  At first acquaintance, it looks rather unusual.

> What I am trying to achieve is the ability to prompt the user as part
> of a keyboard macro, and receive input which the macro will then do
> something with. Importantly, this input could be different every time
> the keyboard macro is run. Ordinarily if you were to prompt the user
> for input, all those actions would be considered part of the keyboard
> macro and simply re-run every time. So you need to invoke the
> recursive edit to make it work.

-- 
Alan Mackenzie (Nuremberg, Germany).




This bug report was last modified 357 days ago.

Previous Next


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