all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: miha--- via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: "Basil L. Contovounesios" <contovob@tcd.ie>,
	Lars Ingebrigtsen <larsi@gnus.org>
Cc: 48603@debbugs.gnu.org
Subject: bug#48603: 27.2; [PATCH] Quit minibuffers without aborting kmacros
Date: Wed, 01 Sep 2021 08:58:04 +0200	[thread overview]
Message-ID: <87o89cdbpf.fsf@miha-pc> (raw)
In-Reply-To: <87czqbzo5g.fsf@tcd.ie>


[-- Attachment #1.1: Type: text/plain, Size: 1789 bytes --]

"Basil L. Contovounesios" via "Bug reports for GNU Emacs, the Swiss army
knife of text editors" <bug-gnu-emacs@gnu.org> writes:

> Lars Ingebrigtsen [2021-07-20 14:37 +0200] wrote:
>
>> <miha@kamnitnik.top> 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.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: 0001-In-batch-mode-avoid-killing-Emacs-with-C-g-in-the-mi.patch --]
[-- Type: text/x-patch, Size: 3266 bytes --]

From dac1a0ccca5678dda4b331d1a788a8432c9a7a03 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Miha=20Rihtar=C5=A1i=C4=8D?= <miha@kamnitnik.top>
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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]

  parent reply	other threads:[~2021-09-01  6:58 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-23 14:36 bug#48603: 27.2; [PATCH] Quit minibuffers without aborting kmacros miha--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-05-25 19:54 ` Lars Ingebrigtsen
2021-05-25 21:34   ` miha--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-07-20 12:37     ` Lars Ingebrigtsen
2021-08-17 22:45       ` Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-08-18 14:55         ` Lars Ingebrigtsen
2021-09-01  6:58         ` miha--- via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2021-09-01  8:11           ` Lars Ingebrigtsen
2021-09-03 17:53           ` Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-09-07 15:11       ` miha--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-09-08  7:40         ` Lars Ingebrigtsen

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

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

  git send-email \
    --in-reply-to=87o89cdbpf.fsf@miha-pc \
    --to=bug-gnu-emacs@gnu.org \
    --cc=48603@debbugs.gnu.org \
    --cc=contovob@tcd.ie \
    --cc=larsi@gnus.org \
    --cc=miha@kamnitnik.top \
    /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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.