GNU logs - #49700, boring messages


Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#49700: 27.2; [PATCH] Refactor minibuffer aborting
Resent-From: miha@HIDDEN
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 22 Jul 2021 23:04:01 +0000
Resent-Message-ID: <handler.49700.B.162699502326065 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: report 49700
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: 49700 <at> debbugs.gnu.org
Cc: Alan Mackenzie <acm@HIDDEN>
X-Debbugs-Original-To: bug-gnu-emacs@HIDDEN
Received: via spool by submit <at> debbugs.gnu.org id=B.162699502326065
          (code B ref -1); Thu, 22 Jul 2021 23:04:01 +0000
Received: (at submit) by debbugs.gnu.org; 22 Jul 2021 23:03:43 +0000
Received: from localhost ([127.0.0.1]:41806 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1m6hjC-0006mI-JT
	for submit <at> debbugs.gnu.org; Thu, 22 Jul 2021 19:03:43 -0400
Received: from lists.gnu.org ([209.51.188.17]:33840)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <miha@HIDDEN>) id 1m6hj8-0006m7-Fr
 for submit <at> debbugs.gnu.org; Thu, 22 Jul 2021 19:03:41 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:49362)
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <miha@HIDDEN>)
 id 1m6hj8-0005ax-7q
 for bug-gnu-emacs@HIDDEN; Thu, 22 Jul 2021 19:03:38 -0400
Received: from kamnitnik.top ([2001:19f0:5001:bf2:5400:2ff:fee0:2626]:35322
 helo=mail.kamnitnik.top)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <miha@HIDDEN>)
 id 1m6hj5-0007mV-Jd
 for bug-gnu-emacs@HIDDEN; Thu, 22 Jul 2021 19:03:37 -0400
Received: from localhost (unknown [IPv6:2a00:ee2:e04:9300:e609:6c46:d026:8c47])
 by mail.kamnitnik.top (Postfix) with ESMTPSA id B4D12BCF6D;
 Thu, 22 Jul 2021 23:03:30 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kamnitnik.top;
 s=mail; t=1626995010;
 bh=KrUF6u19LOCnJlB96Rimph7y4gPGgKwWkMNFdwN+XoY=;
 h=From:To:Cc:Subject:Date:From;
 b=Nk1PG1+xZzRU81uGes1jOiGFxfW+nEpcBg75p+ir9HVlIeYuTllNA9TBgisjogBSO
 FcuEHwG7ulJYYXRljF7Em2jqwgKpfc45MHZaTuIg7JWr/I1dXUVXjBafAHz/7QbiB0
 dIXCBZv6XYuS5xj3k2qe3bt7tgMcUsJj55KRYRVdGnVFKTALM78/x0j0N24Zg7aC4q
 fZXHfliEbLBedBQWoQO9Q9Bd6YD//LWxPoPsAxI6f9myenOVsq43WIZny8qxVJiTeY
 lFOBx0oqAEZbyTdinn3wS8t/KtXAaOgyhdSpAygqNAI0lhc/tEN3PI/Sw0Eovlkckh
 HwTy2fgaSrFXg==
From: miha@HIDDEN
Date: Fri, 23 Jul 2021 01:05:41 +0200
Message-ID: <87pmvaar0a.fsf@miha-pc>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="==-=-=";
 micalg=pgp-sha256; protocol="application/pgp-signature"
Received-SPF: pass client-ip=2001:19f0:5001:bf2:5400:2ff:fee0:2626;
 envelope-from=miha@HIDDEN; helo=mail.kamnitnik.top
X-Spam_score_int: 9
X-Spam_score: 0.9
X-Spam_bar: /
X-Spam_report: (0.9 / 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, FROM_SUSPICIOUS_NTLD=0.499,
 FROM_SUSPICIOUS_NTLD_FP=0.546, PDS_OTHER_BAD_TLD=1.997, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001 autolearn=no autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 1.6 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview: The attached patch removes special handling of the 'exit tag
 from internal_catch. This special handling was introduced by Alan in commit
 Sun Jan 10 20:32:40 2021 +0000 (c7c154bb5756e0ae71d342c5d8aabf7 [...] 
 Content analysis details:   (1.6 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -2.3 RCVD_IN_DNSWL_MED      RBL: Sender listed at https://www.dnswl.org/,
 medium trust [209.51.188.17 listed in list.dnswl.org]
 2.0 PDS_OTHER_BAD_TLD      Untrustworthy TLDs
 [URI: kamnitnik.top (top)]
 0.9 SPF_FAIL               SPF: sender does not match SPF record (fail)
 [SPF failed: Please see http://www.openspf.org/Why?s=mfrom;
 id=miha%40kamnitnik.top; ip=209.51.188.17; r=debbugs.gnu.org]
 -0.0 SPF_HELO_PASS          SPF: HELO matches SPF record
 -0.0 RCVD_IN_MSPIKE_H4      RBL: Very Good reputation (+4)
 [209.51.188.17 listed in wl.mailspike.net]
 0.5 FROM_SUSPICIOUS_NTLD_FP From abused NTLD
 0.5 FROM_SUSPICIOUS_NTLD   From abused NTLD
 -0.0 RCVD_IN_MSPIKE_WL      Mailspike good senders
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.1 (/)

--==-=-=
Content-Type: multipart/mixed; boundary="=-=-="

--=-=-=
Content-Type: text/plain

The attached patch removes special handling of the 'exit tag from
internal_catch.  This special handling was introduced by Alan in commit
Sun Jan 10 20:32:40 2021 +0000
(c7c154bb5756e0ae71d342c5d8aabf725877f186), hence me CC-ing him.

It also exposes Vminibuffer_list to lisp through the new function
Fminibuffer_alist.


--=-=-=
Content-Type: text/x-patch
Content-Disposition: inline;
 filename=0001-Refactor-minibuffer-aborting.patch
Content-Transfer-Encoding: quoted-printable

From=20498dbfbd9e527183fce34e548b7362e5db1b25bf Mon Sep 17 00:00:00 2001
From: =3D?UTF-8?q?Miha=3D20Rihtar=3DC5=3DA1i=3DC4=3D8D?=3D <miha@kamnitnik.=
top>
Date: Thu, 22 Jul 2021 17:49:45 +0200
Subject: [PATCH] Refactor minibuffer aborting

* src/minibuf.c (Finnermost_minibuffer_p): Remove.  Use the new
function `minibuffer-alist' instead.

(Fminibuffer_innermost_command_loop_p): Remove.

(minibuf_c_loop_level): Remove, not needed anymore.

(Fminibuffer_alist): New function.

(Fabort_minibuffers): Re-implement this function in lisp.  To quit
multiple recursive edit levels, use the mechanism of throwing a
function value to 'exit.

* lisp/minibuffer.el (exit-minibuffer): Use `minibuffer-alist'.

* doc/lispref/minibuf.texi (Recursive Mini):
* etc/NEWS: Document new function `minibuffer-alist'.

* src/eval.c (internal_catch): Remove special handling of 'exit tag.
=2D--
 doc/lispref/minibuf.texi |  8 ++++
 etc/NEWS                 |  4 ++
 lisp/minibuffer.el       | 44 ++++++++++++++++++--
 src/eval.c               | 22 ----------
 src/lisp.h               |  1 -
 src/minibuf.c            | 89 ++++++++++------------------------------
 6 files changed, 74 insertions(+), 94 deletions(-)

diff --git a/doc/lispref/minibuf.texi b/doc/lispref/minibuf.texi
index 196dd99076..90e738f3ea 100644
=2D-- a/doc/lispref/minibuf.texi
+++ b/doc/lispref/minibuf.texi
@@ -2645,6 +2645,14 @@ Recursive Mini
 returns zero.
 @end defun
=20
+@defun minibuffer-alist
+Return an alist of all minibuffers and their recursion depths.  The
+car of each element is a minibuffer and the cdr is what the function
+@code{recursion-depth} would have returned after this minibuffer
+activation.  The number of elements of the returned list is equal to
+the current minibuffer depth.
+@end defun
+
 @defopt enable-recursive-minibuffers
 If this variable is non-@code{nil}, you can invoke commands (such as
 @code{find-file}) that use minibuffers even while the minibuffer is
diff --git a/etc/NEWS b/etc/NEWS
index 95218faa1b..364c1b814b 100644
=2D-- a/etc/NEWS
+++ b/etc/NEWS
@@ -3094,6 +3094,10 @@ The former is now declared obsolete.
 
 * Lisp Changes in Emacs 28.1
=20
++++
+** New function 'minibuffer-alist'
+Returns an alist of all minibuffers and their recursion depths.
+
 +++
 *** New function 'split-string-shell-command'.
 This splits a shell command string into separate components,
diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 1578ab8e1e..702e7e105d 100644
=2D-- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -2315,10 +2315,11 @@ exit-minibuffer
   "Terminate this minibuffer argument."
   (interactive)
   (when (minibufferp)
=2D    (when (not (minibuffer-innermost-command-loop-p))
=2D      (error "%s" "Not in most nested command loop"))
=2D    (when (not (innermost-minibuffer-p))
=2D      (error "%s" "Not in most nested minibuffer")))
+    (let ((minibufs (minibuffer-alist)))
+      (when (not (eq (current-buffer) (caar minibufs)))
+        (error "%s" "Not in most nested minibuffer"))
+      (when (/=3D (recursion-depth) (cdar minibufs))
+        (error "%s" "Not in most nested command loop"))))
   ;; If the command that uses this has made modifications in the minibuffe=
r,
   ;; we don't want them to cause deactivation of the mark in the original
   ;; buffer.
@@ -2328,6 +2329,41 @@ exit-minibuffer
   (setq deactivate-mark nil)
   (throw 'exit nil))
=20
+(defun abort-minibuffers ()
+  "Abort the current minibuffer.
+If we are not currently in the innermost minibuffer, prompt the user to
+confirm the aborting of the current minibuffer and all contained ones."
+  (interactive)
+  (let* ((minibufs (minibuffer-alist))
+         (buffer (current-buffer))
+         (found nil)
+         (minibuffer-level (recursion-depth))
+         (outermost-p t))
+    (while (and (not found) minibufs)
+      (when (/=3D minibuffer-level (cdar minibufs))
+        (error "Not in most nested command loop"))
+      (if (eq buffer (caar minibufs))
+          (setq found t)
+        (setq outermost-p nil)
+        (setq minibufs (cdr minibufs))
+        (cl-decf minibuffer-level)))
+    (unless found
+      (error "Not in a minibuffer"))
+    (if outermost-p
+        (minibuffer-quit-recursive-edit)
+      (when (yes-or-no-p
+             (format "Abort %s minibuffer levels? "
+                     (- (recursion-depth) minibuffer-level -1)))
+        (let (exit-fun)
+          (setq exit-fun
+                (lambda ()
+                  (if (> (recursion-depth) minibuffer-level)
+                      (throw 'exit exit-fun)
+                    (signal 'minibuffer-quit nil))))
+          ;; See Info node `(elisp)Recursive Editing' for an
+          ;; explanation of throwing a function to `exit'.
+          (throw 'exit exit-fun))))))
+
 (defun minibuffer-quit-recursive-edit ()
   "Quit the command that requested this recursive edit without error.
 Like `abort-recursive-edit' without aborting keyboard macro
diff --git a/src/eval.c b/src/eval.c
index 48104bd0f4..76fe671b6d 100644
=2D-- a/src/eval.c
+++ b/src/eval.c
@@ -1174,14 +1174,6 @@ #define clobbered_eassert(E) verify (sizeof (E) !=3D=
 0)
    FUNC should return a Lisp_Object.
    This is how catches are done from within C code.  */
=20
=2D/* MINIBUFFER_QUIT_LEVEL is to handle quitting from nested minibuffers by
=2D   throwing t to tag `exit'.
=2D   0 means there is no (throw 'exit t) in progress, or it wasn't from
=2D     a minibuffer which isn't the most nested;
=2D   N > 0 means the `throw' was done from the minibuffer at level N which
=2D     wasn't the most nested.  */
=2DEMACS_INT minibuffer_quit_level =3D 0;
=2D
 Lisp_Object
 internal_catch (Lisp_Object tag,
 		Lisp_Object (*func) (Lisp_Object), Lisp_Object arg)
@@ -1189,9 +1181,6 @@ internal_catch (Lisp_Object tag,
   /* This structure is made part of the chain `catchlist'.  */
   struct handler *c =3D push_handler (tag, CATCHER);
=20
=2D  if (EQ (tag, Qexit))
=2D    minibuffer_quit_level =3D 0;
=2D
   /* Call FUNC.  */
   if (! sys_setjmp (c->jmp))
     {
@@ -1205,17 +1194,6 @@ internal_catch (Lisp_Object tag,
       Lisp_Object val =3D handlerlist->val;
       clobbered_eassert (handlerlist =3D=3D c);
       handlerlist =3D handlerlist->next;
=2D      if (EQ (tag, Qexit) && EQ (val, Qt) && minibuffer_quit_level > 0)
=2D	/* If we've thrown t to tag `exit' from within a minibuffer, we
=2D	   exit all minibuffers more deeply nested than the current
=2D	   one.  */
=2D	{
=2D	  if (minibuf_level > minibuffer_quit_level
=2D	      && !NILP (Fminibuffer_innermost_command_loop_p (Qnil)))
=2D            Fthrow (Qexit, Qt);
=2D	  else
=2D	    minibuffer_quit_level =3D 0;
=2D	}
       return val;
     }
 }
diff --git a/src/lisp.h b/src/lisp.h
index 80efd77113..fd89b464fc 100644
=2D-- a/src/lisp.h
+++ b/src/lisp.h
@@ -4111,7 +4111,6 @@ intern_c_string (const char *str)
 }
=20
 /* Defined in eval.c.  */
=2Dextern EMACS_INT minibuffer_quit_level;
 extern Lisp_Object Vautoload_queue;
 extern Lisp_Object Vrun_hooks;
 extern Lisp_Object Vsignaling_function;
diff --git a/src/minibuf.c b/src/minibuf.c
index 0f4349e70b..d9e404b7b0 100644
=2D-- a/src/minibuf.c
+++ b/src/minibuf.c
@@ -71,7 +71,6 @@ Copyright (C) 1985-1986, 1993-2021 Free Software Foundati=
on, Inc.
 static ptrdiff_t minibuf_prompt_width;
=20
 static Lisp_Object nth_minibuffer (EMACS_INT depth);
=2Dstatic EMACS_INT minibuf_c_loop_level (EMACS_INT depth);
 static void set_minibuffer_mode (Lisp_Object buf, EMACS_INT depth);
 static bool live_minibuffer_p (Lisp_Object);
=20
@@ -423,33 +422,28 @@ DEFUN ("minibufferp", Fminibufferp,
     ? Qt : Qnil;
 }
=20
=2DDEFUN ("innermost-minibuffer-p", Finnermost_minibuffer_p,
=2D       Sinnermost_minibuffer_p, 0, 1, 0,
=2D       doc: /* Return t if BUFFER is the most nested active minibuffer.
=2DNo argument or nil as argument means use the current buffer as BUFFER.  =
*/)
=2D  (Lisp_Object buffer)
=2D{
=2D  if (NILP (buffer))
=2D    buffer =3D Fcurrent_buffer ();
=2D  return EQ (buffer, (Fcar (Fnthcdr (make_fixnum (minibuf_level),
=2D				     Vminibuffer_list))))
=2D    ? Qt
=2D    : Qnil;
=2D}
=2D
=2DDEFUN ("minibuffer-innermost-command-loop-p", Fminibuffer_innermost_comm=
and_loop_p,
=2D       Sminibuffer_innermost_command_loop_p, 0, 1, 0,
=2D       doc: /* Return t if BUFFER is a minibuffer at the current command=
 loop level.
=2DNo argument or nil as argument means use the current buffer as BUFFER.  =
*/)
=2D  (Lisp_Object buffer)
+DEFUN ("minibuffer-alist", Fminibuffer_alist, Sminibuffer_alist, 0, 0, 0,
+       doc: /* Return an alist of minibuffers.
+Elements are of the form (MINIBUFFER . DEPTH), where depth is the
+recursion depth the MINIBUFFER.  The returned minibuffers are sorted
+in the order from the innermost minibuffer to the outermost one.  */)
+  (void)
 {
=2D  EMACS_INT depth;
=2D  if (NILP (buffer))
=2D    buffer =3D Fcurrent_buffer ();
=2D  depth =3D this_minibuffer_depth (buffer);
=2D  return depth && minibuf_c_loop_level (depth) =3D=3D command_loop_level
=2D    ? Qt
=2D    : Qnil;
+  Lisp_Object bufs_tail =3D Fcdr (Vminibuffer_list);
+  Lisp_Object cll_tail =3D Fcdr (Vcommand_loop_level_list);
+  Lisp_Object ret =3D Qnil;
+  for (int i =3D 1;
+       i <=3D minibuf_level && !NILP (bufs_tail) && !NILP (cll_tail);
+       i++)
+    {
+      EMACS_INT depth =3D XFIXNUM (Fcar (cll_tail)) + i;
+      Lisp_Object pair =3D Fcons (Fcar (bufs_tail),
+				make_fixnum (depth));
+      ret =3D Fcons (pair, ret);
+      cll_tail =3D Fcdr (cll_tail);
+      bufs_tail =3D Fcdr (bufs_tail);
+    }
+  return ret;
 }
=20
 /* Return the nesting depth of the active minibuffer BUFFER, or 0 if
@@ -471,35 +465,6 @@ this_minibuffer_depth (Lisp_Object buffer)
   return 0;
 }
=20
=2DDEFUN ("abort-minibuffers", Fabort_minibuffers, Sabort_minibuffers, 0, 0=
, "",
=2D       doc: /* Abort the current minibuffer.
=2DIf we are not currently in the innermost minibuffer, prompt the user to
=2Dconfirm the aborting of the current minibuffer and all contained ones.  =
*/)
=2D  (void)
=2D{
=2D  EMACS_INT minibuf_depth =3D this_minibuffer_depth (Qnil);
=2D  Lisp_Object array[2];
=2D  AUTO_STRING (fmt, "Abort %s minibuffer levels? ");
=2D
=2D  if (!minibuf_depth)
=2D    error ("Not in a minibuffer");
=2D  if (NILP (Fminibuffer_innermost_command_loop_p (Qnil)))
=2D    error ("Not in most nested command loop");
=2D  if (minibuf_depth < minibuf_level)
=2D    {
=2D      array[0] =3D fmt;
=2D      array[1] =3D make_fixnum (minibuf_level - minibuf_depth + 1);
=2D      if (!NILP (Fyes_or_no_p (Fformat (2, array))))
=2D	{
=2D	  minibuffer_quit_level =3D minibuf_depth;
=2D	  Fthrow (Qexit, Qt);
=2D	}
=2D    }
=2D  else
=2D    CALLN (Ffuncall, intern ("minibuffer-quit-recursive-edit"));
=2D  return Qnil;
=2D}
=2D
 DEFUN ("minibuffer-prompt-end", Fminibuffer_prompt_end,
        Sminibuffer_prompt_end, 0, 0, 0,
        doc: /* Return the buffer position of the end of the minibuffer pro=
mpt.
@@ -1045,14 +1010,6 @@ get_minibuffer (EMACS_INT depth)
   return buf;
 }
=20
=2Dstatic EMACS_INT minibuf_c_loop_level (EMACS_INT depth)
=2D{
=2D  Lisp_Object cll =3D Fnth (make_fixnum (depth), Vcommand_loop_level_lis=
t);
=2D  if (FIXNUMP (cll))
=2D    return XFIXNUM (cll);
=2D  return 0;
=2D}
=2D
 static void
 run_exit_minibuf_hook (void)
 {
@@ -2539,9 +2496,7 @@ syms_of_minibuf (void)
   defsubr (&Sminibuffer_prompt);
=20
   defsubr (&Sminibufferp);
=2D  defsubr (&Sinnermost_minibuffer_p);
=2D  defsubr (&Sminibuffer_innermost_command_loop_p);
=2D  defsubr (&Sabort_minibuffers);
+  defsubr (&Sminibuffer_alist);
   defsubr (&Sminibuffer_prompt_end);
   defsubr (&Sminibuffer_contents);
   defsubr (&Sminibuffer_contents_no_properties);
=2D-=20
2.32.0


--=-=-=--

--==-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJHBAEBCAAxFiEEmxVnesoT5rQXvVXnswkaGpIVmT8FAmD5+cUTHG1paGFAa2Ft
bml0bmlrLnRvcAAKCRCzCRoakhWZP2cCD/9pmOUMHw2TLZS+ToU9fJJ32r90Ak+2
ri5j3oIONUDsGptomerBsZ58qhzIjrqcUtAvZmNmyfMl934cLUwCZYqLNrR4nRfg
cKUm+7efzmgYiXNheGXjg7NFMLQkb1SEydQGp4D3elEso/knNEqA4+PCi+udvznZ
plKIj+WNpyumdsYbKAxgq2SBjCxC0xs0beQbaoLQQQukyGPx3CdQ9RNPnnP/OeDN
anYsPNhHQsYR5xSMtJTJTWL48jZvbAKS5CQd0rtoF7ODwKrK+D0h+uJfBOIFLrim
ezDq5+I0iBfeB0hMVDhLCvU/u919sdC9we9oZo6Y0MWgSQJ0q40R2Z8N4M721aSs
k0/oPXhwcuKVaFTE0n0uBcK1wiRFvry5hbgVFf83Ro1W8pyisMxzfm0VRBq+iECP
eO518AOXNnRsPGLNpafpsqAkSS7m8e1M2laH4DJ//fJWmMkiegP1cZIBjSrGJpfH
nDdkqnuFCAjV9v1o2KyzIhk8lkLcRYm2GkmzjLZr4f9GPhpNcio5QkTUqwaS9vjq
Cvt4uCF2Likgtv8n6886caxNX7ao712BZLDpOs6d+wGXy47wuGgROUePWvD/SPrT
1dr0J7/xMOoeNX4TnkEKibSgAoCQxhYd8jtfagkGTNc4yMQNgsy7hmnpRmlBcN/n
I/RoGmhKZo+1gw==
=OOYx
-----END PGP SIGNATURE-----
--==-=-=--




Message sent:


Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: miha@HIDDEN
Subject: bug#49700: Acknowledgement (27.2; [PATCH] Refactor minibuffer
 aborting)
Message-ID: <handler.49700.B.162699502326065.ack <at> debbugs.gnu.org>
References: <87pmvaar0a.fsf@miha-pc>
X-Gnu-PR-Message: ack 49700
X-Gnu-PR-Package: emacs
X-Gnu-PR-Keywords: patch
Reply-To: 49700 <at> debbugs.gnu.org
Date: Thu, 22 Jul 2021 23:04:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 49700 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
49700: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D49700
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems


Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#49700: 27.2; [PATCH] Refactor minibuffer aborting
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 23 Jul 2021 05:43:01 +0000
Resent-Message-ID: <handler.49700.B49700.16270189786167 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 49700
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: miha@HIDDEN
Cc: acm@HIDDEN, 49700 <at> debbugs.gnu.org
Received: via spool by 49700-submit <at> debbugs.gnu.org id=B49700.16270189786167
          (code B ref 49700); Fri, 23 Jul 2021 05:43:01 +0000
Received: (at 49700) by debbugs.gnu.org; 23 Jul 2021 05:42:58 +0000
Received: from localhost ([127.0.0.1]:42142 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1m6nxa-0001bP-29
	for submit <at> debbugs.gnu.org; Fri, 23 Jul 2021 01:42:58 -0400
Received: from eggs.gnu.org ([209.51.188.92]:42302)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1m6nxW-0001bA-Lo
 for 49700 <at> debbugs.gnu.org; Fri, 23 Jul 2021 01:42:57 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:47026)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1m6nxM-0004hk-Na; Fri, 23 Jul 2021 01:42:47 -0400
Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3276
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1m6nxM-0000vu-Bn; Fri, 23 Jul 2021 01:42:44 -0400
Date: Fri, 23 Jul 2021 08:42:28 +0300
Message-Id: <834kcl37sr.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <87pmvaar0a.fsf@miha-pc> (bug-gnu-emacs@HIDDEN)
References: <87pmvaar0a.fsf@miha-pc>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Cc: Alan Mackenzie <acm@HIDDEN>
> Date: Fri, 23 Jul 2021 01:05:41 +0200
> From: miha--- via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
> 
> The attached patch removes special handling of the 'exit tag from
> internal_catch.  This special handling was introduced by Alan in commit
> Sun Jan 10 20:32:40 2021 +0000
> (c7c154bb5756e0ae71d342c5d8aabf725877f186), hence me CC-ing him.
> 
> It also exposes Vminibuffer_list to lisp through the new function
> Fminibuffer_alist.

Thanks, but could you please explain the rationale and the motivation
for these changes?




Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#49700: 27.2; [PATCH] Refactor minibuffer aborting
Resent-From: <miha@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 23 Jul 2021 07:25:02 +0000
Resent-Message-ID: <handler.49700.B49700.162702505415548 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 49700
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Eli Zaretskii <eliz@HIDDEN>
Cc: acm@HIDDEN, 49700 <at> debbugs.gnu.org
Received: via spool by 49700-submit <at> debbugs.gnu.org id=B49700.162702505415548
          (code B ref 49700); Fri, 23 Jul 2021 07:25:02 +0000
Received: (at 49700) by debbugs.gnu.org; 23 Jul 2021 07:24:14 +0000
Received: from localhost ([127.0.0.1]:42194 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1m6pXa-00042i-DU
	for submit <at> debbugs.gnu.org; Fri, 23 Jul 2021 03:24:14 -0400
Received: from kamnitnik.top ([209.250.245.214]:55412 helo=mail.kamnitnik.top)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <miha@HIDDEN>) id 1m6pXY-00042X-0F
 for 49700 <at> debbugs.gnu.org; Fri, 23 Jul 2021 03:24:13 -0400
Received: from localhost (unknown [IPv6:2a00:ee2:e04:9300:e609:6c46:d026:8c47])
 by mail.kamnitnik.top (Postfix) with ESMTPSA id 12C5FBBB71;
 Fri, 23 Jul 2021 07:24:10 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kamnitnik.top;
 s=mail; t=1627025050;
 bh=XphzYPwR7nBSpNkq2aifS3KCSU9SFXVBsMIOZz5JXBw=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=jo8fxhJtgmec/Der9q+UrbkJ9f4WXV6LL5HrGnFaSrs0XXBTu8NL3YWm7ZGkTQAZa
 s7TnbnmxkdENr/33Shx9UMyerMFMJ8gdCLGv1LLas1Z8CG04H2EzDXyco3CWs0i9Ks
 Gk3XCMtuXMfnpRWOOxUve0sE7ActW5VC3UesvmCB8/CzyWa1pdNwSUQTa6lcDkAamc
 2xkJ0f+5ikeYqvMsLY5QviFRUjyAMkc9w/+4U5xZiM/Gdc0++6kVESSXgNv5EWOg+W
 3QDqA3CpfhFZNINzzaT/VfeYr8aWlV3L2MGM1K6MjpUc+F4qZJvNSmv9wAYxPm5Ipa
 HKh4oBCrrhKHQ==
From: <miha@HIDDEN>
In-Reply-To: <834kcl37sr.fsf@HIDDEN>
References: <87pmvaar0a.fsf@miha-pc> <834kcl37sr.fsf@HIDDEN>
Date: Fri, 23 Jul 2021 09:26:21 +0200
Message-ID: <87h7glfq3m.fsf@miha-pc>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
 micalg=pgp-sha256; protocol="application/pgp-signature"
X-Spam-Score: 2.5 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  Eli Zaretskii <eliz@HIDDEN> writes: >> Cc: Alan Mackenzie
 <acm@HIDDEN> >> Date: Fri, 23 Jul 2021 01:05:41 +0200 >> From: miha--- via
 "Bug reports for GNU Emacs,
 >> the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
 >> >> The [...] 
 Content analysis details:   (2.5 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 SPF_PASS               SPF: sender matches SPF record
 2.0 PDS_OTHER_BAD_TLD      Untrustworthy TLDs
 [URI: kamnitnik.top (top)]
 0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 0.5 FROM_SUSPICIOUS_NTLD   From abused NTLD
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 2.5 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  Eli Zaretskii <eliz@HIDDEN> writes: >> Cc: Alan Mackenzie
    <acm@HIDDEN> >> Date: Fri, 23 Jul 2021 01:05:41 +0200 >> From: miha--- via
    "Bug reports for GNU Emacs, >> the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
    >> >> The [...] 
 
 Content analysis details:   (2.5 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 SPF_PASS               SPF: sender matches SPF record
  2.0 PDS_OTHER_BAD_TLD      Untrustworthy TLDs
                             [URI: kamnitnik.top (top)]
  0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
  0.5 FROM_SUSPICIOUS_NTLD   From abused NTLD
  1.0 BULK_RE_SUSP_NTLD      Precedence bulk and RE: from a suspicious TLD
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager

--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Eli Zaretskii <eliz@HIDDEN> writes:

>> Cc: Alan Mackenzie <acm@HIDDEN>
>> Date: Fri, 23 Jul 2021 01:05:41 +0200
>> From: miha--- via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
>>=20
>> The attached patch removes special handling of the 'exit tag from
>> internal_catch.  This special handling was introduced by Alan in commit
>> Sun Jan 10 20:32:40 2021 +0000
>> (c7c154bb5756e0ae71d342c5d8aabf725877f186), hence me CC-ing him.
>>=20
>> It also exposes Vminibuffer_list to lisp through the new function
>> Fminibuffer_alist.
>
> Thanks, but could you please explain the rationale and the motivation
> for these changes?

Refactoring to have cleaner code.

Right now, without applying this patch, quitting multiple recursive
edits (in minibuffer-exit) is achieved by extra special handling in
internal_catch.  In my opinion, it's cleaner to avoid adding such code
into a core function like internal_catch if possible.  This patch moves
this code into the function minibuffer-exit, and by using closures, it
achieves the same effect without a global variable
(minibuffer_quit_level).

In other words, without this patch, Fminibuffer_exit cooperates with
internal_catch through a global variable.  And with this patch,
Fminibuffer_exit cooperates with command_loop by passing it a closure.

Fminibuffer_exit was moved to lisp because its easier to make closures
in lisp.

minibuffer-alist was introduced because it's needed by minibuffer-exit.
I also think that it's nice to expose the list of minibuffers to lisp.

The two minibuffer-innermost-[command-loop]-p functions were removed
because minibuffer-alist can be used instead.

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJHBAEBCAAxFiEEmxVnesoT5rQXvVXnswkaGpIVmT8FAmD6bx4THG1paGFAa2Ft
bml0bmlrLnRvcAAKCRCzCRoakhWZPy6tEACvKcB7EbYKizd9nGbbKtM/jrMpNCdB
o2drAAy1gTyTeRPf7x/zBni2MP3r0nlbefQeswEiEbP4cc6d0JWWujN+7JBWQsyR
dIHkvhS/0H9YzhXqa16pL+xUiBEo8IzaDmoOKJSm8vks/9yXrs7AlMrJeiJTiw/A
sKMchH62S8hbBOBXWtGOaW1Fsnm33Ygoz+jmTTrSX8CY/zFuIoivt6G04Qhrwv20
uY5Ld6vN1jqJajQfl+DDUgV50NhEuqbjMm99vcNr+mfclDb6Emly7edx9OEXbT+k
bTp25u6+PVp2XsbKekZNtxyHWiailitADqBsuDoHS2oq6Uc5C4tWhrd30qiH3mML
addJfBWqk7fgO2p89OpRxMV1PrdfoIktAbZURN6d6gaTXLqeHtkfYFbLhbVDNxw4
qd1IXBHXuonj0AmIw5hViELqErl/m0sR0Ife9MbLZMl4MGLmWzDHwGV4A/J4zIcG
TqVuBU9svqOAnkSX9jCAb+nQb5+5gNMcByl3CSuOossle5lP7KhSdldYW2a6dR8D
klnleRWBb32iXP9Gy2GJCVnWvtxTQgu8nsD4jMy9DINJSdTk4R2b1/kl6E+DV5Vh
DyZyHIuhvrmimjl/TKDMOqhtIahEjA/5G7l4VmCiXKZrLsX//zA6MNibDU+Ay/xp
5WLv0PzZry7ynw==
=JuGh
-----END PGP SIGNATURE-----
--=-=-=--




Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#49700: 27.2; [PATCH] Refactor minibuffer aborting
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 23 Jul 2021 07:33:02 +0000
Resent-Message-ID: <handler.49700.B49700.162702556716513 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 49700
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: <miha@HIDDEN>
Cc: acm@HIDDEN, 49700 <at> debbugs.gnu.org
Received: via spool by 49700-submit <at> debbugs.gnu.org id=B49700.162702556716513
          (code B ref 49700); Fri, 23 Jul 2021 07:33:02 +0000
Received: (at 49700) by debbugs.gnu.org; 23 Jul 2021 07:32:47 +0000
Received: from localhost ([127.0.0.1]:42198 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1m6pfr-0004IH-A3
	for submit <at> debbugs.gnu.org; Fri, 23 Jul 2021 03:32:47 -0400
Received: from eggs.gnu.org ([209.51.188.92]:57736)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1m6pfn-0004I0-L4
 for 49700 <at> debbugs.gnu.org; Fri, 23 Jul 2021 03:32:46 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:48972)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1m6pfh-0003TP-0m; Fri, 23 Jul 2021 03:32:37 -0400
Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2237
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1m6pfg-0006Yl-L4; Fri, 23 Jul 2021 03:32:36 -0400
Date: Fri, 23 Jul 2021 10:32:19 +0300
Message-Id: <83wnph1o58.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <87h7glfq3m.fsf@miha-pc>
References: <87pmvaar0a.fsf@miha-pc> <834kcl37sr.fsf@HIDDEN>
 <87h7glfq3m.fsf@miha-pc>
X-Spam-Score: -0.3 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.3 (-)

> From: <miha@HIDDEN>
> Cc: acm@HIDDEN, 49700 <at> debbugs.gnu.org
> Date: Fri, 23 Jul 2021 09:26:21 +0200
> 
> > Thanks, but could you please explain the rationale and the motivation
> > for these changes?
> 
> Refactoring to have cleaner code.
> 
> Right now, without applying this patch, quitting multiple recursive
> edits (in minibuffer-exit) is achieved by extra special handling in
> internal_catch.  In my opinion, it's cleaner to avoid adding such code
> into a core function like internal_catch if possible.  This patch moves
> this code into the function minibuffer-exit, and by using closures, it
> achieves the same effect without a global variable
> (minibuffer_quit_level).
> 
> In other words, without this patch, Fminibuffer_exit cooperates with
> internal_catch through a global variable.  And with this patch,
> Fminibuffer_exit cooperates with command_loop by passing it a closure.
> 
> Fminibuffer_exit was moved to lisp because its easier to make closures
> in lisp.
> 
> minibuffer-alist was introduced because it's needed by minibuffer-exit.
> I also think that it's nice to expose the list of minibuffers to lisp.

Thanks.

I'd prefer not to expose minibuffer-alist to Lisp if it can be
avoided.  This is a tricky area of Emacs, and exposing it to Lisp IMO
gives Lisp programmers too much rope to hang themselves.  Is it
feasible to make these changes without exposing the alist?




Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#49700: 27.2; [PATCH] Refactor minibuffer aborting
Resent-From: <miha@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 23 Jul 2021 08:33:02 +0000
Resent-Message-ID: <handler.49700.B49700.162702916021946 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 49700
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Eli Zaretskii <eliz@HIDDEN>
Cc: acm@HIDDEN, 49700 <at> debbugs.gnu.org
Received: via spool by 49700-submit <at> debbugs.gnu.org id=B49700.162702916021946
          (code B ref 49700); Fri, 23 Jul 2021 08:33:02 +0000
Received: (at 49700) by debbugs.gnu.org; 23 Jul 2021 08:32:40 +0000
Received: from localhost ([127.0.0.1]:42237 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1m6qbo-0005ht-5f
	for submit <at> debbugs.gnu.org; Fri, 23 Jul 2021 04:32:40 -0400
Received: from kamnitnik.top ([209.250.245.214]:55702 helo=mail.kamnitnik.top)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <miha@HIDDEN>) id 1m6qbj-0005hi-Ox
 for 49700 <at> debbugs.gnu.org; Fri, 23 Jul 2021 04:32:38 -0400
Received: from localhost (unknown [IPv6:2a00:ee2:e04:9300:e609:6c46:d026:8c47])
 by mail.kamnitnik.top (Postfix) with ESMTPSA id 7B176BBB71;
 Fri, 23 Jul 2021 08:32:33 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kamnitnik.top;
 s=mail; t=1627029153;
 bh=Zg7r0RWo63ffHxB3Ba96cRBLjNpS0twrYEPPZ0CeLgc=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=d9JkWDrcSg3phhuTHqSDArYOXQmKk8YMz4mLa2EOJ/Usm8UTzYttMHRwHHzpOLm/1
 XpcXZsT52kixCTV6pM+jP5YHrO8k6Mf0V2chZxMQwISxcPXk7d7No6kmjHkvBAhAem
 v+dO0MoXKotD54RH9MbsocxvQME1JFms/FyL3D787VxJ8ccb0EMNalKw1g+q+AXuwI
 fILnHs9DBN6giueO47OolTjlcaSEjqb5HwBY/uT3JM7qJiviWPdnyKStZ50iSVU3n3
 AD7KDJ+YymFqH2DCNdld3HctrL84ujYEMdS8M0BnDtOa3dAlasOZUkxkNfaiRaXBCG
 3gRJYoaKENcZg==
From: <miha@HIDDEN>
In-Reply-To: <83wnph1o58.fsf@HIDDEN>
References: <87pmvaar0a.fsf@miha-pc> <834kcl37sr.fsf@HIDDEN>
 <87h7glfq3m.fsf@miha-pc> <83wnph1o58.fsf@HIDDEN>
Date: Fri, 23 Jul 2021 10:34:45 +0200
Message-ID: <87eebpfmxm.fsf@miha-pc>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
 micalg=pgp-sha256; protocol="application/pgp-signature"
X-Spam-Score: 2.5 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview: Eli Zaretskii <eliz@HIDDEN> writes: >> From:
 <miha@HIDDEN>
 >> Cc: acm@HIDDEN, 49700 <at> debbugs.gnu.org >> Date: Fri, 23 Jul 2021 09:26:21
 +0200 >> >> > Thanks, but could you please explain the rationale and the
 motivation >> > for t [...] 
 Content analysis details:   (2.5 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 SPF_PASS               SPF: sender matches SPF record
 2.0 PDS_OTHER_BAD_TLD      Untrustworthy TLDs
 [URI: kamnitnik.top (top)]
 0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 0.5 FROM_SUSPICIOUS_NTLD   From abused NTLD
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 2.5 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  Eli Zaretskii <eliz@HIDDEN> writes: >> From: <miha@HIDDEN>
    >> Cc: acm@HIDDEN, 49700 <at> debbugs.gnu.org >> Date: Fri, 23 Jul 2021 09:26:21
    +0200 >> >> > Thanks, but could you please explain the rationale and the
   motivation >> > for t [...] 
 
 Content analysis details:   (2.5 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 SPF_PASS               SPF: sender matches SPF record
  2.0 PDS_OTHER_BAD_TLD      Untrustworthy TLDs
                             [URI: kamnitnik.top (top)]
  0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
  0.5 FROM_SUSPICIOUS_NTLD   From abused NTLD
  1.0 BULK_RE_SUSP_NTLD      Precedence bulk and RE: from a suspicious TLD
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager

--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Eli Zaretskii <eliz@HIDDEN> writes:

>> From: <miha@HIDDEN>
>> Cc: acm@HIDDEN, 49700 <at> debbugs.gnu.org
>> Date: Fri, 23 Jul 2021 09:26:21 +0200
>>=20
>> > Thanks, but could you please explain the rationale and the motivation
>> > for these changes?
>>=20
>> Refactoring to have cleaner code.
>>=20
>> Right now, without applying this patch, quitting multiple recursive
>> edits (in minibuffer-exit) is achieved by extra special handling in
>> internal_catch.  In my opinion, it's cleaner to avoid adding such code
>> into a core function like internal_catch if possible.  This patch moves
>> this code into the function minibuffer-exit, and by using closures, it
>> achieves the same effect without a global variable
>> (minibuffer_quit_level).
>>=20
>> In other words, without this patch, Fminibuffer_exit cooperates with
>> internal_catch through a global variable.  And with this patch,
>> Fminibuffer_exit cooperates with command_loop by passing it a closure.
>>=20
>> Fminibuffer_exit was moved to lisp because its easier to make closures
>> in lisp.
>>=20
>> minibuffer-alist was introduced because it's needed by minibuffer-exit.
>> I also think that it's nice to expose the list of minibuffers to lisp.
>
> Thanks.
>
> I'd prefer not to expose minibuffer-alist to Lisp if it can be
> avoided.  This is a tricky area of Emacs, and exposing it to Lisp IMO
> gives Lisp programmers too much rope to hang themselves.

Well, the minibuffer list is already kind of exposed to lisp, try:
(seq-filter #'minibufferp (buffer-list))

minibuffer-alist returns a newly constructed list, similar to
buffer-list, so modifying the list structure is safe.  What could be
unsafe is modifying the minibuffers themselves, renaming or killing
them.  I believe that, since such actions are possible without the use
of minibuffer-alist
(for example, by evaluating (kill-buffer " *Minibuf-1")), they should
not mess up Emacs internals and it should be treated as a bug if they
do.

> Is it feasible to make these changes without exposing the alist?

Yes it is feasible.  If the above didn't convince you, please send
another e-mail and I will try.  Thanks.

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJHBAEBCAAxFiEEmxVnesoT5rQXvVXnswkaGpIVmT8FAmD6fyUTHG1paGFAa2Ft
bml0bmlrLnRvcAAKCRCzCRoakhWZP6DdD/sFLu8Rp5wQMcPqk/FtRaRyO1zFoGQ9
D1LwpcW55eeA67lFq665KUu9AIIvGmVd1wu+v6S130X/8xj16yYR8DYhT3nPkDCr
5ZdKx5408y1GBcTNIIkpu1EGhb5AH+xrOG/s/bG0X4mgIgGxrudnPzMyyVOPXTSJ
4e1kGCM1miJPggYGnQmn7EnpCxWRzQU+yWOMlgLaT1mYvkZu1wTHQVp2vA3AKf7M
VPo5TZCcI1OVM9iqCSwPM5jAUcSatju+Hu5K0ciWjZHgq8yR1EcMlW41D0KTlX3W
u/NenYe3KpYJ/UGnlEzMlSWePbMD797gjdE5XUldxFd69Cb4baO7F9WspjM4f4O8
5iWwnfmpWpsV3InrK2i5+k+zh35XRHZ0v7ki1q4qFSduVcuDA9wivQTr8V3SPhWv
TSMJTrfqH8rGd1pVSbIl34ChV7v4sr92r5gcAi/mKTBgN53/yN/msC5t0CAG+tBH
Hif/FCCUoSvdeDeetkOy0ACNI+iNlAuB+mDjSe9VVCLDHjLM07WFb0I4kk+mVw3n
keQg1OFurgZIr3vZMShTJNULheuxPKwPi5ehvWeSwUkcGmQWz0LSJtBx1f45Kpg3
EjyAuzVFL9KPQX94OJLWJ9K+oCj34vYNw0gqBcPyqSMx9E/jxAoXdVnfLkSDV44z
RY8zlY0m744LRg==
=WPoZ
-----END PGP SIGNATURE-----
--=-=-=--




Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#49700: 27.2; [PATCH] Refactor minibuffer aborting
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 23 Jul 2021 10:33:02 +0000
Resent-Message-ID: <handler.49700.B49700.16270363249538 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 49700
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: <miha@HIDDEN>
Cc: acm@HIDDEN, 49700 <at> debbugs.gnu.org
Received: via spool by 49700-submit <at> debbugs.gnu.org id=B49700.16270363249538
          (code B ref 49700); Fri, 23 Jul 2021 10:33:02 +0000
Received: (at 49700) by debbugs.gnu.org; 23 Jul 2021 10:32:04 +0000
Received: from localhost ([127.0.0.1]:42378 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1m6sTM-0002Tm-Aj
	for submit <at> debbugs.gnu.org; Fri, 23 Jul 2021 06:32:04 -0400
Received: from eggs.gnu.org ([209.51.188.92]:34288)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1m6sTK-0002T8-Cp
 for 49700 <at> debbugs.gnu.org; Fri, 23 Jul 2021 06:32:03 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:35988)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1m6sTD-0004J0-Sg; Fri, 23 Jul 2021 06:31:55 -0400
Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1312
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1m6sTD-0007QN-Ci; Fri, 23 Jul 2021 06:31:55 -0400
Date: Fri, 23 Jul 2021 13:31:39 +0300
Message-Id: <83sg051fuc.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <87eebpfmxm.fsf@miha-pc>
References: <87pmvaar0a.fsf@miha-pc> <834kcl37sr.fsf@HIDDEN>
 <87h7glfq3m.fsf@miha-pc> <83wnph1o58.fsf@HIDDEN> <87eebpfmxm.fsf@miha-pc>
X-Spam-Score: -0.3 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.3 (-)

> From: <miha@HIDDEN>
> Cc: acm@HIDDEN, 49700 <at> debbugs.gnu.org
> Date: Fri, 23 Jul 2021 10:34:45 +0200
> 
> > I'd prefer not to expose minibuffer-alist to Lisp if it can be
> > avoided.  This is a tricky area of Emacs, and exposing it to Lisp IMO
> > gives Lisp programmers too much rope to hang themselves.
> 
> Well, the minibuffer list is already kind of exposed to lisp, try:
> (seq-filter #'minibufferp (buffer-list))

Then why did you need to introduce a new function?  It's fine with me
to use the above if it does the job.

> minibuffer-alist returns a newly constructed list, similar to
> buffer-list, so modifying the list structure is safe.  What could be
> unsafe is modifying the minibuffers themselves, renaming or killing
> them.

Exactly.  And there are more atrocities that can be done with these
buffers.

> I believe that, since such actions are possible without the use
> of minibuffer-alist
> (for example, by evaluating (kill-buffer " *Minibuf-1")), they should
> not mess up Emacs internals and it should be treated as a bug if they
> do.

I'd like to make that as difficult as possible.  When someone reports
a bug, it could take some time and effort to discover that the code
does something it shouldn't, and that eats up our precious resources.
Also, if we expose the list of minibuffers explicitly, and with
auxiliary information on top of that, it is hard to defend the
position that Lisp programs should not do anything they want with that
information.

> > Is it feasible to make these changes without exposing the alist?
> 
> Yes it is feasible.  If the above didn't convince you, please send
> another e-mail and I will try.  Thanks.

Yes, please try, and thanks in advance.




Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#49700: 27.2; [PATCH] Refactor minibuffer aborting
Resent-From: <miha@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 23 Jul 2021 11:12:02 +0000
Resent-Message-ID: <handler.49700.B49700.162703870413036 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 49700
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Eli Zaretskii <eliz@HIDDEN>
Cc: acm@HIDDEN, 49700 <at> debbugs.gnu.org
Received: via spool by 49700-submit <at> debbugs.gnu.org id=B49700.162703870413036
          (code B ref 49700); Fri, 23 Jul 2021 11:12:02 +0000
Received: (at 49700) by debbugs.gnu.org; 23 Jul 2021 11:11:44 +0000
Received: from localhost ([127.0.0.1]:42395 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1m6t5k-0003OC-6S
	for submit <at> debbugs.gnu.org; Fri, 23 Jul 2021 07:11:44 -0400
Received: from kamnitnik.top ([209.250.245.214]:56376 helo=mail.kamnitnik.top)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <miha@HIDDEN>) id 1m6t5g-0003O1-I4
 for 49700 <at> debbugs.gnu.org; Fri, 23 Jul 2021 07:11:42 -0400
Received: from localhost (unknown [IPv6:2a00:ee2:e04:9300:e609:6c46:d026:8c47])
 by mail.kamnitnik.top (Postfix) with ESMTPSA id 92683BBB71;
 Fri, 23 Jul 2021 11:11:38 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kamnitnik.top;
 s=mail; t=1627038698;
 bh=piXrHTZ3/8tJf35MYeRzodPBCsh5ixjEO0saDHD4GVs=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=exToSwci9+lnIv6fjRCPxCsFGQYlVW/ZqRALWfpM1O6+Xxp2WpnxVVtuiDCXYCefU
 9HeGhIqBHYU6v6mfLpVaFBo4F3ydgz9/tKSYdZ6Fym8TnTb9Q8Hjt/tEgbK0D2+E4G
 YbzcdxS7DZe/ewuaJ3acBXopbpvOdaG02eq/Pyq6uuWzL4THvoTZj5nX7XgK63YzPs
 MwPsBtYnEPzUNWtpDglm041anoZKA5gNmByk6hnPUYKkhXSNnG8UoF0KAxyty/VGCR
 l3wCxY228BbUdIfScaAxFxa2YzQWx+LxaFjIBqARhR+Ry6JM6qzmWlkGIx2zpMuBO0
 vqp703FS7St5w==
From: <miha@HIDDEN>
In-Reply-To: <83sg051fuc.fsf@HIDDEN>
References: <87pmvaar0a.fsf@miha-pc> <834kcl37sr.fsf@HIDDEN>
 <87h7glfq3m.fsf@miha-pc> <83wnph1o58.fsf@HIDDEN> <87eebpfmxm.fsf@miha-pc>
 <83sg051fuc.fsf@HIDDEN>
Date: Fri, 23 Jul 2021 13:13:49 +0200
Message-ID: <87v951th8y.fsf@miha-pc>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
 micalg=pgp-sha256; protocol="application/pgp-signature"
X-Spam-Score: 2.5 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview: Eli Zaretskii <eliz@HIDDEN> writes: >> From:
 <miha@HIDDEN>
 >> Cc: acm@HIDDEN, 49700 <at> debbugs.gnu.org >> Date: Fri, 23 Jul 2021 10:34:45
 +0200 >> >> > I'd prefer not to expose minibuffer-alist to Lisp if it can
 be >> > avoided. Thi [...] 
 Content analysis details:   (2.5 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 SPF_PASS               SPF: sender matches SPF record
 2.0 PDS_OTHER_BAD_TLD      Untrustworthy TLDs
 [URI: kamnitnik.top (top)]
 0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 0.5 FROM_SUSPICIOUS_NTLD   From abused NTLD
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 2.5 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  Eli Zaretskii <eliz@HIDDEN> writes: >> From: <miha@HIDDEN>
    >> Cc: acm@HIDDEN, 49700 <at> debbugs.gnu.org >> Date: Fri, 23 Jul 2021 10:34:45
    +0200 >> >> > I'd prefer not to expose minibuffer-alist to Lisp if it can
    be >> > avoided. Thi [...] 
 
 Content analysis details:   (2.5 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 SPF_PASS               SPF: sender matches SPF record
  2.0 PDS_OTHER_BAD_TLD      Untrustworthy TLDs
                             [URI: kamnitnik.top (top)]
  0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
  0.5 FROM_SUSPICIOUS_NTLD   From abused NTLD
  1.0 BULK_RE_SUSP_NTLD      Precedence bulk and RE: from a suspicious TLD
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager

--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Eli Zaretskii <eliz@HIDDEN> writes:

>> From: <miha@HIDDEN>
>> Cc: acm@HIDDEN, 49700 <at> debbugs.gnu.org
>> Date: Fri, 23 Jul 2021 10:34:45 +0200
>>=20
>> > I'd prefer not to expose minibuffer-alist to Lisp if it can be
>> > avoided.  This is a tricky area of Emacs, and exposing it to Lisp IMO
>> > gives Lisp programmers too much rope to hang themselves.
>>=20
>> Well, the minibuffer list is already kind of exposed to lisp, try:
>> (seq-filter #'minibufferp (buffer-list))
>
> Then why did you need to introduce a new function?  It's fine with me
> to use the above if it does the job.
>

Yes, the above returns an unsorted list of minibuffers and I don't know
of any way to sort them according to depth.  minibuffer-alist would
return a sorted list.

>> minibuffer-alist returns a newly constructed list, similar to
>> buffer-list, so modifying the list structure is safe.  What could be
>> unsafe is modifying the minibuffers themselves, renaming or killing
>> them.
>
> Exactly.  And there are more atrocities that can be done with these
> buffers.
>
>> I believe that, since such actions are possible without the use
>> of minibuffer-alist
>> (for example, by evaluating (kill-buffer " *Minibuf-1")), they should
>> not mess up Emacs internals and it should be treated as a bug if they
>> do.
>
> I'd like to make that as difficult as possible.  When someone reports
> a bug, it could take some time and effort to discover that the code
> does something it shouldn't, and that eats up our precious resources.
> Also, if we expose the list of minibuffers explicitly, and with
> auxiliary information on top of that, it is hard to defend the
> position that Lisp programs should not do anything they want with that
> information.
>

OK, I understand.

>> > Is it feasible to make these changes without exposing the alist?
>>=20
>> Yes it is feasible.  If the above didn't convince you, please send
>> another e-mail and I will try.  Thanks.
>
> Yes, please try, and thanks in advance.

OK, I will, but it might take about a week as I'm currently away.

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJHBAEBCAAxFiEEmxVnesoT5rQXvVXnswkaGpIVmT8FAmD6pG0THG1paGFAa2Ft
bml0bmlrLnRvcAAKCRCzCRoakhWZP9iVEADCPbDd4krupOidxf307rMr15cW1Dwv
blWTvGIKZLzr5p/72sWk7qQ3vt44lY51sjHyfv4DpAPHTOc+egfR9cCVy/WZ75Tt
0I4KukBhj5pi+D2b1wi4VHZhnX5VuSt99J34iPQYb92tZ4N/hd7en/BDoKnCWfG0
qwfm/oZHyffytDD4iDomMj6ZIrJ0+JwpNAdSGF4N6nyi+O8lTyFdc6MIUpQ5YiNW
387w3edl/GWQwyZgTUf+F+fiN8ENxcEdudm70P+gVwJrIQpqS4stqZSU0/oTGTRC
snc+oWaP4EXGHzFspDf+2pyUIYb8KWnqqX12EN72ophg57L4GkZ7/C8AUw3hoaWy
ntWHpAWd3Uuw6Umwtv+VZYPyoYmIG6EVt+eJu9iR3pG8wZy1Ch2HAOHMi8qiZp/0
xe6b4woyf4i0v9Zufh3fod9cn+9aoKpETYhPbd6FYEB47mUvvvlqWo5sOs2qaJnD
Cow+TZXw8Lcjw9vAB7KF6qZNsNbUC95bnnn0yg89nd97i5S1n6VOhApGKPsqyGXD
W9C5e5/muUj9vNKS0pPAjk3wrG5Mg75loCEU8ix+Pfx4Rf2MwS7wSNMyIxPJOdou
FbpvUkSeC47QS4l4IAr9ibR1xNyqdlemLS3QLhHLJw4bGOhrHFYR9YxiCKAdAp72
81UqbrPj0KZjPQ==
=bWVC
-----END PGP SIGNATURE-----
--=-=-=--




Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#49700: 27.2; [PATCH] Refactor minibuffer aborting
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 23 Jul 2021 11:42:01 +0000
Resent-Message-ID: <handler.49700.B49700.162704050124239 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 49700
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: <miha@HIDDEN>
Cc: acm@HIDDEN, 49700 <at> debbugs.gnu.org
Received: via spool by 49700-submit <at> debbugs.gnu.org id=B49700.162704050124239
          (code B ref 49700); Fri, 23 Jul 2021 11:42:01 +0000
Received: (at 49700) by debbugs.gnu.org; 23 Jul 2021 11:41:41 +0000
Received: from localhost ([127.0.0.1]:42440 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1m6tYj-0006It-Dv
	for submit <at> debbugs.gnu.org; Fri, 23 Jul 2021 07:41:41 -0400
Received: from eggs.gnu.org ([209.51.188.92]:47102)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1m6tYg-0006If-Vu
 for 49700 <at> debbugs.gnu.org; Fri, 23 Jul 2021 07:41:39 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:45600)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1m6tYa-00010a-7i; Fri, 23 Jul 2021 07:41:32 -0400
Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1564
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1m6tYZ-0001P2-HH; Fri, 23 Jul 2021 07:41:32 -0400
Date: Fri, 23 Jul 2021 14:41:14 +0300
Message-Id: <83pmv91cmd.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <87v951th8y.fsf@miha-pc>
References: <87pmvaar0a.fsf@miha-pc> <834kcl37sr.fsf@HIDDEN>
 <87h7glfq3m.fsf@miha-pc> <83wnph1o58.fsf@HIDDEN> <87eebpfmxm.fsf@miha-pc>
 <83sg051fuc.fsf@HIDDEN> <87v951th8y.fsf@miha-pc>
X-Spam-Score: -0.3 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.3 (-)

> From: <miha@HIDDEN>
> Cc: acm@HIDDEN, 49700 <at> debbugs.gnu.org
> Date: Fri, 23 Jul 2021 13:13:49 +0200
> 
> >> > Is it feasible to make these changes without exposing the alist?
> >> 
> >> Yes it is feasible.  If the above didn't convince you, please send
> >> another e-mail and I will try.  Thanks.
> >
> > Yes, please try, and thanks in advance.
> 
> OK, I will, but it might take about a week as I'm currently away.

Thanks.  There's no rush, so no worries.




Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#49700: 27.2; [PATCH] Refactor minibuffer aborting
Resent-From: Alan Mackenzie <acm@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 23 Jul 2021 21:04:02 +0000
Resent-Message-ID: <handler.49700.B49700.16270742258437 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 49700
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: 49700 <at> debbugs.gnu.org
Received: via spool by 49700-submit <at> debbugs.gnu.org id=B49700.16270742258437
          (code B ref 49700); Fri, 23 Jul 2021 21:04:02 +0000
Received: (at 49700) by debbugs.gnu.org; 23 Jul 2021 21:03:45 +0000
Received: from localhost ([127.0.0.1]:44740 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1m72Ke-0002Bz-TJ
	for submit <at> debbugs.gnu.org; Fri, 23 Jul 2021 17:03:45 -0400
Received: from colin.muc.de ([193.149.48.1]:44209 helo=mail.muc.de)
 by debbugs.gnu.org with smtp (Exim 4.84_2)
 (envelope-from <acm@HIDDEN>) id 1m72Kb-0002BF-9P
 for 49700 <at> debbugs.gnu.org; Fri, 23 Jul 2021 17:03:43 -0400
Received: (qmail 36164 invoked by uid 3782); 23 Jul 2021 21:03:34 -0000
Received: from acm.muc.de (p4fe154d9.dip0.t-ipconnect.de [79.225.84.217])
 (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP;
 Fri, 23 Jul 2021 23:03:33 +0200
Received: (qmail 13838 invoked by uid 1000); 23 Jul 2021 21:03:33 -0000
Date: Fri, 23 Jul 2021 21:03:33 +0000
Message-ID: <YPsupQ/zKquOV1ly@ACM>
References: <87pmvaar0a.fsf@miha-pc>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87pmvaar0a.fsf@miha-pc>
X-Submission-Agent: TMDA/1.3.x (Ph3nix)
From: Alan Mackenzie <acm@HIDDEN>
X-Primary-Address: acm@HIDDEN
X-Spam-Score: 2.0 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  Hello, Miha. On Fri, Jul 23, 2021 at 01:05:41 +0200,
 miha@HIDDEN
 wrote: > The attached patch removes special handling of the 'exit tag from
 > internal_catch. This special handling was introduced by Alan in [...] 
 Content analysis details:   (2.0 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 SPF_PASS               SPF: sender matches SPF record
 2.0 PDS_OTHER_BAD_TLD      Untrustworthy TLDs
 [URI: kamnitnik.top (top)]
 0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.0 (+)

Hello, Miha.

On Fri, Jul 23, 2021 at 01:05:41 +0200, miha@HIDDEN wrote:
> The attached patch removes special handling of the 'exit tag from
> internal_catch.  This special handling was introduced by Alan in commit
> Sun Jan 10 20:32:40 2021 +0000
> (c7c154bb5756e0ae71d342c5d8aabf725877f186), hence me CC-ing him.

Thanks, that's appreciated.

I'm not sure I'm in favour of the change as a whole, since the proposed
code contains complexities (as does the code it would replace).  I find
the use of the closures difficult to understand.  But then again, I wrote
the old code, so I'm not in a position to judge whether the old or the
new is "better".

> It also exposes Vminibuffer_list to lisp through the new function
> Fminibuffer_alist.

Like Eli, I'm against this.  Indeed, when I was modifying the minibuffer
code, I took great care to avoid Vminibuffer_list becoming visible to
Lisp.  As a result, some of the current code is less elegant than it
might have been.  The idea of some Lisp looping through all existing
minibuffers doing something destructive didn't help me sleep well.

As a general point, I'm a bit worried you might not be distinguishing
between (minibuffer-depth) and (recursive-depth).  They are only the same
most of the time.  When (recursive-edit) gets called outside of the
minibuffer code, then these two values are different.  For example, in 
abort-minibuffers, you've got

> +      (when (yes-or-no-p
> +             (format "Abort %s minibuffer levels? "
> +                     (- (recursion-depth) minibuffer-level -1)))

..  minibuffer-level is confusingly a result of (recursion-depth), not
(minibuffer-depth), so the code isn't prompting with the number of
minibuffer levels to be aborted, but the number of recursive edits.

As a small point, the use of cl-decf:

> +        (cl-decf minibuffer-level)))

might be unwise.  Have you checked that it works in a bootstrap build?
My fear is that in a bootstrap, minibuffer.el might be compiled before
the CL files, and then cl-decf would be wrongly compiled as a function
call rather than a macro expansion.  But I haven't checked it myself.

I've also had a look a part of your patch from Tuesday (2021-07-20), and
am unhappy about some aspects of the change to the documentation on the
Elisp manual page Recursive Editing.  For example, the text no longer
says what happens on throwing a random value to 'exit (but it used to).
Also this text is generally a bit unclear; what does "a function value"
mean?  I would normally understand "the value returned by a function",
but here it just means the function.  But I think it would be better for
me to raise these issues in a different thread.

I haven't yet spent enough time looking at your patch.  Perhaps I'll
manage it in the next week.

-- 
Alan Mackenzie (Nuremberg, Germany).




Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#49700: 27.2; [PATCH] Refactor minibuffer aborting
Resent-From: <miha@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 01 Aug 2021 01:22:01 +0000
Resent-Message-ID: <handler.49700.B49700.16277808733968 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 49700
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: 49700 <at> debbugs.gnu.org
Received: via spool by 49700-submit <at> debbugs.gnu.org id=B49700.16277808733968
          (code B ref 49700); Sun, 01 Aug 2021 01:22:01 +0000
Received: (at 49700) by debbugs.gnu.org; 1 Aug 2021 01:21:13 +0000
Received: from localhost ([127.0.0.1]:35219 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1mA0AC-00011v-RZ
	for submit <at> debbugs.gnu.org; Sat, 31 Jul 2021 21:21:13 -0400
Received: from kamnitnik.top ([209.250.245.214]:52030 helo=mail.kamnitnik.top)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <miha@HIDDEN>) id 1mA0AB-00011n-BE
 for 49700 <at> debbugs.gnu.org; Sat, 31 Jul 2021 21:21:12 -0400
Received: from localhost (unknown [IPv6:2a00:ee2:e04:9300:e609:6c46:d026:8c47])
 by mail.kamnitnik.top (Postfix) with ESMTPSA id ADEB2BBB71
 for <49700 <at> debbugs.gnu.org>; Sun,  1 Aug 2021 01:21:09 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kamnitnik.top;
 s=mail; t=1627780869;
 bh=SxNY8po8B11bDuGAe9DMLz6ZtqT4tYRG/6AbMYPHYWY=;
 h=From:To:Subject:In-Reply-To:References:Date:From;
 b=Pwect0Ica1xV3yeX6IFv8e6uEVu47y/wFlKI8+4DYEZMLeGewK2YqR3SyaoOj0Z3N
 NsVf4dZvMhTj1wgPjokf8WohhxmixYM2ReT3onc5ARn92YwckMqudpZc7atRu9fChW
 GE4zOWF80qcQISqfdR/DQarL6zUVzGr8dv6LRL7VBaBZ4rGjv0pohhCq+AtipQwffx
 GUe13s7hUk0IOlq0tVW4iCAML5p6ayzFvPKM4guyypjynxcbpLyJB0SZdk6vzwa/gj
 pyyobB4745bEirFIMpL6R54/CRjhzzyGxULU0TssvFqG06pMHFHU3wMDN5XPl7GCAF
 y/5wZ350ZCMEQ==
From: <miha@HIDDEN>
In-Reply-To: <YPsnLZa5vmDYIpxX@ACM>
References: <87pmvaar0a.fsf@miha-pc> <YPsnLZa5vmDYIpxX@ACM>
Date: Sun, 01 Aug 2021 03:23:32 +0200
Message-ID: <87czqyhsa3.fsf@miha-pc>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="
X-Spam-Score: 2.5 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  Alan Mackenzie <acm@HIDDEN> writes: > Hello, Miha. > > On
 Fri, Jul 23, 2021 at 01:05:41 +0200, miha@HIDDEN wrote: >> The attached
 patch removes special handling of the 'exit tag from >> internal_catch. This
 special handling was i [...] 
 Content analysis details:   (2.5 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 SPF_PASS               SPF: sender matches SPF record
 2.0 PDS_OTHER_BAD_TLD      Untrustworthy TLDs
 [URI: kamnitnik.top (top)]
 0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 0.5 FROM_SUSPICIOUS_NTLD   From abused NTLD
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 2.5 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  Alan Mackenzie <acm@HIDDEN> writes: > Hello, Miha. > > On
   Fri, Jul 23, 2021 at 01:05:41 +0200, miha@HIDDEN wrote: >> The attached
    patch removes special handling of the 'exit tag from >> internal_catch. This
    special handling was i [...] 
 
 Content analysis details:   (2.5 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 SPF_PASS               SPF: sender matches SPF record
  2.0 PDS_OTHER_BAD_TLD      Untrustworthy TLDs
                             [URI: kamnitnik.top (top)]
  0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
  0.5 FROM_SUSPICIOUS_NTLD   From abused NTLD
  1.0 BULK_RE_SUSP_NTLD      Precedence bulk and RE: from a suspicious TLD
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager

--=-=-=
Content-Type: multipart/mixed; boundary="==-=-="

--==-=-=
Content-Type: text/plain
Content-Disposition: inline

Alan Mackenzie <acm@HIDDEN> writes:

> Hello, Miha.
>
> On Fri, Jul 23, 2021 at 01:05:41 +0200, miha@HIDDEN wrote:
>> The attached patch removes special handling of the 'exit tag from
>> internal_catch.  This special handling was introduced by Alan in commit
>> Sun Jan 10 20:32:40 2021 +0000
>> (c7c154bb5756e0ae71d342c5d8aabf725877f186), hence me CC-ing him.
>
> Thanks, that's appreciated.
>
> I'm not sure I'm in favour of the change as a whole, since the proposed
> code contains complexities (as does the code it would replace).  I find
> the use of the closures difficult to understand.  But then again, I wrote
> the old code, so I'm not in a position to judge whether the old or the
> new is "better".
>
>> It also exposes Vminibuffer_list to lisp through the new function
>> Fminibuffer_alist.
>
> Like Eli, I'm against this.  Indeed, when I was modifying the minibuffer
> code, I took great care to avoid Vminibuffer_list becoming visible to
> Lisp.  As a result, some of the current code is less elegant than it
> might have been.  The idea of some Lisp looping through all existing
> minibuffers doing something destructive didn't help me sleep well.
>
> As a general point, I'm a bit worried you might not be distinguishing
> between (minibuffer-depth) and (recursive-depth).  They are only the same
> most of the time.  When (recursive-edit) gets called outside of the
> minibuffer code, then these two values are different.  For example, in 
> abort-minibuffers, you've got
>
>> +      (when (yes-or-no-p
>> +             (format "Abort %s minibuffer levels? "
>> +                     (- (recursion-depth) minibuffer-level -1)))
>
> ..  minibuffer-level is confusingly a result of (recursion-depth), not
> (minibuffer-depth), so the code isn't prompting with the number of
> minibuffer levels to be aborted, but the number of recursive edits.
>
> As a small point, the use of cl-decf:
>
>> +        (cl-decf minibuffer-level)))
>
> might be unwise.  Have you checked that it works in a bootstrap build?
> My fear is that in a bootstrap, minibuffer.el might be compiled before
> the CL files, and then cl-decf would be wrongly compiled as a function
> call rather than a macro expansion.  But I haven't checked it myself.

Thanks for feedback.  Attached is a patch that should address all of
these issues.  Overall, this patch is much simpler than the original
patch I proposed and the closure passing should now be hopefully easier
to understand.

> I've also had a look a part of your patch from Tuesday (2021-07-20), and
> am unhappy about some aspects of the change to the documentation on the
> Elisp manual page Recursive Editing.  For example, the text no longer
> says what happens on throwing a random value to 'exit (but it used to).
> Also this text is generally a bit unclear; what does "a function value"
> mean?  I would normally understand "the value returned by a function",
> but here it just means the function.  But I think it would be better for
> me to raise these issues in a different thread.
>
Please take a look at the second patch, attached to this message.  I
tried to improve the documentation of exiting a recursive edit in
lispref.  I also adjusted the doc string of the function
`recursive-edit', which I forgot to do in my older patch from
2021-07-20.
>
> -- 
> Alan Mackenzie (Nuremberg, Germany).

--==-=-=
Content-Type: text/x-patch
Content-Disposition: inline;
 filename=0001-Refactor-minibuffer-aborting.patch

From 91276c2485b518850b2d0d02be1823439571a3f9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Miha=20Rihtar=C5=A1i=C4=8D?= <miha@HIDDEN>
Date: Sat, 31 Jul 2021 13:44:21 +0200
Subject: [PATCH] Refactor minibuffer aborting

* lisp/minibuffer.el (minibuffer-quit-recursive-edit): New optional
argument to specify how many levels of recursion to quit.

* src/minibuf.c (Fabort_minibuffers): Use
minibuffer-quit-recursive-edit to quit multiple levels of minibuffer
recursion.

* src/eval.c (internal_catch): Remove special handling of 'exit tag.
---
 lisp/minibuffer.el | 16 ++++++++++------
 src/eval.c         | 22 ----------------------
 src/lisp.h         |  1 -
 src/minibuf.c      |  4 ++--
 4 files changed, 12 insertions(+), 31 deletions(-)

diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 3751ba80e0..912e186b06 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -2328,14 +2328,18 @@ exit-minibuffer
   (setq deactivate-mark nil)
   (throw 'exit nil))
 
-(defun minibuffer-quit-recursive-edit ()
+(defun minibuffer-quit-recursive-edit (&optional levels)
   "Quit the command that requested this recursive edit without error.
 Like `abort-recursive-edit' without aborting keyboard macro
-execution."
-  ;; See Info node `(elisp)Recursive Editing' for an explanation of
-  ;; throwing a function to `exit'.
-  (throw 'exit (lambda ()
-                 (signal 'minibuffer-quit nil))))
+execution.  LEVELS specifies the number of nested recursive edits
+to quit.  If nil, it defaults to 1."
+  (unless levels
+    (setq levels 1))
+  (if (> levels 1)
+      ;; See Info node `(elisp)Recursive Editing' for an explanation
+      ;; of throwing a function to `exit'.
+      (throw 'exit (lambda () (minibuffer-quit-recursive-edit (1- levels))))
+    (throw 'exit (lambda () (signal 'minibuffer-quit nil)))))
 
 (defun self-insert-and-exit ()
   "Terminate minibuffer input."
diff --git a/src/eval.c b/src/eval.c
index 48104bd0f4..76fe671b6d 100644
--- a/src/eval.c
+++ b/src/eval.c
@@ -1174,14 +1174,6 @@ #define clobbered_eassert(E) verify (sizeof (E) != 0)
    FUNC should return a Lisp_Object.
    This is how catches are done from within C code.  */
 
-/* MINIBUFFER_QUIT_LEVEL is to handle quitting from nested minibuffers by
-   throwing t to tag `exit'.
-   0 means there is no (throw 'exit t) in progress, or it wasn't from
-     a minibuffer which isn't the most nested;
-   N > 0 means the `throw' was done from the minibuffer at level N which
-     wasn't the most nested.  */
-EMACS_INT minibuffer_quit_level = 0;
-
 Lisp_Object
 internal_catch (Lisp_Object tag,
 		Lisp_Object (*func) (Lisp_Object), Lisp_Object arg)
@@ -1189,9 +1181,6 @@ internal_catch (Lisp_Object tag,
   /* This structure is made part of the chain `catchlist'.  */
   struct handler *c = push_handler (tag, CATCHER);
 
-  if (EQ (tag, Qexit))
-    minibuffer_quit_level = 0;
-
   /* Call FUNC.  */
   if (! sys_setjmp (c->jmp))
     {
@@ -1205,17 +1194,6 @@ internal_catch (Lisp_Object tag,
       Lisp_Object val = handlerlist->val;
       clobbered_eassert (handlerlist == c);
       handlerlist = handlerlist->next;
-      if (EQ (tag, Qexit) && EQ (val, Qt) && minibuffer_quit_level > 0)
-	/* If we've thrown t to tag `exit' from within a minibuffer, we
-	   exit all minibuffers more deeply nested than the current
-	   one.  */
-	{
-	  if (minibuf_level > minibuffer_quit_level
-	      && !NILP (Fminibuffer_innermost_command_loop_p (Qnil)))
-            Fthrow (Qexit, Qt);
-	  else
-	    minibuffer_quit_level = 0;
-	}
       return val;
     }
 }
diff --git a/src/lisp.h b/src/lisp.h
index 15a42a4456..4fdee6c280 100644
--- a/src/lisp.h
+++ b/src/lisp.h
@@ -4112,7 +4112,6 @@ intern_c_string (const char *str)
 }
 
 /* Defined in eval.c.  */
-extern EMACS_INT minibuffer_quit_level;
 extern Lisp_Object Vautoload_queue;
 extern Lisp_Object Vrun_hooks;
 extern Lisp_Object Vsignaling_function;
diff --git a/src/minibuf.c b/src/minibuf.c
index 0f4349e70b..f7cd2c5fcc 100644
--- a/src/minibuf.c
+++ b/src/minibuf.c
@@ -491,8 +491,8 @@ DEFUN ("abort-minibuffers", Fabort_minibuffers, Sabort_minibuffers, 0, 0, "",
       array[1] = make_fixnum (minibuf_level - minibuf_depth + 1);
       if (!NILP (Fyes_or_no_p (Fformat (2, array))))
 	{
-	  minibuffer_quit_level = minibuf_depth;
-	  Fthrow (Qexit, Qt);
+	  CALLN (Ffuncall, intern ("minibuffer-quit-recursive-edit"),
+		 array[1]);
 	}
     }
   else
-- 
2.32.0


--==-=-=
Content-Type: text/x-patch
Content-Disposition: inline;
 filename=0001-Improve-documentation-of-exiting-recursive-editing.patch

From bdccb4d9399090ffe08cbdde289b5a1afd0c310d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Miha=20Rihtar=C5=A1i=C4=8D?= <miha@HIDDEN>
Date: Sun, 1 Aug 2021 02:41:37 +0200
Subject: [PATCH] Improve documentation of exiting recursive editing

* doc/lispref/commands.texi (Recursive Editing): Mention what happens
when throwing a string or any other value to 'exit.
* src/keyboard.c (Frecursive_edit): Document throwing a function to 'exit.
---
 doc/lispref/commands.texi | 22 ++++++++++++----------
 src/keyboard.c            | 18 ++++++++++++++----
 2 files changed, 26 insertions(+), 14 deletions(-)

diff --git a/doc/lispref/commands.texi b/doc/lispref/commands.texi
index b4a8b733a0..e0982b14bb 100644
--- a/doc/lispref/commands.texi
+++ b/doc/lispref/commands.texi
@@ -3568,17 +3568,19 @@ Recursive Editing
 @cindex exit recursive editing
 @cindex aborting
   To invoke a recursive editing level, call the function
-@code{recursive-edit}.  This function contains the command loop; it also
-contains a call to @code{catch} with tag @code{exit}, which makes it
-possible to exit the recursive editing level by throwing to @code{exit}
-(@pxref{Catch and Throw}).  If you throw a @code{nil} value, then
-@code{recursive-edit} returns normally to the function that called it.
-The command @kbd{C-M-c} (@code{exit-recursive-edit}) does this.
-Throwing a @code{t} value causes @code{recursive-edit} to quit, so that
-control returns to the command loop one level up.  This is called
-@dfn{aborting}, and is done by @kbd{C-]} (@code{abort-recursive-edit}).
-You can also throw a function value.  In that case,
+@code{recursive-edit}.  This function contains the command loop; it
+also contains a call to @code{catch} with tag @code{exit}, which makes
+it possible to exit the recursive editing level by throwing to
+@code{exit} (@pxref{Catch and Throw}).  Throwing a @code{t} value
+causes @code{recursive-edit} to quit, so that control returns to the
+command loop one level up.  This is called @dfn{aborting}, and is done
+by @kbd{C-]} (@code{abort-recursive-edit}).  Similarly, you can throw
+a string value to make @code{recursive-edit} signal an error, printing
+this string as the message.  If you throw a function,
 @code{recursive-edit} will call it without arguments before returning.
+Throwing any other value, will make @code{recursive-edit} return
+normally to the function that called it.  The command @kbd{C-M-c}
+(@code{exit-recursive-edit}) does this.
 
   Most applications should not use recursive editing, except as part of
 using the minibuffer.  Usually it is more convenient for the user if you
diff --git a/src/keyboard.c b/src/keyboard.c
index 820229cf8f..06509bcb72 100644
--- a/src/keyboard.c
+++ b/src/keyboard.c
@@ -753,10 +753,20 @@ DEFUN ("recursive-edit", Frecursive_edit, Srecursive_edit, 0, 0, "",
        doc: /* Invoke the editor command loop recursively.
 To get out of the recursive edit, a command can throw to `exit' -- for
 instance (throw \\='exit nil).
-If you throw a value other than t, `recursive-edit' returns normally
-to the function that called it.  Throwing a t value causes
-`recursive-edit' to quit, so that control returns to the command loop
-one level up.
+
+The following values can be thrown to 'exit:
+
+- t causes `recursive-edit' to quit, so that control returns to the
+  command loop one level up.
+
+- A string causes `recursive-edit' to signal an error, printing this
+  string as the message.
+
+- A function causes `recursive-edit' to call this function without
+  arguments before returning normally.
+
+- Any other value causes `recursive-edit' to return normally to the
+  function that called it.
 
 This function is called by the editor initialization to begin editing.  */)
   (void)
-- 
2.32.0


--==-=-=--

--=-=-=
Content-Type: application/pgp-signature; name=signature.asc
Content-Transfer-Encoding: base64

LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KCmlRSkhCQUVCQ0FBeEZpRUVteFZuZXNvVDVy
UVh2Vlhuc3drYUdwSVZtVDhGQW1FRjlEQVRIRzFwYUdGQWEyRnQKYm1sMGJtbHJMblJ2Y0FBS0NS
Q3pDUm9ha2hXWlA1ZmNELzBiTm5TdE9EYThJTUZMWEFjaHpFWTgyYWtUOVFubQpuNitoYW9QalBB
dWJ6MUd4V0t5VGVhNEdlYzZ0TU1mdE1iei84blB6bmFaV05tWTJhZVg0TGMyd3d2QXQyN2dOCitS
UWIxV0x1YWxCcUQ0cWloOTBleHJOMEFwZ1BFRTA1N1RDMXcxYWtRc21Ob2xtcG5GSE90L0EyK1NF
ME9jR2wKK0cvWERlbjZmaGo2cGZNUzZ3OGxYbU9udFhjM2NjVVNCYXU3SVpSdWtLNHdLcGM5QnlF
cDkwUG5sSks1eU9QSQpvc3NVb3BYQTdQWUlaNG9jc0k3Y290TmZZWDRhc1ZqSDArdUJUakdIenVP
Tk5kdjIwNXUydHMzUXU5dlVscmswCjI2ZGZmK0F4SkJlSEh0Z1JNcTBudWJZMHVNS1FhT1hCZDRz
TkQwV3pVaVNDeWRMTU9ndFdCSzFITVlkNWZKVnUKNTNjQUFpM3NkdHA5aVNncklNYkNiazVrWkY3
b3lFblh0aWE0TnBRK0RWZm9hUGUwYk11WVJvR09WbnNONGVkRAplUmVJNE1CZXJwOXlDZytmY0h0
MWJ3ZVpiQ05KV0R4ZGJySmNvUmJCOGJqTTVpN2t0T251bXo3YkxqYlpwa0JqCkhudURVczJ4M2w0
ZndHVEo4UHhmRjR0VmNib1grMzA5Qi9vdmRRUW9YM085Nzg5ZzBjQnVtK2F4NTFCOFA3ZGUKaCtO
aC9qeHU5a2RNalVMeUVNS1BUVUZna05lcHR1S3JUSytwRStJUzYrNVU2di8xR3hnTUQzdjcyZTky
K1ZBMwpNOG16QjlNRDRZWmJRZHE4QzFkSm4rZmFLaVhCMVRNdDhQc29uSm15dC9QZzFPOUZFWCs5
anFXeHpqbm1BOWlxCmVYS09laWI1VmdOMEVRPT0KPWthWE4KLS0tLS1FTkQgUEdQIFNJR05BVFVS
RS0tLS0t
--=-=-=--




Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#49700: 27.2; [PATCH] Refactor minibuffer aborting
Resent-From: Alan Mackenzie <acm@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 06 Aug 2021 20:16:01 +0000
Resent-Message-ID: <handler.49700.B49700.162828090315872 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 49700
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: 49700 <at> debbugs.gnu.org
Received: via spool by 49700-submit <at> debbugs.gnu.org id=B49700.162828090315872
          (code B ref 49700); Fri, 06 Aug 2021 20:16:01 +0000
Received: (at 49700) by debbugs.gnu.org; 6 Aug 2021 20:15:03 +0000
Received: from localhost ([127.0.0.1]:51416 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1mC6FD-00047v-2p
	for submit <at> debbugs.gnu.org; Fri, 06 Aug 2021 16:15:03 -0400
Received: from colin.muc.de ([193.149.48.1]:44433 helo=mail.muc.de)
 by debbugs.gnu.org with smtp (Exim 4.84_2)
 (envelope-from <acm@HIDDEN>) id 1mC6F8-000477-ND
 for 49700 <at> debbugs.gnu.org; Fri, 06 Aug 2021 16:15:02 -0400
Received: (qmail 73990 invoked by uid 3782); 6 Aug 2021 20:14:51 -0000
Received: from acm.muc.de (p4fe156b7.dip0.t-ipconnect.de [79.225.86.183])
 (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP;
 Fri, 06 Aug 2021 22:14:51 +0200
Received: (qmail 3133 invoked by uid 1000); 6 Aug 2021 20:14:51 -0000
Date: Fri, 6 Aug 2021 20:14:51 +0000
Message-ID: <YQ2YO6//RAUgQdTp@ACM>
References: <87pmvaar0a.fsf@miha-pc> <YPsnLZa5vmDYIpxX@ACM>
 <87im0qrmxe.fsf@miha-pc>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87im0qrmxe.fsf@miha-pc>
X-Submission-Agent: TMDA/1.3.x (Ph3nix)
From: Alan Mackenzie <acm@HIDDEN>
X-Primary-Address: acm@HIDDEN
X-Spam-Score: 2.0 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  Hello again, Miha. On Sun, Aug 01, 2021 at 03:09:01 +0200,
 miha@HIDDEN wrote: > Alan Mackenzie <acm@HIDDEN> writes: > > Hello,
 Miha. Content analysis details:   (2.0 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 SPF_PASS               SPF: sender matches SPF record
 2.0 PDS_OTHER_BAD_TLD      Untrustworthy TLDs
 [URI: kamnitnik.top (top)]
 0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.0 (+)

Hello again, Miha.

On Sun, Aug 01, 2021 at 03:09:01 +0200, miha@HIDDEN wrote:
> Alan Mackenzie <acm@HIDDEN> writes:

> > Hello, Miha.

> > On Fri, Jul 23, 2021 at 01:05:41 +0200, miha@HIDDEN wrote:
> >> The attached patch removes special handling of the 'exit tag from
> >> internal_catch.  This special handling was introduced by Alan in commit
> >> Sun Jan 10 20:32:40 2021 +0000
> >> (c7c154bb5756e0ae71d342c5d8aabf725877f186), hence me CC-ing him.

> > Thanks, that's appreciated.

> > I'm not sure I'm in favour of the change as a whole, since the proposed
> > code contains complexities (as does the code it would replace).  I find
> > the use of the closures difficult to understand.  But then again, I wrote
> > the old code, so I'm not in a position to judge whether the old or the
> > new is "better".

> >> It also exposes Vminibuffer_list to lisp through the new function
> >> Fminibuffer_alist.

> > Like Eli, I'm against this.  Indeed, when I was modifying the minibuffer
> > code, I took great care to avoid Vminibuffer_list becoming visible to
> > Lisp.  As a result, some of the current code is less elegant than it
> > might have been.  The idea of some Lisp looping through all existing
> > minibuffers doing something destructive didn't help me sleep well.

> > As a general point, I'm a bit worried you might not be distinguishing
> > between (minibuffer-depth) and (recursive-depth).  They are only the same
> > most of the time.  When (recursive-edit) gets called outside of the
> > minibuffer code, then these two values are different.  For example, in 
> > abort-minibuffers, you've got

> >> +      (when (yes-or-no-p
> >> +             (format "Abort %s minibuffer levels? "
> >> +                     (- (recursion-depth) minibuffer-level -1)))

> > ..  minibuffer-level is confusingly a result of (recursion-depth), not
> > (minibuffer-depth), so the code isn't prompting with the number of
> > minibuffer levels to be aborted, but the number of recursive edits.

> > As a small point, the use of cl-decf:

> >> +        (cl-decf minibuffer-level)))

> > might be unwise.  Have you checked that it works in a bootstrap build?
> > My fear is that in a bootstrap, minibuffer.el might be compiled before
> > the CL files, and then cl-decf would be wrongly compiled as a function
> > call rather than a macro expansion.  But I haven't checked it myself.

> Thanks for feedback.  Attached is a patch that should address all of
> these issues.

I'm not sure it does.  It still looks unclear to me how you are
distinguishing recursive edit levels from minibuffer depth.  For example,
in Fabort_minibuffers (minibuf.c), the argument passed to
minibuffer-quit-recursive-edit is the number of minibuffer levels to be
aborted.  Yet the doc string of minibuffer-quit-recursive-edit refers to 
LEVELS as "the number of nested recursive edits".  Either the doc string
or the code is erroneous here.  Again, what's needed is "the number of
nested minibuffer calls".

I'm also a touch concerned about the "Like `abort-recursive-edit'" in the
doc string, since minibuffer-quit-recursive-edit is significantly
different from abort-recursive-edit.  It can also be aggravating for a
user to have to look somewhere else (here abort-recursive-edit) to
discover the semantics of a Lisp function.

> Overall, this patch is much simpler than the original
> patch I proposed and the closure passing should now be hopefully easier
> to understand.

I think closures are difficult to understand in any circumstances.  But
that's just my personal take on things.

> > I've also had a look a part of your patch from Tuesday (2021-07-20), and
> > am unhappy about some aspects of the change to the documentation on the
> > Elisp manual page Recursive Editing.  For example, the text no longer
> > says what happens on throwing a random value to 'exit (but it used to).
> > Also this text is generally a bit unclear; what does "a function value"
> > mean?  I would normally understand "the value returned by a function",
> > but here it just means the function.  But I think it would be better for
> > me to raise these issues in a different thread.

> Please take a look at the second patch, attached to this message.  I
> tried to improve the documentation of exiting a recursive edit in
> lispref.  I also adjusted the doc string of the function
> `recursive-edit', which I forgot to do in my older patch from
> 2021-07-20.

Thanks, that's a lot better!

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).




Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#49700: 27.2; [PATCH] Refactor minibuffer aborting
Resent-From: <miha@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 06 Aug 2021 22:44:02 +0000
Resent-Message-ID: <handler.49700.B49700.16282897925010 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 49700
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Alan Mackenzie <acm@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 49700 <at> debbugs.gnu.org
Received: via spool by 49700-submit <at> debbugs.gnu.org id=B49700.16282897925010
          (code B ref 49700); Fri, 06 Aug 2021 22:44:02 +0000
Received: (at 49700) by debbugs.gnu.org; 6 Aug 2021 22:43:12 +0000
Received: from localhost ([127.0.0.1]:51497 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1mC8Ya-0001Ik-7o
	for submit <at> debbugs.gnu.org; Fri, 06 Aug 2021 18:43:12 -0400
Received: from kamnitnik.top ([209.250.245.214]:39086 helo=mail.kamnitnik.top)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <miha@HIDDEN>) id 1mC8YW-0001IZ-CT
 for 49700 <at> debbugs.gnu.org; Fri, 06 Aug 2021 18:43:10 -0400
Received: from localhost (unknown [IPv6:2a00:ee2:e04:9300:e609:6c46:d026:8c47])
 by mail.kamnitnik.top (Postfix) with ESMTPSA id CC1BDBCF6B;
 Fri,  6 Aug 2021 22:43:06 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kamnitnik.top;
 s=mail; t=1628289786;
 bh=eQFqXZk60gJYb5+np0mSNZMgW8Pu+uv35T9zmg6+rw4=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=Q373kTZPjgB6nM9sOK0PU0Gc7TJRbAqmuebcQ9oKrF1YEJuzTYXeKowXdr8D5O/97
 iiKhmnOjUvk5VwnSoPwLpCeignd4YN+77BEv9jMBTnSn1hGHll4x3oq3LzS8yhd/6V
 LYHIuQlHQii6aDytcNFnbA43jdw+7gb+luIgpxEGvWCEC8BL+bAV1uG03u8pWmEJEL
 Z+5VlMWUy75jkFNYnI2h7qJAUStjh4tt9ECT9S7/C84WSGHGcx0R9nj6XgPGbD0XfI
 EjUZ5zi5P3HxuGiRWcLdYK2UE8850axfRoLlmwq/9fFuMMOAAloI2Q3b4wB2TN5UWq
 zZnjccEmp3YHg==
From: <miha@HIDDEN>
In-Reply-To: <YQ2XHG6k6olofEb/@ACM>
References: <87pmvaar0a.fsf@miha-pc> <YPsnLZa5vmDYIpxX@ACM>
 <87im0qrmxe.fsf@miha-pc> <YQ2XHG6k6olofEb/@ACM>
Date: Sat, 07 Aug 2021 00:45:28 +0200
Message-ID: <87eeb6b3av.fsf@miha-pc>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
 micalg=pgp-sha256; protocol="application/pgp-signature"
X-Spam-Score: 2.5 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  Alan Mackenzie <acm@HIDDEN> writes: > Hello again, Miha. >
 > On Sun, Aug 01, 2021 at 03:09:01 +0200, miha@HIDDEN wrote: >> Alan
 Mackenzie <acm@HIDDEN> writes: > >> > Hello, Miha. > >> > On Fri, Jul 23,
 2021 at 01:05:41 +0200, mih [...] 
 Content analysis details:   (2.5 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 SPF_PASS               SPF: sender matches SPF record
 2.0 PDS_OTHER_BAD_TLD      Untrustworthy TLDs
 [URI: kamnitnik.top (top)]
 0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 0.5 FROM_SUSPICIOUS_NTLD   From abused NTLD
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 2.5 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  Alan Mackenzie <acm@HIDDEN> writes: > Hello again, Miha. >
    > On Sun, Aug 01, 2021 at 03:09:01 +0200, miha@HIDDEN wrote: >> Alan
    Mackenzie <acm@HIDDEN> writes: > >> > Hello, Miha. > >> > On Fri, Jul 23,
    2021 at 01:05:41 +0200, mih [...] 
 
 Content analysis details:   (2.5 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 SPF_PASS               SPF: sender matches SPF record
  2.0 PDS_OTHER_BAD_TLD      Untrustworthy TLDs
                             [URI: kamnitnik.top (top)]
  0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
  0.5 FROM_SUSPICIOUS_NTLD   From abused NTLD
  1.0 BULK_RE_SUSP_NTLD      Precedence bulk and RE: from a suspicious TLD
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager

--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Alan Mackenzie <acm@HIDDEN> writes:

> Hello again, Miha.
>
> On Sun, Aug 01, 2021 at 03:09:01 +0200, miha@HIDDEN wrote:
>> Alan Mackenzie <acm@HIDDEN> writes:
>
>> > Hello, Miha.
>
>> > On Fri, Jul 23, 2021 at 01:05:41 +0200, miha@HIDDEN wrote:
>> >> The attached patch removes special handling of the 'exit tag from
>> >> internal_catch.  This special handling was introduced by Alan in comm=
it
>> >> Sun Jan 10 20:32:40 2021 +0000
>> >> (c7c154bb5756e0ae71d342c5d8aabf725877f186), hence me CC-ing him.
>
>> > Thanks, that's appreciated.
>
>> > I'm not sure I'm in favour of the change as a whole, since the proposed
>> > code contains complexities (as does the code it would replace).  I find
>> > the use of the closures difficult to understand.  But then again, I wr=
ote
>> > the old code, so I'm not in a position to judge whether the old or the
>> > new is "better".
>
>> >> It also exposes Vminibuffer_list to lisp through the new function
>> >> Fminibuffer_alist.
>
>> > Like Eli, I'm against this.  Indeed, when I was modifying the minibuff=
er
>> > code, I took great care to avoid Vminibuffer_list becoming visible to
>> > Lisp.  As a result, some of the current code is less elegant than it
>> > might have been.  The idea of some Lisp looping through all existing
>> > minibuffers doing something destructive didn't help me sleep well.
>
>> > As a general point, I'm a bit worried you might not be distinguishing
>> > between (minibuffer-depth) and (recursive-depth).  They are only the s=
ame
>> > most of the time.  When (recursive-edit) gets called outside of the
>> > minibuffer code, then these two values are different.  For example, in=
=20
>> > abort-minibuffers, you've got
>
>> >> +      (when (yes-or-no-p
>> >> +             (format "Abort %s minibuffer levels? "
>> >> +                     (- (recursion-depth) minibuffer-level -1)))
>
>> > ..  minibuffer-level is confusingly a result of (recursion-depth), not
>> > (minibuffer-depth), so the code isn't prompting with the number of
>> > minibuffer levels to be aborted, but the number of recursive edits.
>
>> > As a small point, the use of cl-decf:
>
>> >> +        (cl-decf minibuffer-level)))
>
>> > might be unwise.  Have you checked that it works in a bootstrap build?
>> > My fear is that in a bootstrap, minibuffer.el might be compiled before
>> > the CL files, and then cl-decf would be wrongly compiled as a function
>> > call rather than a macro expansion.  But I haven't checked it myself.
>
>> Thanks for feedback.  Attached is a patch that should address all of
>> these issues.
>
> I'm not sure it does. It still looks unclear to me how you are
> distinguishing recursive edit levels from minibuffer depth. For
> example, in Fabort_minibuffers (minibuf.c), the argument passed to
> minibuffer-quit-recursive-edit is the number of minibuffer levels to
> be aborted. Yet the doc string of minibuffer-quit-recursive-edit
> refers to LEVELS as "the number of nested recursive edits". Either the
> doc string or the code is erroneous here. Again, what's needed is "the
> number of nested minibuffer calls".

True, my code would indeed be incorrect if the number of minibuffer
levels to be aborted weren't to match the number of recursive edits.
However, in such cases, my code isn't reached because an error is
signaled that the current minibuffer isn't in the innermost command
loop.

Sorry for not clarifying this earlier. Would it would be enough to
include the following comment in the code?:

/* Due to the above check, the current minibuffer is in the most nested
   command loop, which means that we don't have to abort any extra
   non-minibuffer recursive edits.  Thus, the number of recursive edits
   we have to abort equals the number of minibuffers we have to abort.
   */

I have also tested various sequences of minibuffers and M-x
recursive-edit with and without this patch and in both cases, behaviour
is the same: C-g will only abort minibuffers and will never let you
abort any M-x recursive-edit, even if it is hidden behind nested
minibuffers.

>
> I'm also a touch concerned about the "Like `abort-recursive-edit'" in the
> doc string, since minibuffer-quit-recursive-edit is significantly
> different from abort-recursive-edit.

Hmm... as I see it, they are pretty much equivalent: Code-wise,
abort-recursive-edit throws 't to 'exit, which is equivalent to throwing
(lambda () (signal 'quit)) to 'exit. This is the same as
minibuffer-quit-recursive-edit except for the error signal (and of
course, the new optional argument in this patch and the interactive
spec. Should the new function perhaps also be made interactive?).

Behaviour-wise, as described in the doc string, the only difference is
that abort-recursive-edit causes kmacro termination and the new function
doesn't.

> It can also be aggravating for a user to have to look somewhere else
> (here abort-recursive-edit) to discover the semantics of a Lisp
> function.

Perhaps the following adjustment to the doc string could be considered
(to be applied on top of the latest patch). It copies the beginning of
abort-recursive-edit's doc string and removes the link to it.

diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 912e186b06..55886ac015 100644
=2D-- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -2331,6 +2331,6 @@ exit-minibuffer
 (defun minibuffer-quit-recursive-edit (&optional levels)
=2D  "Quit the command that requested this recursive edit without error.
=2DLike `abort-recursive-edit' without aborting keyboard macro
=2Dexecution.  LEVELS specifies the number of nested recursive edits
=2Dto quit.  If nil, it defaults to 1."
+  "Quit the command that requested this recursive edit or minibuffer input.
+Do so without terminationg keyboard macro recording or execution.
+LEVELS specifies the number of nested recursive edits to quit.
+If nil, it defaults to 1."
   (unless levels

>
>> Overall, this patch is much simpler than the original
>> patch I proposed and the closure passing should now be hopefully easier
>> to understand.
>
> I think closures are difficult to understand in any circumstances.  But
> that's just my personal take on things.

In this case, both closures in minibuffer-quit-recursive-edit could be
rewritten in terms of `apply-partially' (which returns a closure,
obviously), but maybe partially applied functions could be easier to
reason about than closures?

>
>> > I've also had a look a part of your patch from Tuesday (2021-07-20), a=
nd
>> > am unhappy about some aspects of the change to the documentation on the
>> > Elisp manual page Recursive Editing.  For example, the text no longer
>> > says what happens on throwing a random value to 'exit (but it used to).
>> > Also this text is generally a bit unclear; what does "a function value"
>> > mean?  I would normally understand "the value returned by a function",
>> > but here it just means the function.  But I think it would be better f=
or
>> > me to raise these issues in a different thread.
>
>> Please take a look at the second patch, attached to this message.  I
>> tried to improve the documentation of exiting a recursive edit in
>> lispref.  I also adjusted the doc string of the function
>> `recursive-edit', which I forgot to do in my older patch from
>> 2021-07-20.
>
> Thanks, that's a lot better!
>
> [ .... ]
>
> --=20
> Alan Mackenzie (Nuremberg, Germany).

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJHBAEBCAAxFiEEmxVnesoT5rQXvVXnswkaGpIVmT8FAmENu4gTHG1paGFAa2Ft
bml0bmlrLnRvcAAKCRCzCRoakhWZPxtAD/934oox+/4txErHw/j5BcUEHtbU0RQ0
wC8g+ui5q+MuwyOYSEJr/RdEqq9aEskiKGOsygsaxg+2Mxo19I3spIGrosMny5cB
m0/fy6DQETOrn7G1O4aBU7mCvuNfoPKEZdoCjCuEz3n1j2a93baH9wIUKs9vODnL
xHCtoBO9z3WzC1dnDZY1U+zVfsRR/UbLsj9b7qCp9bdYqyIpFphKFo04UNyfcSsk
KlN8BXHpEnfHnRp0noWxdbjoRiiaIL5z3/564dQnyGI1A48KL3ZGYvRJ/Vw4++Lm
y6kZouiCuS1J3BrRbFgjq7B5C69eXaeZPTa3znrRTC/5w3PxN19wNp/pnclJy+QO
bTePTc3clFQ4has6g8nLgaot7GZICya0GknpBRAo2oKkwvaZ1sld6mnxKLtZdt+H
paVL8S5g4iWS9sgREvaFuCkOOpdIlz8dTBcSeZVv4phlhPa9To3sLxpXxEDy6zFr
6fgkwkihkrybi+hGh5GJ0tKwV1tnV7SB8ZJCRQdQPMEV1PaFEOqi7iEvEMetl7b8
3mZ5Eh94CdhQ2xGMHcHE3tOymWUtsBCCduIkCr0BxAg5DDBDOj6pSIYnplrsSpDx
8THhCD91FE3O6U/I4t9UfzYPppICc8nNdZTJB22RdksLvD09brMCdQjByFvhzFoU
tR2QCj4YhYZRKw==
=U9jN
-----END PGP SIGNATURE-----
--=-=-=--




Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#49700: 27.2; [PATCH] Refactor minibuffer aborting
Resent-From: <miha@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 17 Sep 2021 21:45:02 +0000
Resent-Message-ID: <handler.49700.B49700.163191506822925 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 49700
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Alan Mackenzie <acm@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 49700 <at> debbugs.gnu.org
Received: via spool by 49700-submit <at> debbugs.gnu.org id=B49700.163191506822925
          (code B ref 49700); Fri, 17 Sep 2021 21:45:02 +0000
Received: (at 49700) by debbugs.gnu.org; 17 Sep 2021 21:44:28 +0000
Received: from localhost ([127.0.0.1]:33183 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1mRLel-0005xg-G6
	for submit <at> debbugs.gnu.org; Fri, 17 Sep 2021 17:44:28 -0400
Received: from kamnitnik.top ([209.250.245.214]:57770)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <miha@HIDDEN>) id 1mRLeg-0005xV-Lb
 for 49700 <at> debbugs.gnu.org; Fri, 17 Sep 2021 17:44:26 -0400
Received: from localhost (unknown [IPv6:2a00:ee2:e04:9300:e18:5d33:4bd1:d3a4])
 by kamnitnik.top (Postfix) with ESMTPSA id 35A489C5E5;
 Fri, 17 Sep 2021 21:44:21 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kamnitnik.top;
 s=mail; t=1631915061;
 bh=yklCj4q6ZrKn+bX+aN18Qdvp2f6SqFY7gTtZpTbFwr8=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=ju1D1EtS3rI8/PvE9Pzj6OY1paGsZrnO4LAQzr+fqoAnyJRmZQKishoi9cTypiBIM
 02vgAhuJM+6L/F6Yn9njuXwsmtZR9tD3SBRgdRCyk+n6St02IHgS1l6lUC+aIHXcPy
 I5xn38mOo08rOpERWmwFUkjL0XH6UM4MIkbZuKUyKbC1OjVoBJF5a9JAREjv0mFxpS
 mwdAVQtXgch672EqdNnky4AOkq1BuRqmZ3rhOGlqf7vWdLxwAtYOaHogr7Yih616c5
 CwH2KzvbuXu/5yuLOq98tXjC3oJ/HJV97FOyc+UDfmNyp4sxn3nMHJiY0zB7AOaum+
 UA0UFA/g3chjg==
From: <miha@HIDDEN>
In-Reply-To: <87eeb6b3av.fsf@miha-pc>
References: <87pmvaar0a.fsf@miha-pc> <YPsnLZa5vmDYIpxX@ACM>
 <87im0qrmxe.fsf@miha-pc> <YQ2XHG6k6olofEb/@ACM> <87eeb6b3av.fsf@miha-pc>
Date: Fri, 17 Sep 2021 23:47:35 +0200
Message-ID: <87pmt6ho20.fsf@miha-pc>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="==-=-=";
 micalg=pgp-sha256; protocol="application/pgp-signature"
X-Spam-Score: 2.5 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  miha--- via "Bug reports for GNU Emacs, the Swiss army knife
 of text editors" <bug-gnu-emacs@HIDDEN> writes: > True, my code would indeed
 be incorrect if the number of minibuffer > levels to be aborted weren't to
 match the number of recursive edits. > However, in such cases, my code isn't
 reached because an [...] 
 Content analysis details:   (2.5 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 SPF_PASS               SPF: sender matches SPF record
 2.0 PDS_OTHER_BAD_TLD      Untrustworthy TLDs
 [URI: kamnitnik.top (top)]
 -0.0 SPF_HELO_PASS          SPF: HELO matches SPF record
 0.5 FROM_SUSPICIOUS_NTLD   From abused NTLD
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 2.5 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  miha--- via "Bug reports for GNU Emacs, the Swiss army knife
    of text editors" <bug-gnu-emacs@HIDDEN> writes: > True, my code would indeed
    be incorrect if the number of minibuffer > levels to be aborted weren't to
    match the number of recursive edits. > However, in such cases, my code isn't
    reached because an [...] 
 
 Content analysis details:   (2.5 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 SPF_PASS               SPF: sender matches SPF record
  2.0 PDS_OTHER_BAD_TLD      Untrustworthy TLDs
                             [URI: kamnitnik.top (top)]
 -0.0 SPF_HELO_PASS          SPF: HELO matches SPF record
  0.5 FROM_SUSPICIOUS_NTLD   From abused NTLD
  1.0 BULK_RE_SUSP_NTLD      Precedence bulk and RE: from a suspicious TLD
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager

--==-=-=
Content-Type: multipart/mixed; boundary="=-=-="

--=-=-=
Content-Type: text/plain

miha--- via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs@HIDDEN> writes:

> True, my code would indeed be incorrect if the number of minibuffer
> levels to be aborted weren't to match the number of recursive edits.
> However, in such cases, my code isn't reached because an error is
> signaled that the current minibuffer isn't in the innermost command
> loop.
>
> Sorry for not clarifying this earlier. Would it would be enough to
> include the following comment in the code?:
>
> /* Due to the above check, the current minibuffer is in the most nested
>    command loop, which means that we don't have to abort any extra
>    non-minibuffer recursive edits.  Thus, the number of recursive edits
>    we have to abort equals the number of minibuffers we have to abort.
>    */
>
> [...]


> Perhaps the following adjustment to the doc string could be considered
> (to be applied on top of the latest patch). It copies the beginning of
> abort-recursive-edit's doc string and removes the link to it.
>
> [...]

I realized that my proposals are kind of scattered over multiple e-mails
in this thread. So I'm sending them again, attached in this mail as
complete patches that apply to current master.

The first patch refactors abort-minibuffers
(and improves minibuffer-quit-recursive-edit's doc string as requested).

The second patch improves documentation of recursive editing.

Best regards.


--=-=-=
Content-Type: text/x-patch
Content-Disposition: inline;
 filename=0001-Refactor-minibuffer-aborting.patch
Content-Transfer-Encoding: quoted-printable

From=20fd5be298c67157822b35cd0231c65691c48dc29e Mon Sep 17 00:00:00 2001
From: =3D?UTF-8?q?Miha=3D20Rihtar=3DC5=3DA1i=3DC4=3D8D?=3D <miha@kamnitnik.=
top>
Date: Sat, 31 Jul 2021 13:44:21 +0200
Subject: [PATCH] Refactor minibuffer aborting

* lisp/minibuffer.el (minibuffer-quit-recursive-edit): New optional
argument to specify how many levels of recursion to quit.

* src/minibuf.c (Fabort_minibuffers): Use
minibuffer-quit-recursive-edit to quit multiple levels of minibuffer
recursion.

* src/eval.c (internal_catch): Remove special handling of 'exit tag.
=2D--
 lisp/minibuffer.el | 20 ++++++++++++--------
 src/eval.c         | 22 ----------------------
 src/lisp.h         |  1 -
 src/minibuf.c      |  9 +++++++--
 4 files changed, 19 insertions(+), 33 deletions(-)

diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 9668e7c732..b5c0054a3c 100644
=2D-- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -2349,14 +2349,18 @@ minibuffer-restore-windows
=20
 (add-hook 'minibuffer-exit-hook 'minibuffer-restore-windows)
=20
=2D(defun minibuffer-quit-recursive-edit ()
=2D  "Quit the command that requested this recursive edit without error.
=2DLike `abort-recursive-edit' without aborting keyboard macro
=2Dexecution."
=2D  ;; See Info node `(elisp)Recursive Editing' for an explanation of
=2D  ;; throwing a function to `exit'.
=2D  (throw 'exit (lambda ()
=2D                 (signal 'minibuffer-quit nil))))
+(defun minibuffer-quit-recursive-edit (&optional levels)
+  "Quit the command that requested this recursive edit or minibuffer input.
+Do so without terminating keyboard macro recording or execution.
+LEVELS specifies the number of nested recursive edits to quit.
+If nil, it defaults to 1."
+  (unless levels
+    (setq levels 1))
+  (if (> levels 1)
+      ;; See Info node `(elisp)Recursive Editing' for an explanation
+      ;; of throwing a function to `exit'.
+      (throw 'exit (lambda () (minibuffer-quit-recursive-edit (1- levels))=
))
+    (throw 'exit (lambda () (signal 'minibuffer-quit nil)))))
=20
 (defun self-insert-and-exit ()
   "Terminate minibuffer input."
diff --git a/src/eval.c b/src/eval.c
index 48104bd0f4..76fe671b6d 100644
=2D-- a/src/eval.c
+++ b/src/eval.c
@@ -1174,14 +1174,6 @@ #define clobbered_eassert(E) verify (sizeof (E) !=3D=
 0)
    FUNC should return a Lisp_Object.
    This is how catches are done from within C code.  */
=20
=2D/* MINIBUFFER_QUIT_LEVEL is to handle quitting from nested minibuffers by
=2D   throwing t to tag `exit'.
=2D   0 means there is no (throw 'exit t) in progress, or it wasn't from
=2D     a minibuffer which isn't the most nested;
=2D   N > 0 means the `throw' was done from the minibuffer at level N which
=2D     wasn't the most nested.  */
=2DEMACS_INT minibuffer_quit_level =3D 0;
=2D
 Lisp_Object
 internal_catch (Lisp_Object tag,
 		Lisp_Object (*func) (Lisp_Object), Lisp_Object arg)
@@ -1189,9 +1181,6 @@ internal_catch (Lisp_Object tag,
   /* This structure is made part of the chain `catchlist'.  */
   struct handler *c =3D push_handler (tag, CATCHER);
=20
=2D  if (EQ (tag, Qexit))
=2D    minibuffer_quit_level =3D 0;
=2D
   /* Call FUNC.  */
   if (! sys_setjmp (c->jmp))
     {
@@ -1205,17 +1194,6 @@ internal_catch (Lisp_Object tag,
       Lisp_Object val =3D handlerlist->val;
       clobbered_eassert (handlerlist =3D=3D c);
       handlerlist =3D handlerlist->next;
=2D      if (EQ (tag, Qexit) && EQ (val, Qt) && minibuffer_quit_level > 0)
=2D	/* If we've thrown t to tag `exit' from within a minibuffer, we
=2D	   exit all minibuffers more deeply nested than the current
=2D	   one.  */
=2D	{
=2D	  if (minibuf_level > minibuffer_quit_level
=2D	      && !NILP (Fminibuffer_innermost_command_loop_p (Qnil)))
=2D            Fthrow (Qexit, Qt);
=2D	  else
=2D	    minibuffer_quit_level =3D 0;
=2D	}
       return val;
     }
 }
diff --git a/src/lisp.h b/src/lisp.h
index 7bfc69b647..4e6298a101 100644
=2D-- a/src/lisp.h
+++ b/src/lisp.h
@@ -4113,7 +4113,6 @@ intern_c_string (const char *str)
 }
=20
 /* Defined in eval.c.  */
=2Dextern EMACS_INT minibuffer_quit_level;
 extern Lisp_Object Vautoload_queue;
 extern Lisp_Object Vrun_hooks;
 extern Lisp_Object Vsignaling_function;
diff --git a/src/minibuf.c b/src/minibuf.c
index 0e7baf30dc..a4219d2a63 100644
=2D-- a/src/minibuf.c
+++ b/src/minibuf.c
@@ -491,8 +491,13 @@ DEFUN ("abort-minibuffers", Fabort_minibuffers, Sabort=
_minibuffers, 0, 0, "",
       array[1] =3D make_fixnum (minibuf_level - minibuf_depth + 1);
       if (!NILP (Fyes_or_no_p (Fformat (2, array))))
 	{
=2D	  minibuffer_quit_level =3D minibuf_depth;
=2D	  Fthrow (Qexit, Qt);
+	  /* Due to the above check, the current minibuffer is in the
+	     most nested command loop, which means that we don't have
+	     to abort any extra non-minibuffer recursive edits.  Thus,
+	     the number of recursive edits we have to abort equals the
+	     number of minibuffers we have to abort.  */
+	  CALLN (Ffuncall, intern ("minibuffer-quit-recursive-edit"),
+		 array[1]);
 	}
     }
   else
=2D-=20
2.33.0


--=-=-=
Content-Type: text/x-patch
Content-Disposition: inline;
 filename=0001-Improve-documentation-of-exiting-recursive-editing.patch
Content-Transfer-Encoding: quoted-printable

From=20387baa2b42e8220b0aac36f6f23ec3547ad0811e Mon Sep 17 00:00:00 2001
From: =3D?UTF-8?q?Miha=3D20Rihtar=3DC5=3DA1i=3DC4=3D8D?=3D <miha@kamnitnik.=
top>
Date: Sun, 1 Aug 2021 02:41:37 +0200
Subject: [PATCH] Improve documentation of exiting recursive editing

* doc/lispref/commands.texi (Recursive Editing): Mention what happens
when throwing a string or any other value to 'exit.
* src/keyboard.c (Frecursive_edit): Document throwing a function to 'exit.
=2D--
 doc/lispref/commands.texi | 22 ++++++++++++----------
 src/keyboard.c            | 18 ++++++++++++++----
 2 files changed, 26 insertions(+), 14 deletions(-)

diff --git a/doc/lispref/commands.texi b/doc/lispref/commands.texi
index ddd74d1245..3425880fec 100644
=2D-- a/doc/lispref/commands.texi
+++ b/doc/lispref/commands.texi
@@ -3585,17 +3585,19 @@ Recursive Editing
 @cindex exit recursive editing
 @cindex aborting
   To invoke a recursive editing level, call the function
=2D@code{recursive-edit}.  This function contains the command loop; it also
=2Dcontains a call to @code{catch} with tag @code{exit}, which makes it
=2Dpossible to exit the recursive editing level by throwing to @code{exit}
=2D(@pxref{Catch and Throw}).  If you throw a @code{nil} value, then
=2D@code{recursive-edit} returns normally to the function that called it.
=2DThe command @kbd{C-M-c} (@code{exit-recursive-edit}) does this.
=2DThrowing a @code{t} value causes @code{recursive-edit} to quit, so that
=2Dcontrol returns to the command loop one level up.  This is called
=2D@dfn{aborting}, and is done by @kbd{C-]} (@code{abort-recursive-edit}).
=2DYou can also throw a function value.  In that case,
+@code{recursive-edit}.  This function contains the command loop; it
+also contains a call to @code{catch} with tag @code{exit}, which makes
+it possible to exit the recursive editing level by throwing to
+@code{exit} (@pxref{Catch and Throw}).  Throwing a @code{t} value
+causes @code{recursive-edit} to quit, so that control returns to the
+command loop one level up.  This is called @dfn{aborting}, and is done
+by @kbd{C-]} (@code{abort-recursive-edit}).  Similarly, you can throw
+a string value to make @code{recursive-edit} signal an error, printing
+this string as the message.  If you throw a function,
 @code{recursive-edit} will call it without arguments before returning.
+Throwing any other value, will make @code{recursive-edit} return
+normally to the function that called it.  The command @kbd{C-M-c}
+(@code{exit-recursive-edit}) does this.
=20
   Most applications should not use recursive editing, except as part of
 using the minibuffer.  Usually it is more convenient for the user if you
diff --git a/src/keyboard.c b/src/keyboard.c
index 63bf29a948..2d97429ade 100644
=2D-- a/src/keyboard.c
+++ b/src/keyboard.c
@@ -753,10 +753,20 @@ DEFUN ("recursive-edit", Frecursive_edit, Srecursive_=
edit, 0, 0, "",
        doc: /* Invoke the editor command loop recursively.
 To get out of the recursive edit, a command can throw to `exit' -- for
 instance (throw \\=3D'exit nil).
=2DIf you throw a value other than t, `recursive-edit' returns normally
=2Dto the function that called it.  Throwing a t value causes
=2D`recursive-edit' to quit, so that control returns to the command loop
=2Done level up.
+
+The following values can be thrown to 'exit:
+
+- t causes `recursive-edit' to quit, so that control returns to the
+  command loop one level up.
+
+- A string causes `recursive-edit' to signal an error, printing this
+  string as the message.
+
+- A function causes `recursive-edit' to call this function without
+  arguments before returning normally.
+
+- Any other value causes `recursive-edit' to return normally to the
+  function that called it.
=20
 This function is called by the editor initialization to begin editing.  */)
   (void)
=2D-=20
2.33.0


--=-=-=--

--==-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJHBAEBCAAxFiEEmxVnesoT5rQXvVXnswkaGpIVmT8FAmFFDPcTHG1paGFAa2Ft
bml0bmlrLnRvcAAKCRCzCRoakhWZP0zxEAC/f7Jaa4qLRqHMTVr1+yV59GPM1mBg
asm0H/1DgPGRofqMX3fsR+m5PrJcF1PkAyx2gAuD1QA6E6T0XFKcz/o8nFKd/mwo
MUAcpIkJbS5IBmdjzP8vhlHVCaPj23C15j7MLWJjCJwcNKZZeTQtNIdtuZuBFqnB
iRZ8s8VugEkn1dxbLd+gcpR8+JAcEt04cCGEtzS86m/K/HL/j/2glp94fZb80Xen
pZkHyN519kXY+q9mhFIUb4fp682PbReWybchjgtZGlbaKsljQw17MCva9f8tUnD3
gSbTOKWrwgNjuk5Mwr+uG5P9vfoaQ76bNKcNgbuw+FI/VXqVcu/lJQkIxwPAYnAe
BF75E7PT8Btlj5rQlEAF8Z16BbFIGYOqHGHz4RDNJwEI0ocDrRrM0oMHi71yCa6I
4pu+iGRbYpOuRdpJhHgg44MQlWXMYu/Ttf82wLxPFSuoC+uG45iEwpmGmaTFa5MB
8lag61nTSt09FEE3oXLQNj685IEktpzZavRej0VAyzqaFWdvJlV7EUDjvwNKtJMg
EoFez0XCmYFP2iGfThHcgX3qoXNffajp9NaWHEQ14r6w/WMeQCShpYpaKi+zBbvS
M0qgRyTGLMS6bLCHC61/pLkVMhCEOoMyUkZm1DnWCRXtoyn0Yc0XqmvHrgoh3tIC
2z9pnZTTtTpH3A==
=Wrzb
-----END PGP SIGNATURE-----
--==-=-=--




Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#49700: 27.2; [PATCH] Refactor minibuffer aborting
Resent-From: Alan Mackenzie <acm@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 19 Sep 2021 19:31:02 +0000
Resent-Message-ID: <handler.49700.B49700.163207983512948 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 49700
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: miha@HIDDEN
Cc: acm@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, 49700 <at> debbugs.gnu.org
Received: via spool by 49700-submit <at> debbugs.gnu.org id=B49700.163207983512948
          (code B ref 49700); Sun, 19 Sep 2021 19:31:02 +0000
Received: (at 49700) by debbugs.gnu.org; 19 Sep 2021 19:30:35 +0000
Received: from localhost ([127.0.0.1]:39994 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1mS2WI-0003Ml-HH
	for submit <at> debbugs.gnu.org; Sun, 19 Sep 2021 15:30:35 -0400
Received: from colin.muc.de ([193.149.48.1]:22622 helo=mail.muc.de)
 by debbugs.gnu.org with smtp (Exim 4.84_2)
 (envelope-from <acm@HIDDEN>) id 1mS2WF-0003MX-9H
 for 49700 <at> debbugs.gnu.org; Sun, 19 Sep 2021 15:30:32 -0400
Received: (qmail 26540 invoked by uid 3782); 19 Sep 2021 19:30:24 -0000
Received: from acm.muc.de (p2e5d5c04.dip0.t-ipconnect.de [46.93.92.4]) (using
 STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP;
 Sun, 19 Sep 2021 21:30:24 +0200
Received: (qmail 17712 invoked by uid 1000); 19 Sep 2021 19:30:24 -0000
Date: Sun, 19 Sep 2021 19:30:24 +0000
Message-ID: <YUeP0KcVjH/te33Y@ACM>
References: <87pmvaar0a.fsf@miha-pc> <YPsnLZa5vmDYIpxX@ACM>
 <87im0qrmxe.fsf@miha-pc> <YQ2XHG6k6olofEb/@ACM>
 <87eeb6b3av.fsf@miha-pc> <87pmt6ho20.fsf@miha-pc>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87pmt6ho20.fsf@miha-pc>
X-Submission-Agent: TMDA/1.3.x (Ph3nix)
From: Alan Mackenzie <acm@HIDDEN>
X-Primary-Address: acm@HIDDEN
X-Spam-Score: 2.0 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  Hello, Miha. Apologies for loosing track of this thread a
 few weeks ago. I spent quite some time trying to find things wrong with your
 latest patch, but couldn't. ;-) So although I haven't fully tested it, I
 would be in favour of merging it to master. 
 Content analysis details:   (2.0 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 SPF_PASS               SPF: sender matches SPF record
 2.0 PDS_OTHER_BAD_TLD      Untrustworthy TLDs
 [URI: kamnitnik.top (top)]
 0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.0 (+)

Hello, Miha.

Apologies for loosing track of this thread a few weeks ago.

I spent quite some time trying to find things wrong with your latest
patch, but couldn't.  ;-)  So although I haven't fully tested it, I would
be in favour of merging it to master.

-- 
Alan Mackenzie (Nuremberg, Germany).


On Fri, Sep 17, 2021 at 23:47:35 +0200, miha@HIDDEN wrote:
> miha--- via "Bug reports for GNU Emacs, the Swiss army knife of text
> editors" <bug-gnu-emacs@HIDDEN> writes:

> > True, my code would indeed be incorrect if the number of minibuffer
> > levels to be aborted weren't to match the number of recursive edits.
> > However, in such cases, my code isn't reached because an error is
> > signaled that the current minibuffer isn't in the innermost command
> > loop.

> > Sorry for not clarifying this earlier. Would it would be enough to
> > include the following comment in the code?:

> > /* Due to the above check, the current minibuffer is in the most nested
> >    command loop, which means that we don't have to abort any extra
> >    non-minibuffer recursive edits.  Thus, the number of recursive edits
> >    we have to abort equals the number of minibuffers we have to abort.
> >    */

> > [...]


> > Perhaps the following adjustment to the doc string could be considered
> > (to be applied on top of the latest patch). It copies the beginning of
> > abort-recursive-edit's doc string and removes the link to it.

> > [...]

> I realized that my proposals are kind of scattered over multiple e-mails
> in this thread. So I'm sending them again, attached in this mail as
> complete patches that apply to current master.

> The first patch refactors abort-minibuffers
> (and improves minibuffer-quit-recursive-edit's doc string as requested).

> The second patch improves documentation of recursive editing.

> Best regards.


> From fd5be298c67157822b35cd0231c65691c48dc29e Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Miha=20Rihtar=C5=A1i=C4=8D?= <miha@HIDDEN>
> Date: Sat, 31 Jul 2021 13:44:21 +0200
> Subject: [PATCH] Refactor minibuffer aborting

> * lisp/minibuffer.el (minibuffer-quit-recursive-edit): New optional
> argument to specify how many levels of recursion to quit.

> * src/minibuf.c (Fabort_minibuffers): Use
> minibuffer-quit-recursive-edit to quit multiple levels of minibuffer
> recursion.

> * src/eval.c (internal_catch): Remove special handling of 'exit tag.
> ---
>  lisp/minibuffer.el | 20 ++++++++++++--------
>  src/eval.c         | 22 ----------------------
>  src/lisp.h         |  1 -
>  src/minibuf.c      |  9 +++++++--
>  4 files changed, 19 insertions(+), 33 deletions(-)

> diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
> index 9668e7c732..b5c0054a3c 100644
> --- a/lisp/minibuffer.el
> +++ b/lisp/minibuffer.el
> @@ -2349,14 +2349,18 @@ minibuffer-restore-windows
>  
>  (add-hook 'minibuffer-exit-hook 'minibuffer-restore-windows)
>  
> -(defun minibuffer-quit-recursive-edit ()
> -  "Quit the command that requested this recursive edit without error.
> -Like `abort-recursive-edit' without aborting keyboard macro
> -execution."
> -  ;; See Info node `(elisp)Recursive Editing' for an explanation of
> -  ;; throwing a function to `exit'.
> -  (throw 'exit (lambda ()
> -                 (signal 'minibuffer-quit nil))))
> +(defun minibuffer-quit-recursive-edit (&optional levels)
> +  "Quit the command that requested this recursive edit or minibuffer input.
> +Do so without terminating keyboard macro recording or execution.
> +LEVELS specifies the number of nested recursive edits to quit.
> +If nil, it defaults to 1."
> +  (unless levels
> +    (setq levels 1))
> +  (if (> levels 1)
> +      ;; See Info node `(elisp)Recursive Editing' for an explanation
> +      ;; of throwing a function to `exit'.
> +      (throw 'exit (lambda () (minibuffer-quit-recursive-edit (1- levels))))
> +    (throw 'exit (lambda () (signal 'minibuffer-quit nil)))))
>  
>  (defun self-insert-and-exit ()
>    "Terminate minibuffer input."
> diff --git a/src/eval.c b/src/eval.c
> index 48104bd0f4..76fe671b6d 100644
> --- a/src/eval.c
> +++ b/src/eval.c
> @@ -1174,14 +1174,6 @@ #define clobbered_eassert(E) verify (sizeof (E) != 0)
>     FUNC should return a Lisp_Object.
>     This is how catches are done from within C code.  */
>  
> -/* MINIBUFFER_QUIT_LEVEL is to handle quitting from nested minibuffers by
> -   throwing t to tag `exit'.
> -   0 means there is no (throw 'exit t) in progress, or it wasn't from
> -     a minibuffer which isn't the most nested;
> -   N > 0 means the `throw' was done from the minibuffer at level N which
> -     wasn't the most nested.  */
> -EMACS_INT minibuffer_quit_level = 0;
> -
>  Lisp_Object
>  internal_catch (Lisp_Object tag,
>  		Lisp_Object (*func) (Lisp_Object), Lisp_Object arg)
> @@ -1189,9 +1181,6 @@ internal_catch (Lisp_Object tag,
>    /* This structure is made part of the chain `catchlist'.  */
>    struct handler *c = push_handler (tag, CATCHER);
>  
> -  if (EQ (tag, Qexit))
> -    minibuffer_quit_level = 0;
> -
>    /* Call FUNC.  */
>    if (! sys_setjmp (c->jmp))
>      {
> @@ -1205,17 +1194,6 @@ internal_catch (Lisp_Object tag,
>        Lisp_Object val = handlerlist->val;
>        clobbered_eassert (handlerlist == c);
>        handlerlist = handlerlist->next;
> -      if (EQ (tag, Qexit) && EQ (val, Qt) && minibuffer_quit_level > 0)
> -	/* If we've thrown t to tag `exit' from within a minibuffer, we
> -	   exit all minibuffers more deeply nested than the current
> -	   one.  */
> -	{
> -	  if (minibuf_level > minibuffer_quit_level
> -	      && !NILP (Fminibuffer_innermost_command_loop_p (Qnil)))
> -            Fthrow (Qexit, Qt);
> -	  else
> -	    minibuffer_quit_level = 0;
> -	}
>        return val;
>      }
>  }
> diff --git a/src/lisp.h b/src/lisp.h
> index 7bfc69b647..4e6298a101 100644
> --- a/src/lisp.h
> +++ b/src/lisp.h
> @@ -4113,7 +4113,6 @@ intern_c_string (const char *str)
>  }
>  
>  /* Defined in eval.c.  */
> -extern EMACS_INT minibuffer_quit_level;
>  extern Lisp_Object Vautoload_queue;
>  extern Lisp_Object Vrun_hooks;
>  extern Lisp_Object Vsignaling_function;
> diff --git a/src/minibuf.c b/src/minibuf.c
> index 0e7baf30dc..a4219d2a63 100644
> --- a/src/minibuf.c
> +++ b/src/minibuf.c
> @@ -491,8 +491,13 @@ DEFUN ("abort-minibuffers", Fabort_minibuffers, Sabort_minibuffers, 0, 0, "",
>        array[1] = make_fixnum (minibuf_level - minibuf_depth + 1);
>        if (!NILP (Fyes_or_no_p (Fformat (2, array))))
>  	{
> -	  minibuffer_quit_level = minibuf_depth;
> -	  Fthrow (Qexit, Qt);
> +	  /* Due to the above check, the current minibuffer is in the
> +	     most nested command loop, which means that we don't have
> +	     to abort any extra non-minibuffer recursive edits.  Thus,
> +	     the number of recursive edits we have to abort equals the
> +	     number of minibuffers we have to abort.  */
> +	  CALLN (Ffuncall, intern ("minibuffer-quit-recursive-edit"),
> +		 array[1]);
>  	}
>      }
>    else
> -- 
> 2.33.0


> From 387baa2b42e8220b0aac36f6f23ec3547ad0811e Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Miha=20Rihtar=C5=A1i=C4=8D?= <miha@HIDDEN>
> Date: Sun, 1 Aug 2021 02:41:37 +0200
> Subject: [PATCH] Improve documentation of exiting recursive editing

> * doc/lispref/commands.texi (Recursive Editing): Mention what happens
> when throwing a string or any other value to 'exit.
> * src/keyboard.c (Frecursive_edit): Document throwing a function to 'exit.
> ---
>  doc/lispref/commands.texi | 22 ++++++++++++----------
>  src/keyboard.c            | 18 ++++++++++++++----
>  2 files changed, 26 insertions(+), 14 deletions(-)

> diff --git a/doc/lispref/commands.texi b/doc/lispref/commands.texi
> index ddd74d1245..3425880fec 100644
> --- a/doc/lispref/commands.texi
> +++ b/doc/lispref/commands.texi
> @@ -3585,17 +3585,19 @@ Recursive Editing
>  @cindex exit recursive editing
>  @cindex aborting
>    To invoke a recursive editing level, call the function
> -@code{recursive-edit}.  This function contains the command loop; it also
> -contains a call to @code{catch} with tag @code{exit}, which makes it
> -possible to exit the recursive editing level by throwing to @code{exit}
> -(@pxref{Catch and Throw}).  If you throw a @code{nil} value, then
> -@code{recursive-edit} returns normally to the function that called it.
> -The command @kbd{C-M-c} (@code{exit-recursive-edit}) does this.
> -Throwing a @code{t} value causes @code{recursive-edit} to quit, so that
> -control returns to the command loop one level up.  This is called
> -@dfn{aborting}, and is done by @kbd{C-]} (@code{abort-recursive-edit}).
> -You can also throw a function value.  In that case,
> +@code{recursive-edit}.  This function contains the command loop; it
> +also contains a call to @code{catch} with tag @code{exit}, which makes
> +it possible to exit the recursive editing level by throwing to
> +@code{exit} (@pxref{Catch and Throw}).  Throwing a @code{t} value
> +causes @code{recursive-edit} to quit, so that control returns to the
> +command loop one level up.  This is called @dfn{aborting}, and is done
> +by @kbd{C-]} (@code{abort-recursive-edit}).  Similarly, you can throw
> +a string value to make @code{recursive-edit} signal an error, printing
> +this string as the message.  If you throw a function,
>  @code{recursive-edit} will call it without arguments before returning.
> +Throwing any other value, will make @code{recursive-edit} return
> +normally to the function that called it.  The command @kbd{C-M-c}
> +(@code{exit-recursive-edit}) does this.
>  
>    Most applications should not use recursive editing, except as part of
>  using the minibuffer.  Usually it is more convenient for the user if you
> diff --git a/src/keyboard.c b/src/keyboard.c
> index 63bf29a948..2d97429ade 100644
> --- a/src/keyboard.c
> +++ b/src/keyboard.c
> @@ -753,10 +753,20 @@ DEFUN ("recursive-edit", Frecursive_edit, Srecursive_edit, 0, 0, "",
>         doc: /* Invoke the editor command loop recursively.
>  To get out of the recursive edit, a command can throw to `exit' -- for
>  instance (throw \\='exit nil).
> -If you throw a value other than t, `recursive-edit' returns normally
> -to the function that called it.  Throwing a t value causes
> -`recursive-edit' to quit, so that control returns to the command loop
> -one level up.
> +
> +The following values can be thrown to 'exit:
> +
> +- t causes `recursive-edit' to quit, so that control returns to the
> +  command loop one level up.
> +
> +- A string causes `recursive-edit' to signal an error, printing this
> +  string as the message.
> +
> +- A function causes `recursive-edit' to call this function without
> +  arguments before returning normally.
> +
> +- Any other value causes `recursive-edit' to return normally to the
> +  function that called it.
>  
>  This function is called by the editor initialization to begin editing.  */)
>    (void)
> -- 
> 2.33.0







Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#49700: 27.2; [PATCH] Refactor minibuffer aborting
Resent-From: Lars Ingebrigtsen <larsi@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 20 Sep 2021 06:02:02 +0000
Resent-Message-ID: <handler.49700.B49700.163211770615013 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 49700
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Alan Mackenzie <acm@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, miha@HIDDEN, 49700 <at> debbugs.gnu.org
Received: via spool by 49700-submit <at> debbugs.gnu.org id=B49700.163211770615013
          (code B ref 49700); Mon, 20 Sep 2021 06:02:02 +0000
Received: (at 49700) by debbugs.gnu.org; 20 Sep 2021 06:01:46 +0000
Received: from localhost ([127.0.0.1]:40676 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1mSCN8-0003tm-0h
	for submit <at> debbugs.gnu.org; Mon, 20 Sep 2021 02:01:46 -0400
Received: from quimby.gnus.org ([95.216.78.240]:57658)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <larsi@HIDDEN>) id 1mSCN5-0003nw-A0
 for 49700 <at> debbugs.gnu.org; Mon, 20 Sep 2021 02:01:44 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org;
 s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:
 References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=dMmfCh+Qj4szo0UmpBfyUdN9bXqnXV2I5uGeJxl/NGk=; b=eV7eHJhXrKhUQ9GGaBWyusBZ2t
 K23YJpFdmilTXd/TxS5C+lAv/GLixB4vGWPcf7dJuCIeYRN+hyoW1j3FvlfFNZPG7K+CzlF4wKHXJ
 CPU4yXZ5gkkdigF0q4N8Fsmma2TCW0MTQ4kddwsfrgNbfHDgXcieIjo4XT+V6BWxz134=;
Received: from [84.212.220.105] (helo=elva)
 by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.92) (envelope-from <larsi@HIDDEN>)
 id 1mSCMu-0005yI-Ud; Mon, 20 Sep 2021 08:01:35 +0200
From: Lars Ingebrigtsen <larsi@HIDDEN>
References: <87pmvaar0a.fsf@miha-pc> <YPsnLZa5vmDYIpxX@ACM>
 <87im0qrmxe.fsf@miha-pc> <YQ2XHG6k6olofEb/@ACM>
 <87eeb6b3av.fsf@miha-pc> <87pmt6ho20.fsf@miha-pc>
 <YUeP0KcVjH/te33Y@ACM>
Date: Mon, 20 Sep 2021 08:01:32 +0200
In-Reply-To: <YUeP0KcVjH/te33Y@ACM> (Alan Mackenzie's message of "Sun, 19 Sep
 2021 19:30:24 +0000")
Message-ID: <87fstzkcoz.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 @@CONTACT_ADDRESS@@ for details.
 Content preview: Alan Mackenzie <acm@HIDDEN> writes: > Apologies for loosing
 track of this thread a few weeks ago. > > I spent quite some time trying
 to find things wrong with your latest > patch, but couldn't. ;-) So although
 I haven't fully tested it, [...] 
 Content analysis details:   (-2.9 points, 5.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -1.0 ALL_TRUSTED            Passed through trusted hosts only via SMTP
 -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
 [score: 0.0000]
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Alan Mackenzie <acm@HIDDEN> writes:

> Apologies for loosing track of this thread a few weeks ago.
>
> I spent quite some time trying to find things wrong with your latest
> patch, but couldn't.  ;-)  So although I haven't fully tested it, I would
> be in favour of merging it to master.

Thanks for doing the code review.  I've applied the patch and tested it
here, and it doesn't seem to lead to any regressions here, so I went
ahead and pushed the two patches to Emacs 28.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Message received at control <at> debbugs.gnu.org:


Received: (at control) by debbugs.gnu.org; 20 Sep 2021 06:01:50 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Sep 20 02:01:50 2021
Received: from localhost ([127.0.0.1]:40679 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1mSCNC-0003xX-CX
	for submit <at> debbugs.gnu.org; Mon, 20 Sep 2021 02:01:50 -0400
Received: from quimby.gnus.org ([95.216.78.240]:57672)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <larsi@HIDDEN>) id 1mSCNA-0003rx-QQ
 for control <at> debbugs.gnu.org; Mon, 20 Sep 2021 02:01:49 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org;
 s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc:
 MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID:
 Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
 :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=0O8ZEhFM5B0v6bFO4CE59stRNp0lUVFCQssuyZARLws=; b=dgEDnefiT6ixeaV5NT64wYJtQ5
 3lF+xYYTQFV7DSCjjpgATgfJfC0QrYuqP5YAeKD5R+rHw9U0Qzi/XHLMaJSln9Jsta1EdD+fuMop8
 b31/eCGZ1hrbXJs7vv8Vhn9Rm4kz5ml7UQ9mw3DTpeb9BZaEtPzHbuCinGz9fFobL62s=;
Received: from [84.212.220.105] (helo=elva)
 by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.92) (envelope-from <larsi@HIDDEN>) id 1mSCN2-0005yU-SI
 for control <at> debbugs.gnu.org; Mon, 20 Sep 2021 08:01:43 +0200
Date: Mon, 20 Sep 2021 08:01:38 +0200
Message-Id: <87ee9jkcot.fsf@HIDDEN>
To: control <at> debbugs.gnu.org
From: Lars Ingebrigtsen <larsi@HIDDEN>
Subject: control message for bug #49700
X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 @@CONTACT_ADDRESS@@ for details.
 Content preview:  close 49700 28.1 quit 
 Content analysis details:   (-2.9 points, 5.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -1.0 ALL_TRUSTED            Passed through trusted hosts only via SMTP
 -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
 [score: 0.0000]
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: control
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

close 49700 28.1
quit






Last modified: Mon, 20 Sep 2021 06:15:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.