unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: 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: Thu, 9 Nov 2023 17:37:22 +0000	[thread overview]
Message-ID: <ZU0Y0t1gPfK88Nt3@ACM> (raw)
In-Reply-To: <CAMGeJwkMJTKwRi6wEj5uYLh+6KNwJv-AYXkwCYg9HY1yNn0L_Q@mail.gmail.com>

Hello, Morgon.

Thanks for taking the trouble to report this.

[ Unfortunately, your post, in HTML, has got corrupted somewhere,
possibly in my mail user agent, thus is difficult to read. ]

On Tue, Nov 07, 2023 at 22:29:22 -0500, Morgon Kanter wrote:
>    I believe there is a regression, but possibly intentional, caused by
>    this patch:
>    [1]https://github.com/emacs-mirror/emacs/commit/203e61ff837128b397eb313
>    a5bb1b703f0eae0ec
>    This affects minibuffers created when (kbd-macro-query t) is called as
>    part of the hook that runs when the (read-from-minibuffer) function is
>    called. You get the error message "Not in most nested command loop".

>    For example, this code here:
>    [2]https://www.emacswiki.org/emacs/KeyboardMacros#h5o-5
>    Or, pasting the code in question:
>    Â  Â  (defun my-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))))
>    Â  Â  Â  Â  (unless (string= "" input) (insert input))))
>    Â  Â  (global-set-key (kbd "C-x Q") 'my-macro-query)

>    If you attempt to start a keyboard macro via F3, then attempt to read a
>    minibuffer with the above code via C-x Q, upon pressing ENTER to close
>    the minibuffer, you get the following error message:
>    "Not in most nested command loop"

>    You won't be able to close out the minibuffer, the only way I found
>    to proceed was to C-] or multiple escapes, which canceled the
>    keyboard macro creation. As a result, it appears we can't use the
>    above method to read and set variables during keyboard macro
>    creation. I'm not sure if this is intentional or not, or if there's
>    a replacement for the above or not. But it appears to be a
>    regression from before that series of patches.

As you say in your later post, you can terminate the recursive edit with
C-M-c.  I'm not sure there's actually a bug, here.  While in the
recursive edit, the minibuffer "belongs" to the outer editing level,
and this outer level expects the recursive edit to be closed before its
minibuffer input can be terminated.

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.

>    In GNU Emacs 29.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.38,
>    cairo version 1.17.8)
>    Windowing system distributor 'Microsoft Corporation', version
>    11.0.12010000
>    System Description: Arch Linux

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).





  parent reply	other threads:[~2023-11-09 17:37 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 [this message]
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

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=ZU0Y0t1gPfK88Nt3@ACM \
    --to=acm@muc.de \
    --cc=66998@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).