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

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.

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





  reply	other threads:[~2023-11-09 18:41 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 [this message]
2023-11-10 18:57     ` Alan Mackenzie
2023-11-12 18:26       ` Morgon Kanter
2024-05-31 10:16     ` Alan Mackenzie

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='CAMGeJwkXYw3rS8MH44u+16haDRUawJhy=AT9mS1O3Qcox8NxHw@mail.gmail.com' \
    --to=morgon.kanter@gmail.com \
    --cc=66998@debbugs.gnu.org \
    --cc=acm@muc.de \
    --cc=eliz@gnu.org \
    /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).