Subject: Re: bug#48603: 27.2; [PATCH] Quit minibuffers without aborting kmacros

From: <[email-masked]>
Date: Wed, 01 Sep 2021 08:58:04 +0200

"Basil L. Contovounesios" via "Bug reports for GNU Emacs, the Swiss army
knife of text editors" <[email-masked]> writes:

> Lars Ingebrigtsen [2021-07-20 14:37 +0200] wrote:
>
>> <[email-masked]> writes:
>>
>>> Good idea, attaching a revised patch (which also adds two NEWS entries.)
>>
>> Sorry; I forgot all about this.  I've now re-read and tested the patch,
>> and it seems to work fine for me, so I've pushed it to Emacs 28.
>
> Thanks, but given the following file quit.el, which is distilled from
> the Ivy package's batch-run test suite:
> [...]
> IOW, it's no longer possible to catch the quit around execute-kbd-macro.
> I tried wrapping it in (catch 'exit ...) as well, but to no avail.
> Surely it should always be possible to catch a quit condition from Lisp?
>
In order to make C-g from a minibuffer not abort kmacro execution,
execute-kbd-macro was made to catch the minibuffer-quit condition,
handle it with the default error handler (command-error-function) and
continue with kmacro execution.

In batch mode, this error handler kills Emacs with status 255. Please
consider the attached patch, which avoids killing for the
minibuffer-quit condition.

However, even with this patch, slight change in behaviour still remains:
- In Emacs 27, C-g in the minibuffer is bound to abort-recursive-edit
  which makes execute-kbd-macro signal an error (a quit).
- In Emacs 28, C-g is bound to abort-minibuffers. This command will not
  make execute-kbd-macro signal any errors.
I hope this change in default behaviour is acceptable, otherwise it
wouldn't be possible to have C-g continue with kmacro execution. For
test suites, you can get back the old behaviour with

(define-key minibuffer-local-map "\C-g" #'abort-recursive-edit)

Sorry for late reply,
best regards.

From dac1a0ccca5678dda4b331d1a788a8432c9a7a03 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Miha=20Rihtar=C5=A1i=C4=8D?= <[email-masked]>
Date: Wed, 1 Sep 2021 08:32:25 +0200
Subject: [PATCH] In batch mode, avoid killing Emacs with C-g in the minibuffer

* src/keyboard.c (Fcommand_error_default_function): Don't kill emacs
when handling the minibuffer-quit condition (bug#48603).
---
 src/keyboard.c | 37 +++++++++++++++++++------------------
 1 file changed, 19 insertions(+), 18 deletions(-)

diff --git a/src/keyboard.c b/src/keyboard.c
index 81ff9df153..6a8c33ae3b 100644
--- a/src/keyboard.c
+++ b/src/keyboard.c
@@ -1009,25 +1009,28 @@ DEFUN ("command-error-default-function", Fcommand_error_default_function,
   (Lisp_Object data, Lisp_Object context, Lisp_Object signal)
 {
   struct frame *sf = SELECTED_FRAME ();
-  Lisp_Object conditions;
+  Lisp_Object conditions = Fget (XCAR (data), Qerror_conditions);
+  int is_minibuffer_quit = !NILP (Fmemq (Qminibuffer_quit, conditions));
 
   CHECK_STRING (context);
 
   /* If the window system or terminal frame hasn't been initialized
-     yet, or we're not interactive, write the message to stderr and exit.  */
-  if (!sf->glyphs_initialized_p
-	   /* The initial frame is a special non-displaying frame. It
-	      will be current in daemon mode when there are no frames
-	      to display, and in non-daemon mode before the real frame
-	      has finished initializing.  If an error is thrown in the
-	      latter case while creating the frame, then the frame
-	      will never be displayed, so the safest thing to do is
-	      write to stderr and quit.  In daemon mode, there are
-	      many other potential errors that do not prevent frames
-	      from being created, so continuing as normal is better in
-	      that case.  */
-	   || (!IS_DAEMON && FRAME_INITIAL_P (sf))
-	   || noninteractive)
+     yet, or we're not interactive, write the message to stderr and exit.
+     Don't do this for the minibuffer-quit condition.  */
+  if (!is_minibuffer_quit
+      && (!sf->glyphs_initialized_p
+	  /* The initial frame is a special non-displaying frame. It
+	     will be current in daemon mode when there are no frames
+	     to display, and in non-daemon mode before the real frame
+	     has finished initializing.  If an error is thrown in the
+	     latter case while creating the frame, then the frame
+	     will never be displayed, so the safest thing to do is
+	     write to stderr and quit.  In daemon mode, there are
+	     many other potential errors that do not prevent frames
+	     from being created, so continuing as normal is better in
+	     that case.  */
+	  || (!IS_DAEMON && FRAME_INITIAL_P (sf))
+	  || noninteractive))
     {
       print_error_message (data, Qexternal_debugging_output,
 			   SSDATA (context), signal);
@@ -1036,12 +1039,10 @@ DEFUN ("command-error-default-function", Fcommand_error_default_function,
     }
   else
     {
-      conditions = Fget (XCAR (data), Qerror_conditions);
-
       clear_message (1, 0);
       message_log_maybe_newline ();
 
-      if (!NILP (Fmemq (Qminibuffer_quit, conditions)))
+      if (is_minibuffer_quit)
 	{
 	  Fding (Qt);
 	}
-- 
2.32.0