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

[Morgon Kanter]

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

I ended up advising recursive-edit. I set up a transient keymap that
remaps anything that calls minibuffer-exit to exit-recursive-edit.
Then the advice, which fires after recursive-edit completes, undoes
the transient keymap. As far as I can tell, this works out pretty
well.

Your idea does sound cleaner overall than my solution. It's worth
thinking if there's anything else that would be interesting for
enhancing keyboard macros and what's the most general thing we can do
as well. Personally the largest issue I had, which I wasn't able to
completely solve, was keeping things local to a given kmacro. There's
no way I can tell to have some kind of local state for a kmacro. So
the most useful enhancement for me, I think, would be to have some
kind of explicitly local-to-kmacro variable. I imagine just some
specially named variable that could be set when the kmacro is defined,
and referenced when the kmacro is running. So if you wanted to you
could even turn it into an obarray and have a kmacro-local namespace.

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

For reference, here's what I ended up doing with the advice:
https://pastebin.com/wG9L7xRb

Cheers,
-- Morgon