Received: (at 69056) by debbugs.gnu.org; 15 Feb 2024 16:17:51 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Feb 15 11:17:51 2024
Received: from localhost ([127.0.0.1]:56822 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1raeQo-0002Wh-KH
for submit <at> debbugs.gnu.org; Thu, 15 Feb 2024 11:17:51 -0500
Received: from mail.eshelyaron.com ([107.175.124.16]:52298 helo=eshelyaron.com)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <me@HIDDEN>) id 1raeQm-0002WY-HW
for 69056 <at> debbugs.gnu.org; Thu, 15 Feb 2024 11:17:49 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com;
s=mail; t=1708013849;
bh=T2xn+9thfc3n57cIwhDO+IvKwN0FdbpPKjJQo+4uOdg=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=bceCt8U3keQG8wltZezDgSLtiW8c7Yjti8Nc63OMlwZ+dB/7koNgxCG84hARFUeUV
PsHsze8+AxBijxF/pjtmoRJPlZpVabkkvI7WmfyDGH87BTo535nqXBavRoNFO1BILj
PkzFWM5ZHLtP1QG2Vjly2ZYqoVsD7p9vyJipVUYCuEhDLy8md0A5j+inBqjUFQFQr7
tXbb9aY+zNz63Rl42WfyCy6XVN+AGKkp4fdEoLbSl5tRrvGk8VvL5CKtpjPpU20Cd7
ltblcqPHBlHKHl0g0SrZ5dvszWJLRVkRq/KJu3doD9LgCvZLxj/nT4ghze5gdlmYis
kw0HR923Xejfg==
From: Eshel Yaron <me@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
Subject: Re: bug#69056: 30.0.50; history-add-new-input and recursive
minibuffers
In-Reply-To: <jwvplwxah1w.fsf-monnier+emacs@HIDDEN> (Stefan Monnier's message
of "Thu, 15 Feb 2024 10:24:45 -0500")
References: <m11q9jngho.fsf@HIDDEN>
<jwvplwxah1w.fsf-monnier+emacs@HIDDEN>
X-Hashcash: 1:20:240215:monnier@HIDDEN::/rjAqgxFdq3PtMPI:uNo
X-Hashcash: 1:20:240215:69056 <at> debbugs.gnu.org::DkJa9f3AjDEDikY1:3cmx
Date: Thu, 15 Feb 2024 17:17:26 +0100
Message-ID: <m1v86pln1l.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Spam-Score: -1.9 (-)
X-Debbugs-Envelope-To: 69056
Cc: 69056 <at> debbugs.gnu.org
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.9 (--)
--=-=-=
Content-Type: text/plain
Stefan Monnier <monnier@HIDDEN> writes:
>> 1. emacs -Q
>> 2. (setq enable-recursive-minibuffers t)
>> 3. M-y
>> 4. In the minibuffer (with the prompt "Yank from kill-ring: "),
>> type M-x calendar RET (or any other command).
>> 5. M-x M-p
>> Expected: "calendar" is inserted in the minibuffer.
>> Observed: error saying "Beginning of history; no preceding item".
>>
>> The problem is that the minibuffer history of M-x isn't recorded when
>> you invoke M-x from within the minibuffer of read-from-kill-ring (M-y).
>> The reason is that read-from-kill-ring let binds history-add-new-input,
>> and that affects all recursive minibuffers as well, so no minibuffer
>> history is recorded until you exit the first (non-recursive) minibuffer.
>
> I suspect this can bite in more cases, including cases which don't
> involve setting `enable-recursive-minibuffers` to t.
> We should probably change the way `history-add-new-input` works so it's
> attached to a particular minibuffer rather than being dynbound.
Thanks, that's what I thought too. Here's an attempt do just that:
--=-=-=
Content-Type: text/x-patch; charset=utf-8
Content-Disposition: attachment;
filename=0001-Use-buffer-local-value-of-history-add-new-input-in-m.patch
Content-Transfer-Encoding: quoted-printable
From 35c7cf51102b5625a46bdb0dc5f7f2299659f699 Mon Sep 17 00:00:00 2001
From: Eshel Yaron <me@HIDDEN>
Date: Sun, 11 Feb 2024 16:18:48 +0100
Subject: [PATCH] Use buffer local value of 'history-add-new-input' in
minibuffer
Avoid let-binding 'history-add-new-input', since that affects all nested
recursive minibuffers, and instead use a buffer-local setting in the
appropriate minibuffer.
* src/minibuf.c (read_minibuf): Use 'history-add-new-input' local value.
* lisp/isearch.el (isearch-edit-string)
* lisp/replace.el (query-replace-read-from)
(query-replace-read-to, read-regexp)
* lisp/simple.el (read-from-kill-ring): Set 'history-add-new-input'
locally in the minibuffer, instead of let-binding it.
* doc/lispref/minibuf.texi (Minibuffer History): Update.
---
doc/lispref/minibuf.texi | 6 +++---
lisp/isearch.el | 12 +++++++-----
lisp/replace.el | 36 +++++++++++++++++++-----------------
lisp/simple.el | 4 ++--
src/minibuf.c | 7 ++++++-
5 files changed, 37 insertions(+), 28 deletions(-)
diff --git a/doc/lispref/minibuf.texi b/doc/lispref/minibuf.texi
index aa27de72ba0..2e8b21d7040 100644
--- a/doc/lispref/minibuf.texi
+++ b/doc/lispref/minibuf.texi
@@ -700,9 +700,9 @@ Minibuffer History
@end defun
=20
@defvar history-add-new-input
-If the value of this variable is @code{nil}, standard functions that
-read from the minibuffer don't add new elements to the history list.
-This lets Lisp programs explicitly manage input history by using
+If the value of this variable is @code{nil} in a minibuffer, Emacs
+doesn't add new elements to the history list of that minibuffer. This
+lets Lisp programs explicitly manage input history by using
@code{add-to-history}. The default value is @code{t}.
@end defvar
=20
diff --git a/lisp/isearch.el b/lisp/isearch.el
index a139a6fb84e..814ab919d5e 100644
--- a/lisp/isearch.el
+++ b/lisp/isearch.el
@@ -1844,10 +1844,6 @@ isearch-edit-string
(interactive)
(with-isearch-suspended
(let* ((message-log-max nil)
- ;; Don't add a new search string to the search ring here
- ;; in `read-from-minibuffer'. It should be added only
- ;; by `isearch-update-ring' called from `isearch-done'.
- (history-add-new-input nil)
;; Binding minibuffer-history-symbol to nil is a work-around
;; for some incompatibility with gmhist.
(minibuffer-history-symbol)
@@ -1855,7 +1851,13 @@ isearch-edit-string
(minibuffer-allow-text-properties t))
(setq isearch-new-string
(minibuffer-with-setup-hook
- (minibuffer-lazy-highlight-setup)
+ (let ((setup (minibuffer-lazy-highlight-setup)))
+ (lambda ()
+ ;; Don't add a new search string to the search ring here
+ ;; in `read-from-minibuffer'. It should be added only
+ ;; by `isearch-update-ring' called from `isearch-done'.
+ (setq-local history-add-new-input nil)
+ (funcall setup)))
(read-from-minibuffer
(isearch-message-prefix nil isearch-nonincremental)
(cons isearch-string (1+ (or (isearch-fail-pos)
diff --git a/lisp/replace.el b/lisp/replace.el
index fa460a16063..61a1cc7714c 100644
--- a/lisp/replace.el
+++ b/lisp/replace.el
@@ -205,8 +205,7 @@ query-replace-read-from
Prompt with PROMPT. REGEXP-FLAG non-nil means the response should be a re=
gexp.
The return value can also be a pair (FROM . TO) indicating that the user
wants to replace FROM with TO."
- (let* ((history-add-new-input nil)
- (separator-string
+ (let* ((separator-string
(when query-replace-from-to-separator
;; Check if the first non-whitespace char is displayable
(if (char-displayable-p
@@ -254,7 +253,8 @@ query-replace-read-from
(lambda ()
(setq-local text-property-default-nonsticky
(append '((separator . t) (face . t))
- text-property-default-nonsticky)))
+ text-property-default-nonsticky)
+ history-add-new-input nil))
(if regexp-flag
(read-regexp
(if query-replace-read-from-regexp-default
@@ -342,11 +342,13 @@ query-replace-read-to
should a regexp."
(query-replace-compile-replacement
(save-excursion
- (let* ((history-add-new-input nil)
- (to (read-from-minibuffer
- (format "%s %s with: " prompt (query-replace-descr from))
- nil nil nil
- query-replace-to-history-variable from t)))
+ (let* ((to
+ (minibuffer-with-setup-hook
+ (lambda () (setq-local history-add-new-input nil))
+ (read-from-minibuffer
+ (format "%s %s with: " prompt (query-replace-descr from))
+ nil nil nil
+ query-replace-to-history-variable from t))))
(add-to-history query-replace-to-history-variable to nil t)
(add-to-history 'query-replace-defaults (cons from to) nil t)
to))
@@ -903,18 +905,18 @@ read-regexp
(suggestions (if (listp defaults) defaults (list defaults)))
(suggestions (append suggestions (read-regexp-suggestions)))
(suggestions (delete-dups (delq nil (delete "" suggestions))))
- ;; Do not automatically add default to the history for empty input.
- (history-add-new-input nil)
;; `read-regexp--case-fold' dynamically bound and may be
;; altered by `M-c'.
(read-regexp--case-fold case-fold-search)
- (input (read-from-minibuffer
- (if (string-match-p ":[ \t]*\\'" prompt)
- prompt
- (format-prompt prompt (and (length> default 0)
- (query-replace-descr default=
))))
- nil read-regexp-map
- nil (or history 'regexp-history) suggestions t))
+ (input (minibuffer-with-setup-hook
+ (lambda () (setq-local history-add-new-input nil))
+ (read-from-minibuffer
+ (if (string-match-p ":[ \t]*\\'" prompt)
+ prompt
+ (format-prompt prompt (and (length> default 0)
+ (query-replace-descr defau=
lt))))
+ nil read-regexp-map
+ nil (or history 'regexp-history) suggestions t)))
(result (if (equal input "")
;; Return the default value when the user enters
;; empty input.
diff --git a/lisp/simple.el b/lisp/simple.el
index 9a33049f4ca..c5e7f24961c 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -6405,8 +6405,7 @@ read-from-kill-ring
PROMPT is a string to prompt with."
;; `current-kill' updates `kill-ring' with a possible interprogram-paste
(current-kill 0)
- (let* ((history-add-new-input nil)
- (history-pos (when yank-from-kill-ring-rotate
+ (let* ((history-pos (when yank-from-kill-ring-rotate
(- (length kill-ring)
(length kill-ring-yank-pointer))))
(ellipsis (if (char-displayable-p ?=E2=80=A6) "=E2=80=A6" "..."))
@@ -6441,6 +6440,7 @@ read-from-kill-ring
read-from-kill-ring-history)))
(minibuffer-with-setup-hook
(lambda ()
+ (setq-local history-add-new-input nil)
;; Allow =E2=80=98SPC=E2=80=99 to be self-inserting
(use-local-map
(let ((map (make-sparse-keymap)))
diff --git a/src/minibuf.c b/src/minibuf.c
index 7c0c9799a60..b6126fe5c87 100644
--- a/src/minibuf.c
+++ b/src/minibuf.c
@@ -585,6 +585,7 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lis=
p_Object prompt,
/* String to add to the history. */
Lisp_Object histstring;
Lisp_Object histval;
+ bool nohist =3D false;
=20
Lisp_Object empty_minibuf;
=20
@@ -902,6 +903,9 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lis=
p_Object prompt,
/* Don't allow the user to undo past this point. */
bset_undo_list (current_buffer, Qnil);
=20
+ /* Cache the buffer-local value. */
+ nohist =3D NILP (find_symbol_value (Qhistory_add_new_input));
+
recursive_edit_1 ();
=20
/* If cursor is on the minibuffer line,
@@ -965,7 +969,7 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lis=
p_Object prompt,
/* Add the value to the appropriate history list, if any. This is
done after the previous buffer has been made current again, in
case the history variable is buffer-local. */
- if (! (NILP (Vhistory_add_new_input) || NILP (histstring)))
+ if (! (nohist || NILP (histstring)))
call2 (Qadd_to_history, histvar, histstring);
=20
/* If Lisp form desired instead of string, parse it. */
@@ -2311,6 +2315,7 @@ syms_of_minibuf (void)
Fset (Qcustom_variable_history, Qnil);
=20
DEFSYM (Qminibuffer_history, "minibuffer-history");
+ DEFSYM (Qhistory_add_new_input, "history-add-new-input");
DEFSYM (Qbuffer_name_history, "buffer-name-history");
Fset (Qbuffer_name_history, Qnil);
=20
--=20
2.42.0
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#69056; Package emacs.
Full text available.
Received: (at 69056) by debbugs.gnu.org; 15 Feb 2024 15:25:11 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Feb 15 10:25:11 2024
Received: from localhost ([127.0.0.1]:56764 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1radbq-00014g-MJ
for submit <at> debbugs.gnu.org; Thu, 15 Feb 2024 10:25:11 -0500
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:54006)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1radbo-00014T-Nr
for 69056 <at> debbugs.gnu.org; Thu, 15 Feb 2024 10:25:09 -0500
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id A06A480577;
Thu, 15 Feb 2024 10:24:44 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1708010683;
bh=RU8z6t/Ra8H6lAplm/q7IzoKPLEpA1sPIX0SpRWjUPg=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=R3LCYKvVj9uXQWwAmRk0M4One6YbJX70YTqtJ++ObijKJPEPiZEoAt+T+QVEPbYP+
uI/nYNRsRAk/Fs+Qzjhy5ofyfMaMrq1fh5WDpKBLez72rk/9hqH4d1hwhxVE9U1VXF
JlxZxB0+cBKPvOrErI6s3mbm44K4Zf4w8F2Rlg8pNDSbzIOlAFyCWAVldMiwVIoH9f
LBIEC/7D8AARwRABadbhz82AyI7d6/8x1tdk+iRAL9UKT3aGU/qO6zlB82XnRC3wC0
707bIhBn45vTP24K8+wX4kA5DQkYXVBggZAp2cHM5o/Qo+E7wCUwaRUDWvf0RVoKwR
PtP3G1SOayUhg==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id A133A80348;
Thu, 15 Feb 2024 10:24:43 -0500 (EST)
Received: from alfajor (unknown [23.233.149.155])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 8822B120223;
Thu, 15 Feb 2024 10:24:43 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
To: Eshel Yaron <me@HIDDEN>
Subject: Re: bug#69056: 30.0.50; history-add-new-input and recursive
minibuffers
In-Reply-To: <m11q9jngho.fsf@HIDDEN> (Eshel Yaron's message of "Sun,
11 Feb 2024 16:54:43 +0100")
Message-ID: <jwvplwxah1w.fsf-monnier+emacs@HIDDEN>
References: <m11q9jngho.fsf@HIDDEN>
Date: Thu, 15 Feb 2024 10:24:45 -0500
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL 0.044 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain T_SCC_BODY_TEXT_LINE -0.01 -
X-SPAM-LEVEL:
X-Spam-Score: -4.2 (----)
X-Debbugs-Envelope-To: 69056
Cc: 69056 <at> debbugs.gnu.org
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: -5.2 (-----)
> 1. emacs -Q
> 2. (setq enable-recursive-minibuffers t)
> 3. M-y
> 4. In the minibuffer (with the prompt "Yank from kill-ring: "),
> type M-x calendar RET (or any other command).
> 5. M-x M-p
> Expected: "calendar" is inserted in the minibuffer.
> Observed: error saying "Beginning of history; no preceding item".
>
> The problem is that the minibuffer history of M-x isn't recorded when
> you invoke M-x from within the minibuffer of read-from-kill-ring (M-y).
> The reason is that read-from-kill-ring let binds history-add-new-input,
> and that affects all recursive minibuffers as well, so no minibuffer
> history is recorded until you exit the first (non-recursive) minibuffer.
I suspect this can bite in more cases, including cases which don't
involve setting `enable-recursive-minibuffers` to t.
We should probably change the way `history-add-new-input` works so it's
attached to a particular minibuffer rather than being dynbound.
Stefan
bug-gnu-emacs@HIDDEN:bug#69056; Package emacs.
Full text available.Received: (at 69056) by debbugs.gnu.org; 15 Feb 2024 08:19:50 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Feb 15 03:19:50 2024 Received: from localhost ([127.0.0.1]:53934 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1raWyE-0000Ad-BW for submit <at> debbugs.gnu.org; Thu, 15 Feb 2024 03:19:50 -0500 Received: from eggs.gnu.org ([209.51.188.92]:42730) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1raWyC-0000AQ-7C for 69056 <at> debbugs.gnu.org; Thu, 15 Feb 2024 03:19:49 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1raWxn-0002NG-W3; Thu, 15 Feb 2024 03:19:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=cheBVPsUJCxQMPvhBqioKNN1dSS8RMxcpsyC5Ak66cc=; b=ZIKn23YXsn5D Oy+9MMbOBvmLV5XqaRsWenQDLyYNoTFHC6ht2Rl0j3CPNUOBgX4bZFhJj/FLsk7TL00QjK90RQHcr 1/qOGY2laixr4FW0ji06SFAFoMfCBzCyuUUrFxln1QvP8Vmmy3mghTKid5PtpnCRew6SYIKjrJ6yx vgM7JLXX7r2Am3hvU+lbv6eJisU5PvhHPxdnu9EjYhJT8ldxik5MLTKJm8Rng6L9/8rSDgEucN84c WLa/X2rp/qouHeIP1psGgn1aE+0KvN6FIJXYSH+FzjSK7IpOCWMpCwLc96CGHWzvY/2nbmZtL1xGN tccG9z5Zy/E+0NtXTN4AlA==; Date: Thu, 15 Feb 2024 10:19:18 +0200 Message-Id: <86sf1uw35l.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Kangas <stefankangas@HIDDEN>, Stefan Monnier <monnier@HIDDEN> In-Reply-To: <86frxysxeq.fsf@HIDDEN> (message from Eli Zaretskii on Sun, 11 Feb 2024 19:50:21 +0200) Subject: Re: bug#69056: 30.0.50; history-add-new-input and recursive minibuffers References: <m11q9jngho.fsf@HIDDEN> <86il2vrlri.fsf@HIDDEN> <m1frxy3nja.fsf@HIDDEN> <86frxysxeq.fsf@HIDDEN> X-Spam-Score: -4.2 (----) X-Debbugs-Envelope-To: 69056 Cc: 69056 <at> debbugs.gnu.org, me@HIDDEN 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: -5.2 (-----) > Cc: 69056 <at> debbugs.gnu.org > Date: Sun, 11 Feb 2024 19:50:21 +0200 > From: Eli Zaretskii <eliz@HIDDEN> > > > From: Eshel Yaron <me@HIDDEN> > > Cc: 69056 <at> debbugs.gnu.org > > Date: Sun, 11 Feb 2024 18:42:49 +0100 > > > > Eli Zaretskii <eliz@HIDDEN> writes: > > > > > I'm not sure we should be interested in fixing this. Recursive > > > minibuffers are not supposed to start a completely new command loop > > > unaffected by whatever was before it, so we shouldn't try. > > > > I see that, but the problem, IMO, is that there's nothing telling you > > that you're in this state of not recording minibuffer history. You > > likely won't know that you're using a command that let-binds > > history-add-new-input when you enter a recursive minibuffer, and losing > > all minibuffer history from commands you invoked in the recursive edit > > may come as an unpleasant surprise. > > We should probably document this caveat. enable-recursive-minibuffers > is an advanced feature, not recommended to newbies. Stefan & Stefan, any comments or suggestions, beyond documenting this caveat?
bug-gnu-emacs@HIDDEN:bug#69056; Package emacs.
Full text available.Received: (at 69056) by debbugs.gnu.org; 11 Feb 2024 18:02:44 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Feb 11 13:02:43 2024 Received: from localhost ([127.0.0.1]:36066 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rZEA7-0002GL-Gt for submit <at> debbugs.gnu.org; Sun, 11 Feb 2024 13:02:43 -0500 Received: from mail.eshelyaron.com ([107.175.124.16]:59668 helo=eshelyaron.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <me@HIDDEN>) id 1rZEA5-0002GD-2V for 69056 <at> debbugs.gnu.org; Sun, 11 Feb 2024 13:02:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com; s=mail; t=1707673371; bh=p3Rn0+Xu9RH1of2fAEMWHaPTNyWOhVU6XlX6+jVkGTA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=vhzhEOZAgHp1ceYAAXzMR0dpbpdGY8pzQXXR79K+3LGJ3cVhaA9dLfpqGkQvKopZp BzDhR9WxcyCPqCXR29GlcN9QMfjSPaV4h2HiDZEAKKpwHKcwDHzWi/w30zbxaRFkyw R+OJumii1hbqueq5RU7VdIbNlAq8cXHcYAfjoZSBJiljX20j45e78DdnBFtx2iK263 DHD3y+bMB1n/YCWuOZxpy4iuExmV1A9l0lNPuGfSP+L2uq6mE5T76/BayPOsQRsY6U 4NdRv473LparQfRN6tdxQvPpHH5ZfXsdGYetnjgn/kdurukFVBNAYYq1IQjHNoCwYh dHqFSoY+3ouAA== From: Eshel Yaron <me@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#69056: 30.0.50; history-add-new-input and recursive minibuffers In-Reply-To: <86il2vrlri.fsf@HIDDEN> (Eli Zaretskii's message of "Sun, 11 Feb 2024 18:47:13 +0200") References: <m11q9jngho.fsf@HIDDEN> <86il2vrlri.fsf@HIDDEN> Date: Sun, 11 Feb 2024 18:42:49 +0100 Message-ID: <m1frxy3nja.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 69056 Cc: 69056 <at> debbugs.gnu.org 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 (-) Eli Zaretskii <eliz@HIDDEN> writes: >> Date: Sun, 11 Feb 2024 16:54:43 +0100 >> From: Eshel Yaron via "Bug reports for GNU Emacs, >> the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN> >> >> >> 1. emacs -Q >> 2. (setq enable-recursive-minibuffers t) >> 3. M-y >> 4. In the minibuffer (with the prompt "Yank from kill-ring: "), >> type M-x calendar RET (or any other command). >> 5. M-x M-p >> Expected: "calendar" is inserted in the minibuffer. >> Observed: error saying "Beginning of history; no preceding item". >> >> The problem is that the minibuffer history of M-x isn't recorded when >> you invoke M-x from within the minibuffer of read-from-kill-ring (M-y). >> The reason is that read-from-kill-ring let binds history-add-new-input, >> and that affects all recursive minibuffers as well, so no minibuffer >> history is recorded until you exit the first (non-recursive) minibuffer. >> >> AFAICT This issue affects all uses history-add-new-input, unfortunately, >> not only read-from-kill-ring, since it's always used via let-bindings. > > I'm not sure we should be interested in fixing this. Recursive > minibuffers are not supposed to start a completely new command loop > unaffected by whatever was before it, so we shouldn't try. I see that, but the problem, IMO, is that there's nothing telling you that you're in this state of not recording minibuffer history. You likely won't know that you're using a command that let-binds history-add-new-input when you enter a recursive minibuffer, and losing all minibuffer history from commands you invoked in the recursive edit may come as an unpleasant surprise. > Even if this particular case is solved (which I'm not sure we can), > there are a legion of other similar situations, where something > let-bound by a command entering the minibuffer affects all the > recursive minibuffers. Let-binding in commands that prompt users is > ubiquitous in Emacs. Indeed, this issue is possibly broader. Often the solution is to use minibuffer-setup-hook to bind a variable buffer-locally in a minibuffer, rather than let-binding it (affecting all recursive minibuffers). For history-add-new-input this is slightly trickier since read_minibuf checks the value of this variable only after the minibuffer is exited. I'm experimenting with a possible solution where we change read_minibuf to grab the buffer-local value of this variable from the minibuffer, and change all users of history-add-new-input to set it buffer-locally instead of let-binding it. Works pretty well, but it doesn't cover third party code that uses this variable, naturally. > It's easy enough to work around the problem: C-g (perhaps more than > once), then start afresh. > > So I tend to close this as wontfix. All right, fair enough.
bug-gnu-emacs@HIDDEN:bug#69056; Package emacs.
Full text available.Received: (at 69056) by debbugs.gnu.org; 11 Feb 2024 17:50:49 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Feb 11 12:50:49 2024 Received: from localhost ([127.0.0.1]:35177 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rZDya-0001gJ-Td for submit <at> debbugs.gnu.org; Sun, 11 Feb 2024 12:50:49 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:43246) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1rZDyY-0001fv-Qv for 69056 <at> debbugs.gnu.org; Sun, 11 Feb 2024 12:50:47 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1rZDyD-00014i-0m; Sun, 11 Feb 2024 12:50:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=bkFe/+C2Np0hM6TA7HrbldtNj7X1+M8Gbeo/wYGXMPc=; b=an7Wm3Ze5vNk V/7q3KmzCQLeGfQYzIoxihHC/gKSzKVTMxw5ODU6xFISB2bLs/ZH6JrCCrdaW15KfzAJC+banUL4Z 9xAqo80qsTWojkRXDvPQtkPFjdl8K3VgJNjfzvCOYk92le9a35asNusMWT2tAW0rR/xDdadArfAh3 FOwubRvueNoPUD9x1RJmxB4i/2ODfsYQbh02ddIanjYf28oxFyfSdRUy3OV5WLfHYtu72idqP1FsQ ub+3ML0LExAZM6EIiHtQPSfBbg0tMJbJkonxZtpOSssdXvGAWorVJvbnVp2yB0U3VHv7/GOxbi03F qQbihNo1d9advHyt34Ez1g==; Date: Sun, 11 Feb 2024 19:50:21 +0200 Message-Id: <86frxysxeq.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Eshel Yaron <me@HIDDEN> In-Reply-To: <m1frxy3nja.fsf@HIDDEN> (message from Eshel Yaron on Sun, 11 Feb 2024 18:42:49 +0100) Subject: Re: bug#69056: 30.0.50; history-add-new-input and recursive minibuffers References: <m11q9jngho.fsf@HIDDEN> <86il2vrlri.fsf@HIDDEN> <m1frxy3nja.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 69056 Cc: 69056 <at> debbugs.gnu.org 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 (---) > From: Eshel Yaron <me@HIDDEN> > Cc: 69056 <at> debbugs.gnu.org > Date: Sun, 11 Feb 2024 18:42:49 +0100 > > Eli Zaretskii <eliz@HIDDEN> writes: > > > I'm not sure we should be interested in fixing this. Recursive > > minibuffers are not supposed to start a completely new command loop > > unaffected by whatever was before it, so we shouldn't try. > > I see that, but the problem, IMO, is that there's nothing telling you > that you're in this state of not recording minibuffer history. You > likely won't know that you're using a command that let-binds > history-add-new-input when you enter a recursive minibuffer, and losing > all minibuffer history from commands you invoked in the recursive edit > may come as an unpleasant surprise. We should probably document this caveat. enable-recursive-minibuffers is an advanced feature, not recommended to newbies.
bug-gnu-emacs@HIDDEN:bug#69056; Package emacs.
Full text available.Received: (at 69056) by debbugs.gnu.org; 11 Feb 2024 16:47:42 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Feb 11 11:47:42 2024 Received: from localhost ([127.0.0.1]:59484 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rZCzW-0007D3-46 for submit <at> debbugs.gnu.org; Sun, 11 Feb 2024 11:47:42 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:43482) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1rZCzS-0007Ci-U6 for 69056 <at> debbugs.gnu.org; Sun, 11 Feb 2024 11:47:39 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1rZCz7-0005Bj-5v; Sun, 11 Feb 2024 11:47:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=vLp6EONXvpZizCA41i98JJYfrdzD2XVJfF/NVIi0uKc=; b=XO6FHIVjbtT1 TubXytyNo465ZEMzIHlcgP96IoJHW/L1xWNIvKKvwmqQjrGILjI1AsgIxitilHTFpHIGs8lcj9QeV u8w0w42K8phPMo3fXr374kalVCNbFV7WdX5BXGAiusG4A8+Vh7mUcfVIRrh1u9TNz/d3zBfATTenB vFT0iRUYtzvCk5B/gMrzZZSv4KhnbJRRiXT3b72AZTvPtnGA/12Cr5TQeceFQmAGFqn0YgFgnApIw 8wDl3IuDuSeZsjYaWYWAsA2O1TOyxfP1F48Kdr/3UCYDDHt8W8hAqGDn1hrFEM5yRe1mFwAerXDBP 0GNXyDfARVgON02bD34+hQ==; Date: Sun, 11 Feb 2024 18:47:13 +0200 Message-Id: <86il2vrlri.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Eshel Yaron <me@HIDDEN> In-Reply-To: <m11q9jngho.fsf@HIDDEN> (bug-gnu-emacs@HIDDEN) Subject: Re: bug#69056: 30.0.50; history-add-new-input and recursive minibuffers References: <m11q9jngho.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 69056 Cc: 69056 <at> debbugs.gnu.org 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 (---) > Date: Sun, 11 Feb 2024 16:54:43 +0100 > From: Eshel Yaron via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN> > > > 1. emacs -Q > 2. (setq enable-recursive-minibuffers t) > 3. M-y > 4. In the minibuffer (with the prompt "Yank from kill-ring: "), > type M-x calendar RET (or any other command). > 5. M-x M-p > Expected: "calendar" is inserted in the minibuffer. > Observed: error saying "Beginning of history; no preceding item". > > The problem is that the minibuffer history of M-x isn't recorded when > you invoke M-x from within the minibuffer of read-from-kill-ring (M-y). > The reason is that read-from-kill-ring let binds history-add-new-input, > and that affects all recursive minibuffers as well, so no minibuffer > history is recorded until you exit the first (non-recursive) minibuffer. > > AFAICT This issue affects all uses history-add-new-input, unfortunately, > not only read-from-kill-ring, since it's always used via let-bindings. I'm not sure we should be interested in fixing this. Recursive minibuffers are not supposed to start a completely new command loop unaffected by whatever was before it, so we shouldn't try. Even if this particular case is solved (which I'm not sure we can), there are a legion of other similar situations, where something let-bound by a command entering the minibuffer affects all the recursive minibuffers. Let-binding in commands that prompt users is ubiquitous in Emacs. It's easy enough to work around the problem: C-g (perhaps more than once), then start afresh. So I tend to close this as wontfix.
bug-gnu-emacs@HIDDEN:bug#69056; Package emacs.
Full text available.Received: (at submit) by debbugs.gnu.org; 11 Feb 2024 15:55:12 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Feb 11 10:55:12 2024 Received: from localhost ([127.0.0.1]:56558 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rZCAi-0004yM-DP for submit <at> debbugs.gnu.org; Sun, 11 Feb 2024 10:55:12 -0500 Received: from lists.gnu.org ([2001:470:142::17]:39692) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <me@HIDDEN>) id 1rZCAh-0004y4-2r for submit <at> debbugs.gnu.org; Sun, 11 Feb 2024 10:55:11 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <me@HIDDEN>) id 1rZCAL-0001V3-8z for bug-gnu-emacs@HIDDEN; Sun, 11 Feb 2024 10:54:49 -0500 Received: from mail.eshelyaron.com ([107.175.124.16] helo=eshelyaron.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <me@HIDDEN>) id 1rZCAJ-00030X-FG for bug-gnu-emacs@HIDDEN; Sun, 11 Feb 2024 10:54:49 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com; s=mail; t=1707666886; bh=0plnITl3t7O43lUJw2EOXDLSUBU0wHNFq36DtcPIf54=; h=From:To:Subject:Date:From; b=WDlVY++KwvqfMqZI+UqFTgu/VWih3AFAT1sX83Y+jlqAdyZtyB/Zu8wz+4rrF8zm+ kzto92y9kjEOXG7Y3zcjA7WHo8obeo81s8jF/wRm33YkpP+xk2m4Gvl+hZBmR3Hi7Y Z/ePPJ1Rl1m2DRaPoyT+iKowcukGBHLg8Ok3IQnJ1H+qjWAlV+Y3X/+um5omj8ThPL nfEwXQfDxQ/ND7NxTvsW9IFFCb37PXWEziJgJcF+6M1f3opIa1FditT2zofLjNzfSo bvjEFSz1KRV/NK780E2aPQEi4NvbKtq8dHl5AQMYchH9QKtaaIw8zxs4VfRHIOJDrV zHWUj6sQRQmIQ== From: Eshel Yaron <me@HIDDEN> To: bug-gnu-emacs@HIDDEN Subject: 30.0.50; history-add-new-input and recursive minibuffers X-Debbugs-Cc: Date: Sun, 11 Feb 2024 16:54:43 +0100 Message-ID: <m11q9jngho.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=107.175.124.16; envelope-from=me@HIDDEN; helo=eshelyaron.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.9 (/) X-Debbugs-Envelope-To: submit 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 (/) 1. emacs -Q 2. (setq enable-recursive-minibuffers t) 3. M-y 4. In the minibuffer (with the prompt "Yank from kill-ring: "), type M-x calendar RET (or any other command). 5. M-x M-p Expected: "calendar" is inserted in the minibuffer. Observed: error saying "Beginning of history; no preceding item". The problem is that the minibuffer history of M-x isn't recorded when you invoke M-x from within the minibuffer of read-from-kill-ring (M-y). The reason is that read-from-kill-ring let binds history-add-new-input, and that affects all recursive minibuffers as well, so no minibuffer history is recorded until you exit the first (non-recursive) minibuffer. AFAICT This issue affects all uses history-add-new-input, unfortunately, not only read-from-kill-ring, since it's always used via let-bindings.
Eshel Yaron <me@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#69056; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.