From unknown Sat Jun 21 12:24:35 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#66998 <66998@debbugs.gnu.org> To: bug#66998 <66998@debbugs.gnu.org> Subject: Status: 29.1; Regression for recursive keyboard macros + minibuffers in (I think) Emacs 28 Reply-To: bug#66998 <66998@debbugs.gnu.org> Date: Sat, 21 Jun 2025 19:24:35 +0000 retitle 66998 29.1; Regression for recursive keyboard macros + minibuffers = in (I think) Emacs 28 reassign 66998 emacs submitter 66998 Morgon Kanter severity 66998 normal tag 66998 notabug thanks From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 08 01:17:44 2023 Received: (at submit) by debbugs.gnu.org; 8 Nov 2023 06:17:44 +0000 Received: from localhost ([127.0.0.1]:43907 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0bsj-0006J5-Uk for submit@debbugs.gnu.org; Wed, 08 Nov 2023 01:17:44 -0500 Received: from lists.gnu.org ([2001:470:142::17]:36340) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0ZGo-0001g4-Ub for submit@debbugs.gnu.org; Tue, 07 Nov 2023 22:30:24 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r0ZG6-00070k-R9 for bug-gnu-emacs@gnu.org; Tue, 07 Nov 2023 22:29:38 -0500 Received: from mail-pj1-x1034.google.com ([2607:f8b0:4864:20::1034]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1r0ZG4-0007Ks-2r for bug-gnu-emacs@gnu.org; Tue, 07 Nov 2023 22:29:38 -0500 Received: by mail-pj1-x1034.google.com with SMTP id 98e67ed59e1d1-28098ebd5aeso5910753a91.0 for ; Tue, 07 Nov 2023 19:29:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699414174; x=1700018974; darn=gnu.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=qcNAWqc1FlGs3b3o9IU8CKd0Vq3mfaLrwmleB83GHKY=; b=JIhwR5CJfqIUhFXQztlM5X84eEnor4EwVolZFedKK7virVfcLhV2m8lDX8PcggLvym XeI8IdosGTN9n/HqxZQ6MFfS3Cgaub7YksIBZgvnjU7Sf3LTHcxFCuMmchx65wxSY/Su /BfCRxm1sSdDeF6gYPzMO7Sm/nIasKmgFwv14AmF+x6qk6nvzBcm73eI3JtgpoFAA8h6 gAW4Y0RniOPbnwX4d2MEOXnK+5GW8dni1z1XQyxU+mv6TQdeugtW3sZQlTKSAT+014jX WdnyugFOffarGhT32Wr3EKGGolrBM0ISTGpJVcHopNhW668/2SYsxiuo9RMa8eiK3g+k QzzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699414174; x=1700018974; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=qcNAWqc1FlGs3b3o9IU8CKd0Vq3mfaLrwmleB83GHKY=; b=tdxbdfT0pmWRHXWzfNbqaVZIIBXLPb2wauwIJNXK1UItc15smZBgVZ6vkA7X+K1wgl WeML0Sx7kZXsgLNrTMOlgx3mHYtgh3R4E7FtdBKy48jvkN3yEze6fv5mtUmH7KK1POCL u+hVUmf8KBJAHXJM6lGN5H3Bo7CVqAQ0+fNYDuCFu8rym9WsfFWQygRlAhEOPz0ckWB9 tx0hstommK1SgCRF/1D6iBwcrXpjZVpoM8W8MIRNutbjvqQy14YgtjSlUtewkJgq2YV7 Z+gUMzOnAvu5BYl4VJev1lx6sqv1+kAVxViOCxGJoYrwTykwUPscwLCSfza4eGgVAm59 TsoQ== X-Gm-Message-State: AOJu0Yx3FQw6irjOfWNO7cwcMnCu9Ea90Hkpb+uo1MeF3C/Arev1BSBI EhFAhHtwOLW4w96smfXaEXlUPxsQhLithbDoXFA3vbrS X-Google-Smtp-Source: AGHT+IHbi7JvAI3KGZmb5TX8mzC7aayO9VxpwRBd7eB+5sCXttqKUOAsG+IvBchpoaBt3A/Th2PAsca5fuyLed9sKFc= X-Received: by 2002:a17:90b:4a05:b0:280:35d:4532 with SMTP id kk5-20020a17090b4a0500b00280035d4532mr676151pjb.14.1699414173447; Tue, 07 Nov 2023 19:29:33 -0800 (PST) MIME-Version: 1.0 From: Morgon Kanter Date: Tue, 7 Nov 2023 22:29:22 -0500 Message-ID: Subject: 29.1; Regression for recursive keyboard macros + minibuffers in (I think) Emacs 28 To: bug-gnu-emacs@gnu.org Content-Type: multipart/alternative; boundary="000000000000227a8306099bb283" Received-SPF: pass client-ip=2607:f8b0:4864:20::1034; envelope-from=morgon.kanter@gmail.com; helo=mail-pj1-x1034.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Wed, 08 Nov 2023 01:17:41 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) --000000000000227a8306099bb283 Content-Type: text/plain; charset="UTF-8" I believe there is a regression, but possibly intentional, caused by this patch: https://github.com/emacs-mirror/emacs/commit/203e61ff837128b397eb313a5bb1b703f0eae0ec 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: 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. 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 Configured using: 'configure --with-x-toolkit=gtk3 --with-native-compilation=aot --sysconfdir=/etc --prefix=/usr --libexecdir=/usr/lib --with-tree-sitter --localstatedir=/var --with-cairo --disable-build-details --with-harfbuzz --with-libsystemd --with-modules 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -g -ffile-prefix-map=/build/emacs/src=/usr/src/debug/emacs -flto=auto' 'LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -flto=auto' 'CXXFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -Wp,-D_GLIBCXX_ASSERTIONS -g -ffile-prefix-map=/build/emacs/src=/usr/src/debug/emacs -flto=auto'' Configured features: ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG JSON LCMS2 LIBOTF LIBSYSTEMD LIBXML2 M17N_FLT MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XDBE XIM XINPUT2 XPM GTK3 ZLIB Important settings: value of $LANG: en_US.UTF-8 locale-coding-system: utf-8-unix Major mode: ELisp/d Minor modes in effect: global-git-commit-mode: t magit-auto-revert-mode: t shell-dirtrack-mode: t marginalia-mode: t override-global-mode: t vertico-mode: t which-key-mode: t server-mode: t global-eldoc-mode: t eldoc-mode: t show-paren-mode: t electric-indent-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t column-number-mode: t line-number-mode: t transient-mark-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t Load-path shadows: /home/surgo/.emacs.d/elpa/transient-20231103.2312/transient hides /usr/share/emacs/29.1/lisp/transient /home/surgo/.emacs.d/elpa/seq-2.24/seq hides /usr/share/emacs/29.1/lisp/emacs-lisp/seq Features: (shadow sort mail-extr emacsbug minibuf-eldef thingatpt misearch multi-isearch cl-print debug backtrace find-func mule-util shortdoc help-fns radix-tree macros dired-aux cc-styles cc-align cc-engine cc-vars cc-defs magit-submodule magit-blame magit-stash magit-reflog magit-bisect magit-push magit-pull magit-fetch magit-clone magit-remote magit-commit magit-sequence magit-notes magit-worktree magit-tag magit-merge magit-branch magit-reset magit-files magit-refs magit-status magit magit-repos magit-apply magit-wip magit-log which-func imenu magit-diff smerge-mode diff diff-mode git-commit log-edit message sendmail yank-media puny dired dired-loaddefs rfc822 mml mml-sec epa derived epg rfc6068 epg-config gnus-util text-property-search time-date mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums mail-prsvr mailabbrev mail-utils gmm-utils mailheader pcvs-util add-log magit-core magit-autorevert autorevert filenotify magit-margin magit-transient magit-process with-editor comp comp-cstr warnings icons rx shell pcomplete comint ansi-osc ring ansi-color magit-mode transient magit-git magit-base magit-section format-spec cursor-sensor crm dash marginalia edmacro kmacro use-package-bind-key bind-key easy-mmode vertico compat diminish which-key cl-extra help-mode use-package-diminish use-package-core tango-dark-theme server magit-autoloads pcase git-commit-autoloads magit-section-autoloads dash-autoloads marginalia-autoloads projectile-autoloads transient-autoloads vertico-autoloads with-editor-autoloads info compat-autoloads seq-autoloads package browse-url url url-proxy url-privacy url-expand url-methods url-history url-cookie generate-lisp-file url-domsuf url-util mailcap url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs password-cache json subr-x map byte-opt gv bytecomp byte-compile url-vars cl-loaddefs cl-lib rmc iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic indonesian philippine cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite emoji-zwj charscript charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp files window text-properties overlay sha1 md5 base64 format env code-pages mule custom widget keymap hashtable-print-readable backquote threads dbusbind inotify lcms2 dynamic-setting system-font-setting font-render-setting cairo move-toolbar gtk x-toolkit xinput2 x multi-tty make-network-process native-compile emacs) Memory information: ((conses 16 241723 51274) (symbols 48 17022 0) (strings 32 64370 2962) (string-bytes 1 2928754) (vectors 16 41856) (vector-slots 8 758358 34977) (floats 8 161 322) (intervals 56 1802 323) (buffers 984 17)) --000000000000227a8306099bb283 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I believe there is a regression, but possibly intentional,= caused by this patch:
https://github.com/emacs-m= irror/emacs/commit/203e61ff837128b397eb313a5bb1b703f0eae0ec

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". Fo= r
example, this code here:
https://www.emacswiki.org/emacs/KeyboardMacros#h5o-5=

Or, pasting the code in question:

=C2=A0 =C2=A0 (defun m= y-macro-query (arg)
=C2=A0 =C2=A0 =C2=A0 "Prompt for input using mi= nibuffer during kbd macro execution.
=C2=A0 =C2=A0 With prefix argument,= allows you to select what prompt string to use.
=C2=A0 =C2=A0 If the in= put is non-empty, it is inserted at point."
=C2=A0 =C2=A0 =C2=A0 (i= nteractive "P")
=C2=A0 =C2=A0 =C2=A0 (let* ((prompt (if arg (r= ead-from-minibuffer "PROMPT: ") "Input: "))
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(input (minibuffer-with-setup-hook= (lambda () (kbd-macro-query t))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (read-from-minibuffer prompt))))
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 (unless (string=3D "" input) (insert = input))))
=C2=A0 =C2=A0 (global-set-key (kbd "C-x Q") 'my-= macro-query)

If you attempt to start a keyboard macro via F3, then a= ttempt 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 resu= lt, it appears we can't use the above method to
read and set variabl= es during keyboard macro creation. I'm not sure if
this is intention= al 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.


I= n GNU Emacs 29.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.38,
ca= iro version 1.17.8)
Windowing system distributor 'Microsoft Corporat= ion', version 11.0.12010000
System Description: Arch Linux

Co= nfigured using:
=C2=A0'configure --with-x-toolkit=3Dgtk3 --with-nati= ve-compilation=3Daot
=C2=A0--sysconfdir=3D/etc --prefix=3D/usr --libexec= dir=3D/usr/lib
=C2=A0--with-tree-sitter --localstatedir=3D/var --with-ca= iro
=C2=A0--disable-build-details --with-harfbuzz --with-libsystemd
= =C2=A0--with-modules 'CFLAGS=3D-march=3Dx86-64 -mtune=3Dgeneric -O2 -pi= pe -fno-plt
=C2=A0-fexceptions -Wp,-D_FORTIFY_SOURCE=3D2 -Wformat -Werro= r=3Dformat-security
=C2=A0-fstack-clash-protection -fcf-protection -g=C2=A0-ffile-prefix-map=3D/build/emacs/src=3D/usr/src/debug/emacs -flto=3D= auto'
=C2=A0'LDFLAGS=3D-Wl,-O1,--sort-common,--as-needed,-z,relr= o,-z,now -flto=3Dauto'
=C2=A0'CXXFLAGS=3D-march=3Dx86-64 -mtune= =3Dgeneric -O2 -pipe -fno-plt -fexceptions
=C2=A0-Wp,-D_FORTIFY_SOURCE= =3D2 -Wformat -Werror=3Dformat-security
=C2=A0-fstack-clash-protection -= fcf-protection -Wp,-D_GLIBCXX_ASSERTIONS -g
=C2=A0-ffile-prefix-map=3D/b= uild/emacs/src=3D/usr/src/debug/emacs -flto=3Dauto''

Configu= red features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS = HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSYSTEMD LIBXML2 M17N_FLT MODULES NATI= VE_COMP NOTIFY
INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TI= FF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XDBE XIM XINPUT2 XPM GTK3 ZL= IB

Important settings:
=C2=A0 value of $LANG: en_US.UTF-8
=C2= =A0 locale-coding-system: utf-8-unix

Major mode: ELisp/d

Mino= r modes in effect:
=C2=A0 global-git-commit-mode: t
=C2=A0 magit-auto= -revert-mode: t
=C2=A0 shell-dirtrack-mode: t
=C2=A0 marginalia-mode:= t
=C2=A0 override-global-mode: t
=C2=A0 vertico-mode: t
=C2=A0 wh= ich-key-mode: t
=C2=A0 server-mode: t
=C2=A0 global-eldoc-mode: t
= =C2=A0 eldoc-mode: t
=C2=A0 show-paren-mode: t
=C2=A0 electric-indent= -mode: t
=C2=A0 mouse-wheel-mode: t
=C2=A0 menu-bar-mode: t
=C2=A0= file-name-shadow-mode: t
=C2=A0 global-font-lock-mode: t
=C2=A0 font= -lock-mode: t
=C2=A0 blink-cursor-mode: t
=C2=A0 column-number-mode: = t
=C2=A0 line-number-mode: t
=C2=A0 transient-mark-mode: t
=C2=A0 = auto-composition-mode: t
=C2=A0 auto-encryption-mode: t
=C2=A0 auto-c= ompression-mode: t

Load-path shadows:
/home/surgo/.emacs.d/elpa/t= ransient-20231103.2312/transient hides /usr/share/emacs/29.1/lisp/transient=
/home/surgo/.emacs.d/elpa/seq-2.24/seq hides /usr/share/emacs/29.1/lisp= /emacs-lisp/seq

Features:
(shadow sort mail-extr emacsbug minibuf= -eldef thingatpt misearch
multi-isearch cl-print debug backtrace find-fu= nc mule-util shortdoc
help-fns radix-tree macros dired-aux cc-styles cc-= align cc-engine
cc-vars cc-defs magit-submodule magit-blame magit-stash = magit-reflog
magit-bisect magit-push magit-pull magit-fetch magit-clone = magit-remote
magit-commit magit-sequence magit-notes magit-worktree magi= t-tag
magit-merge magit-branch magit-reset magit-files magit-refs magit-= status
magit magit-repos magit-apply magit-wip magit-log which-func imen= u
magit-diff smerge-mode diff diff-mode git-commit log-edit message
s= endmail yank-media puny dired dired-loaddefs rfc822 mml mml-sec epa
deri= ved epg rfc6068 epg-config gnus-util text-property-search time-date
mm-d= ecode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 mm-util
iet= f-drums mail-prsvr mailabbrev mail-utils gmm-utils mailheader
pcvs-util = add-log magit-core magit-autorevert autorevert filenotify
magit-margin m= agit-transient magit-process with-editor comp comp-cstr
warnings icons r= x shell pcomplete comint ansi-osc ring ansi-color
magit-mode transient m= agit-git magit-base magit-section format-spec
cursor-sensor crm dash mar= ginalia edmacro kmacro use-package-bind-key
bind-key easy-mmode vertico = compat diminish which-key cl-extra help-mode
use-package-diminish use-pa= ckage-core tango-dark-theme server
magit-autoloads pcase git-commit-auto= loads magit-section-autoloads
dash-autoloads marginalia-autoloads projec= tile-autoloads
transient-autoloads vertico-autoloads with-editor-autoloa= ds info
compat-autoloads seq-autoloads package browse-url url url-proxy<= br>url-privacy url-expand url-methods url-history url-cookie
generate-li= sp-file url-domsuf url-util mailcap url-handlers url-parse
auth-source c= l-seq eieio eieio-core cl-macs password-cache json subr-x
map byte-opt g= v bytecomp byte-compile url-vars cl-loaddefs cl-lib rmc
iso-transl toolt= ip cconv eldoc paren electric uniquify ediff-hook
vc-hooks lisp-float-ty= pe elisp-mode mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd= fontset image regexp-opt fringe
tabulated-list replace newcomment text-= mode lisp-mode prog-mode register
page tab-bar menu-bar rfn-eshadow isea= rch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax fon= t-core term/tty-colors
frame minibuffer nadvice seq simple cl-generic in= donesian philippine
cham georgian utf-8-lang misc-lang vietnamese tibeta= n thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romani= an slovak czech
european ethiopic indian cyrillic chinese composite emoj= i-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help abbrev = obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-f= ace macroexp
files window text-properties overlay sha1 md5 base64 format= env
code-pages mule custom widget keymap hashtable-print-readable backq= uote
threads dbusbind inotify lcms2 dynamic-setting system-font-setting<= br>font-render-setting cairo move-toolbar gtk x-toolkit xinput2 x multi-tty=
make-network-process native-compile emacs)

Memory information:((conses 16 241723 51274)
=C2=A0(symbols 48 17022 0)
=C2=A0(strings= 32 64370 2962)
=C2=A0(string-bytes 1 2928754)
=C2=A0(vectors 16 4185= 6)
=C2=A0(vector-slots 8 758358 34977)
=C2=A0(floats 8 161 322)
= =C2=A0(intervals 56 1802 323)
=C2=A0(buffers 984 17))
--000000000000227a8306099bb283-- From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 08 02:34:02 2023 Received: (at 66998) by debbugs.gnu.org; 8 Nov 2023 07:34:02 +0000 Received: from localhost ([127.0.0.1]:43927 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0d4b-0008PH-NN for submit@debbugs.gnu.org; Wed, 08 Nov 2023 02:34:02 -0500 Received: from mail-pg1-x535.google.com ([2607:f8b0:4864:20::535]:43020) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0cGf-00072B-8g for 66998@debbugs.gnu.org; Wed, 08 Nov 2023 01:42:26 -0500 Received: by mail-pg1-x535.google.com with SMTP id 41be03b00d2f7-5b9390d6bd3so364350a12.0 for <66998@debbugs.gnu.org>; Tue, 07 Nov 2023 22:41:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699425700; x=1700030500; darn=debbugs.gnu.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=jjrsXxtSyXj59KAnm4SZugmAx4TTCkaYWxermQHopL8=; b=KH3qcy0CwFE2+ZHjUW1f3bsR3Nwtz65cKnPWzkApkAXZc68pmFfj4Hj5fYAt+XLXrK n53g/H3tunsKmQni2YLkNWERrZ9CKD/qPKwM0dLSK/MJEhJMb4+s+gaiR5uogqr+qurT 5mb0XqBeu6Tn/fOk/82lSOUBdUPWpdrppZ7gb29OHlTtGRiJh57b/4pGofoUmrJhhwFA SCueM4HKT7fp+apHk7QV3+T+xldS0a5tS+NPtE1wRE6z7XrMQ3J4Szj5/CLwBFJ4JsWX VVdkDYXB9DaTwQn2YaYkfHOvUM6pg+FgTuZTeOK+FO/QimODkX0N6PcajotwOWRF2jbI s/CQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699425700; x=1700030500; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=jjrsXxtSyXj59KAnm4SZugmAx4TTCkaYWxermQHopL8=; b=aMK2J/BbbohVhrDVLna2/WogkN3m9lVQ2KB4vlvh9DtCgCHS8HhINMQ82dKPPUf1M8 KnunZyMkdgX3dTbAupkOFPikw8emfBlvChLaZ48geEilO9ksDiqg3hyO/felGct27sHy cfzdqOMJaBo82UvBoe/2qIWPZKFCxEk75LWOzZcX5Q1PGdu3NYWQ+90riMP5WC7c8Z0N NCbAUrwVRu3D03akhVTYVxcwzzRJ2VB/38dBW5EU+gMnJrtR32QmNp+QXA8nsu91Uom2 UVX5XBSfblAGW5mrb9kOMgJF2RTnXLpde8mYsoJQibR6Z4YzWsYio9ZsNYrfo+iTnkmL lTsQ== X-Gm-Message-State: AOJu0Yxp/52o38zNhGDFs1xCJCyeHfS984EcK6iNGUlpUBq/ApI95BT4 KKM1/g+EfbMGl4J+dST8AqvyTE37NyKjUkx9d1F2Zw== X-Google-Smtp-Source: AGHT+IGLOJy+FELcDMtC60DDqYO2zSq05pnANGsB1D+zAG86qkEE9Yg3TGaMn9WguO5/o65X6yQLSYT9jliSJizfJ6I= X-Received: by 2002:a17:90a:1157:b0:27d:2d2f:9ca2 with SMTP id d23-20020a17090a115700b0027d2d2f9ca2mr6410052pje.24.1699425700266; Tue, 07 Nov 2023 22:41:40 -0800 (PST) MIME-Version: 1.0 From: Morgon Kanter Date: Wed, 8 Nov 2023 01:41:29 -0500 Message-ID: Subject: Further information To: 66998@debbugs.gnu.org Content-Type: multipart/alternative; boundary="0000000000002fc8ad06099e6170" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 66998 X-Mailman-Approved-At: Wed, 08 Nov 2023 02:34:00 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --0000000000002fc8ad06099e6170 Content-Type: text/plain; charset="UTF-8" Some additional information -- It works the same whether you use kbd-macro-query or recursive-edit in the hook. Adding exit-recursive-edit to the minibuffer-exit hook doesn't help. To actually finish typing in the minibuffer, it appears like you need to do M-C-c, and then you can press enter to finish. -- Morgon --0000000000002fc8ad06099e6170 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Some additional information --

It works= the same whether you use kbd-macro-query or recursive-edit in the hook. Ad= ding exit-recursive-edit to the minibuffer-exit hook doesn't help.

To actually finish typing in the minibuffer, it appear= s like you need to do M-C-c, and then you can press enter to finish.
<= div>
-- Morgon
--0000000000002fc8ad06099e6170-- From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 08 07:37:53 2023 Received: (at 66998) by debbugs.gnu.org; 8 Nov 2023 12:37:53 +0000 Received: from localhost ([127.0.0.1]:44179 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0hoe-00055O-UJ for submit@debbugs.gnu.org; Wed, 08 Nov 2023 07:37:53 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:33564) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0hod-00055C-BL for 66998@debbugs.gnu.org; Wed, 08 Nov 2023 07:37:51 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r0hnu-0007Fe-VZ; Wed, 08 Nov 2023 07:37:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=Fs4biMNtyW+pp0KCRtKNDDfUTGzKjS4rBKRyxqlE9Rs=; b=pnwgTNbjTaM7 IVd53AH8Rn+LJrc51JUExJIethpv+0pAqbCLIAHxnI1HPDqeqWNlCWR834lyOqRRDAG5JmbtY7Pwh 5THJXOEZPvHKq82XvoIlulDS2fHltubZuJNGRLtawReFXhdThR/vek1u2EKVfZ3XTuHWaFThF89qA 9lAfpFFsNvAeQYFI0bXPR7ukGHEOglv8KPaeHZTmekrE8UoADNCMZXgOufX/X3cZN4BRMkabSaPj/ 6LfJF8wKp2w9yOnnyKmtBJErjHHwSJW9YnXFZAaAm978Y6vDc2jbCCQtTMsfCnKngQroLEahWwHXj cRUT2J2FERuFPeLwy1djzQ==; Date: Wed, 08 Nov 2023 14:36:56 +0200 Message-Id: <83msvo1kwn.fsf@gnu.org> From: Eli Zaretskii To: Morgon Kanter , Alan Mackenzie In-Reply-To: (message from Morgon Kanter on Tue, 7 Nov 2023 22:29:22 -0500) Subject: Re: bug#66998: 29.1; Regression for recursive keyboard macros + minibuffers in (I think) Emacs 28 References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 66998 Cc: 66998@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Morgon Kanter > Date: Tue, 7 Nov 2023 22:29:22 -0500 > > I believe there is a regression, but possibly intentional, caused by this patch: > https://github.com/emacs-mirror/emacs/commit/203e61ff837128b397eb313a5bb1b703f0eae0ec > > 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: > 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. Alan, can you please look into this? From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 08 07:54:05 2023 Received: (at 66998) by debbugs.gnu.org; 8 Nov 2023 12:54:05 +0000 Received: from localhost ([127.0.0.1]:44187 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0i4K-0005Yr-Vk for submit@debbugs.gnu.org; Wed, 08 Nov 2023 07:54:05 -0500 Received: from mail.muc.de ([193.149.48.3]:12670) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0i4G-0005YG-Gy for 66998@debbugs.gnu.org; Wed, 08 Nov 2023 07:54:03 -0500 Received: (qmail 62127 invoked by uid 3782); 8 Nov 2023 13:53:14 +0100 Received: from acm.muc.de (p4fe1584b.dip0.t-ipconnect.de [79.225.88.75]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 08 Nov 2023 13:53:14 +0100 Received: (qmail 19838 invoked by uid 1000); 8 Nov 2023 12:53:13 -0000 Date: Wed, 8 Nov 2023 12:53:13 +0000 To: Eli Zaretskii Subject: Re: bug#66998: 29.1; Regression for recursive keyboard macros + minibuffers in (I think) Emacs 28 Message-ID: References: <83msvo1kwn.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83msvo1kwn.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 66998 Cc: 66998@debbugs.gnu.org, Morgon Kanter X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Eli. On Wed, Nov 08, 2023 at 14:36:56 +0200, Eli Zaretskii wrote: > > From: Morgon Kanter > > Date: Tue, 7 Nov 2023 22:29:22 -0500 > > I believe there is a regression, but possibly intentional, caused by this patch: > > https://github.com/emacs-mirror/emacs/commit/203e61ff837128b397eb313a5bb1b703f0eae0ec > > 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: > > 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. > Alan, can you please look into this? Will do. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 09 12:38:10 2023 Received: (at 66998) by debbugs.gnu.org; 9 Nov 2023 17:38:10 +0000 Received: from localhost ([127.0.0.1]:48666 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r18yo-0000fM-02 for submit@debbugs.gnu.org; Thu, 09 Nov 2023 12:38:10 -0500 Received: from mail.muc.de ([193.149.48.3]:33868) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r18ym-0000fA-9C for 66998@debbugs.gnu.org; Thu, 09 Nov 2023 12:38:09 -0500 Received: (qmail 52947 invoked by uid 3782); 9 Nov 2023 18:37:23 +0100 Received: from acm.muc.de (p4fe15b72.dip0.t-ipconnect.de [79.225.91.114]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 09 Nov 2023 18:37:22 +0100 Received: (qmail 28317 invoked by uid 1000); 9 Nov 2023 17:37:22 -0000 Date: Thu, 9 Nov 2023 17:37:22 +0000 To: Morgon Kanter Subject: Re: bug#66998: 29.1; Regression for recursive keyboard macros + minibuffers in (I think) Emacs 28 Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 66998 Cc: acm@muc.de, eliz@gnu.org, 66998@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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). From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 09 13:55:37 2023 Received: (at 66998) by debbugs.gnu.org; 9 Nov 2023 18:55:37 +0000 Received: from localhost ([127.0.0.1]:48742 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r1ABk-0005KY-Jq for submit@debbugs.gnu.org; Thu, 09 Nov 2023 13:55:37 -0500 Received: from mail-pg1-x52c.google.com ([2607:f8b0:4864:20::52c]:45379) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r19yx-0004te-4s for 66998@debbugs.gnu.org; Thu, 09 Nov 2023 13:42:25 -0500 Received: by mail-pg1-x52c.google.com with SMTP id 41be03b00d2f7-5b99bfca064so930134a12.3 for <66998@debbugs.gnu.org>; Thu, 09 Nov 2023 10:41:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699555298; x=1700160098; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ZTgR9D7ML9dz19Lu4DfzaYd/RigEb4s9WQHXd8oZMZk=; b=mZ/Jd3zlVIfoeb+w4PX6b0fBxVu/sqoc6jtjIquQOc5/rogOzWGWdi2oC+yqgZRhvs qMwuG40gtjbGMd1MkKpV2yIR1BOsOHVZqmUZxkvb/RmzrThH3vXdww5XxLoX/eTBqFPN dcEdqRo6huPHTfh7P3HeHHGYtV2okIBPRnWxTymTZuUEvbDvWUD3SQqXW/MqNGebuyEZ uToOAKo8rr1/mK9K6V/d+simcq9jcFkM5zTK1ZrRgIgOFRzJU5ZNIpTVSY8iWRI5njAI PZm0T3e2R8UWorFId1OLNHLLsopJImQJVQ+VV0TLKRfrmIH2PF4AcEJ9/FpBYHlCr5Mt ipAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699555298; x=1700160098; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ZTgR9D7ML9dz19Lu4DfzaYd/RigEb4s9WQHXd8oZMZk=; b=tA6/K8EvzBQdDLkFhU4+nup3UPd+A+j/FuudKWHkYH2SZGa2R8h5doQRTDVBS978yu RiHuqmqzSucC6dK0gfHu0+A2WR3mipNKhBL3GCJlTC8iKL5ZzLmbpjBKgWj5gnPyqxk3 5LV49dIFfgC436I6xnMkMITBE39n1H+JOUfVVUmDjtfdkzaudmuTvbrjvLnSP4xP2LF9 GaFUkEydg14M4Si27LAGMh+x+tNcRl6yMDwE8oJksYnWXukgEUMVwqcd6VeJp0l/gf1e tJk/QFX0brCrXsb3sUZWij//dTKX2l6NLVxrUDnOB6Ta8x/pBw9qzDPOS3gD8O+eYuv6 Mojw== X-Gm-Message-State: AOJu0Yxz42Spm/MdCPGBh5/Tz+rgxM0bO1rYfl0+7Gxu2ZhpbQRELZjC uQta0RIBRVSiBIhN+4CC4VL+lJQpu4GIV7Is X-Google-Smtp-Source: AGHT+IGsNReWpxsBSe//xDHgZ+BygPBiuGy5j62YaO9oewnxqE6OPCVclvY+mMvi6U0RPqMEFqXPjLGfNlOBWCJcv8o= X-Received: by 2002:a17:90b:1b0b:b0:280:a464:e9d4 with SMTP id nu11-20020a17090b1b0b00b00280a464e9d4mr2527928pjb.8.1699555297835; Thu, 09 Nov 2023 10:41:37 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Morgon Kanter Date: Thu, 9 Nov 2023 13:41:26 -0500 Message-ID: Subject: Re: bug#66998: 29.1; Regression for recursive keyboard macros + minibuffers in (I think) Emacs 28 To: Alan Mackenzie Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 66998 X-Mailman-Approved-At: Thu, 09 Nov 2023 13:55:34 -0500 Cc: eliz@gnu.org, 66998@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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. From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 10 13:58:22 2023 Received: (at 66998) by debbugs.gnu.org; 10 Nov 2023 18:58:22 +0000 Received: from localhost ([127.0.0.1]:50868 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r1Whx-0004Wg-NA for submit@debbugs.gnu.org; Fri, 10 Nov 2023 13:58:22 -0500 Received: from mail.muc.de ([193.149.48.3]:54102) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r1Whg-0004Vr-Pj for 66998@debbugs.gnu.org; Fri, 10 Nov 2023 13:58:20 -0500 Received: (qmail 94940 invoked by uid 3782); 10 Nov 2023 19:57:18 +0100 Received: from acm.muc.de (p4fe158a9.dip0.t-ipconnect.de [79.225.88.169]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 10 Nov 2023 19:57:18 +0100 Received: (qmail 25064 invoked by uid 1000); 10 Nov 2023 18:57:17 -0000 Date: Fri, 10 Nov 2023 18:57:17 +0000 To: Morgon Kanter Subject: Re: bug#66998: 29.1; Regression for recursive keyboard macros + minibuffers in (I think) Emacs 28 Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 66998 Cc: eliz@gnu.org, 66998@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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). From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 12 22:12:57 2023 Received: (at 66998) by debbugs.gnu.org; 13 Nov 2023 03:12:57 +0000 Received: from localhost ([127.0.0.1]:57270 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r2NNc-0008ET-Kn for submit@debbugs.gnu.org; Sun, 12 Nov 2023 22:12:57 -0500 Received: from mail-ot1-x32a.google.com ([2607:f8b0:4864:20::32a]:56348) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r2FAu-0005gL-0g for 66998@debbugs.gnu.org; Sun, 12 Nov 2023 13:27:15 -0500 Received: by mail-ot1-x32a.google.com with SMTP id 46e09a7af769-6cf65093780so2280335a34.0 for <66998@debbugs.gnu.org>; Sun, 12 Nov 2023 10:26:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699813585; x=1700418385; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=iNHaOJBqNTCI14rAHVIpf5rqlbcbAfPBoB3eZvqxYFM=; b=kSbSIclPGeBkS/as9qlEslBe3nOoI4ZrXLUHbt6AjB5pRy4i0f2DUi0jwVDoxjdkXb Wney2cI/TKrd7t8EC8u3SuaBsONRVg/9MQVU1EaLjrgswiVpA/UCbFPtfa1nLilrF3sB fDGIOLvbgfFkN+He+Nxd6Rh49gLc/dzPZOFtuq4njQ5DozKszvBF80TxvDKNuKKcd1Dh ncSgTmy0axdkwzuEeGmdvlpRFfZEbxLaWPWYsKDVUj1dGgF/HEqinMR1QAUiU3/GdAl9 /2Bq0B3hV6LC4anCN/QRkML5yDUm6OHHwwrcAIvpS+wlPfX9r+4rBAaNuI7sZVh8GYV6 EVxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699813585; x=1700418385; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=iNHaOJBqNTCI14rAHVIpf5rqlbcbAfPBoB3eZvqxYFM=; b=TfDOxvC9lGvZV9EiWglMpt1q3AqYzfnz+PDbDhZa35hh2UrZ5fCdpE0XplbmF2YJhE ENIeqkW4mCv+f8Bavq8FnYPtddbQl4AHPia44DnNJzPNab84Pn+QKBStz6DaWUidKB1k atnT9H9Dt36ngsODyV1LYJG/h41lRtoJz+EYKhmYRvCZKxNEfoRC0jDDeSbc4O/VHfLk RJ0YgY5Oium733niHRhTkMHYfPiQl7q8dj30Z3Sn4PhhaHaBw1RYdpeca4jmfLj6jcig 4WTcEGrisW3rpBEWpNXUEt9+Z17lZZLiXgehS75+iqK9D6HzKBJKvVD9+CfmNtkBpaDN vF8Q== X-Gm-Message-State: AOJu0Yyty/SXzXJgX/7/bgrc3DwWuDdQBaQhKjkfg7ZLT21/QSPeOW6O E7T6NZGP0ss99UUAcZwOXoD602CM69oZzcPF X-Google-Smtp-Source: AGHT+IEgvrH/q9vN/POuYyst11IJwElrTkt/hdvl5nKT1GonU7t+aNdeuv6oMVWW4NfDFRgcFNmXprKMWR7yYovngYI= X-Received: by 2002:a05:6871:5289:b0:1d6:cbcd:80f8 with SMTP id hu9-20020a056871528900b001d6cbcd80f8mr7564088oac.54.1699813584982; Sun, 12 Nov 2023 10:26:24 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Morgon Kanter Date: Sun, 12 Nov 2023 13:26:13 -0500 Message-ID: Subject: Re: bug#66998: 29.1; Regression for recursive keyboard macros + minibuffers in (I think) Emacs 28 To: Alan Mackenzie Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 66998 X-Mailman-Approved-At: Sun, 12 Nov 2023 22:12:50 -0500 Cc: eliz@gnu.org, 66998@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > > 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 From debbugs-submit-bounces@debbugs.gnu.org Fri May 31 06:16:59 2024 Received: (at 66998) by debbugs.gnu.org; 31 May 2024 10:17:00 +0000 Received: from localhost ([127.0.0.1]:53270 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sCzJj-0004nb-J7 for submit@debbugs.gnu.org; Fri, 31 May 2024 06:16:59 -0400 Received: from mail.muc.de ([193.149.48.3]:23940) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sCzJf-0004nE-OX for 66998@debbugs.gnu.org; Fri, 31 May 2024 06:16:58 -0400 Received: (qmail 51262 invoked by uid 3782); 31 May 2024 12:16:38 +0200 Received: from muc.de (p4fe154df.dip0.t-ipconnect.de [79.225.84.223]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 31 May 2024 12:16:37 +0200 Received: (qmail 8265 invoked by uid 1000); 31 May 2024 10:16:37 -0000 Date: Fri, 31 May 2024 10:16:37 +0000 To: control@debbugs.gnu.org, Morgon Kanter Subject: Re: bug#66998: 29.1; Regression for recursive keyboard macros + minibuffers in (I think) Emacs 28 Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 66998 Cc: acm@muc.de, eliz@gnu.org, 66998@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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). From unknown Sat Jun 21 12:24:35 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Fri, 28 Jun 2024 11:24:10 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator