bug#66998: 29.1; Regression for recursive keyboard macros + minibuffers in (I think) Emacs 28

[Alan Mackenzie]

Hello, Morgon.

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.

Thanks, appreciated!

> 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!

It should be possible in Emacs to do what you want to do.  I've not been
able to come up with any clean way to do this, even after sleeping on
it.

It seems there is a deficiency in Emacs's keyboard macro handling.  I
think we need a new interactive command called something like
interpolate-kbd-macro, which would take one argument, a function to run.
This function would take no arguments and return a list of key
sequences.  These key sequences, rather than being inserted into the
keyboard macro, would instead be looked up in the current keymaps, and
their commands (e.g.  self-insert-command) would get run as part of the
current keyboard macro invocation.

Or something like that.  What do you think?

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

WAI?  That's a new one on me!

Possibly a new bug should be opened to implement my suggestion above.

> > 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.

OK, thanks.

-- 
Alan Mackenzie (Nuremberg, Germany).