unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: control@debbugs.gnu.org, Morgon Kanter <morgon.kanter@gmail.com>
Cc: acm@muc.de, eliz@gnu.org, 66998@debbugs.gnu.org
Subject: bug#66998: 29.1; Regression for recursive keyboard macros + minibuffers in (I think) Emacs 28
Date: Fri, 31 May 2024 10:16:37 +0000	[thread overview]
Message-ID: <ZlmjhaaiGlL0Zvd6@ACM> (raw)
In-Reply-To: <CAMGeJwkXYw3rS8MH44u+16haDRUawJhy=AT9mS1O3Qcox8NxHw@mail.gmail.com>

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





      parent reply	other threads:[~2024-05-31 10:16 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-08  3:29 bug#66998: 29.1; Regression for recursive keyboard macros + minibuffers in (I think) Emacs 28 Morgon Kanter
2023-11-08  6:41 ` bug#66998: Further information Morgon Kanter
2023-11-08 12:36 ` bug#66998: 29.1; Regression for recursive keyboard macros + minibuffers in (I think) Emacs 28 Eli Zaretskii
2023-11-08 12:53   ` Alan Mackenzie
2023-11-09 17:37 ` Alan Mackenzie
2023-11-09 18:41   ` Morgon Kanter
2023-11-10 18:57     ` Alan Mackenzie
2023-11-12 18:26       ` Morgon Kanter
2024-05-31 10:16     ` Alan Mackenzie [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZlmjhaaiGlL0Zvd6@ACM \
    --to=acm@muc.de \
    --cc=66998@debbugs.gnu.org \
    --cc=control@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=morgon.kanter@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).