GNU logs - #69056, boring messages

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#69056: 30.0.50; history-add-new-input and recursive minibuffers
Resent-From: Eshel Yaron <me@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 11 Feb 2024 15:56:02 +0000
Resent-Message-ID: <handler.69056.B.170766691219123 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 69056 <at> debbugs.gnu.org
From: Eshel Yaron <me@HIDDEN>
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-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.

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: Eshel Yaron <me@HIDDEN>
Subject: bug#69056: Acknowledgement (30.0.50; history-add-new-input and
 recursive minibuffers)
Message-ID: <handler.69056.B.170766691219123.ack <at> debbugs.gnu.org>
References: <m11q9jngho.fsf@HIDDEN>
X-Gnu-PR-Message: ack 69056
X-Gnu-PR-Package: emacs
Reply-To: 69056 <at> debbugs.gnu.org
Date: Sun, 11 Feb 2024 15:56: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 69056 <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
69056: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D69056
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#69056: 30.0.50; history-add-new-input and recursive minibuffers
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: Sun, 11 Feb 2024 16:48:02 +0000
Resent-Message-ID: <handler.69056.B69056.170767006227723 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Eshel Yaron <me@HIDDEN>
Cc: 69056 <at> debbugs.gnu.org
Date: Sun, 11 Feb 2024 18:47:13 +0200
Message-Id: <86il2vrlri.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <m11q9jngho.fsf@HIDDEN> (bug-gnu-emacs@HIDDEN)
References: <m11q9jngho.fsf@HIDDEN>
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

> 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.

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#69056: 30.0.50; history-add-new-input and recursive minibuffers
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: Sun, 11 Feb 2024 17:51:02 +0000
Resent-Message-ID: <handler.69056.B69056.17076738496473 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Eshel Yaron <me@HIDDEN>
Cc: 69056 <at> debbugs.gnu.org
Date: Sun, 11 Feb 2024 19:50:21 +0200
Message-Id: <86frxysxeq.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <m1frxy3nja.fsf@HIDDEN> (message from Eshel Yaron on Sun, 
 11 Feb 2024 18:42:49 +0100)
References: <m11q9jngho.fsf@HIDDEN> <86il2vrlri.fsf@HIDDEN>
 <m1frxy3nja.fsf@HIDDEN>
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

> 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.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#69056: 30.0.50; history-add-new-input and recursive minibuffers
Resent-From: Eshel Yaron <me@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 11 Feb 2024 18:03:02 +0000
Resent-Message-ID: <handler.69056.B69056.17076745648705 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 69056
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 69056 <at> debbugs.gnu.org
Received: via spool by 69056-submit <at> debbugs.gnu.org id=B69056.17076745648705
          (code B ref 69056); Sun, 11 Feb 2024 18:03:02 +0000
Received: (at 69056) by debbugs.gnu.org; 11 Feb 2024 18:02:44 +0000
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>
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-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.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#69056: 30.0.50; history-add-new-input and recursive minibuffers
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: Thu, 15 Feb 2024 08:20:01 +0000
Resent-Message-ID: <handler.69056.B69056.1707985190664 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 69056
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Kangas <stefankangas@HIDDEN>, Stefan Monnier <monnier@HIDDEN>
Cc: 69056 <at> debbugs.gnu.org, me@HIDDEN
Received: via spool by 69056-submit <at> debbugs.gnu.org id=B69056.1707985190664
          (code B ref 69056); Thu, 15 Feb 2024 08:20:01 +0000
Received: (at 69056) by debbugs.gnu.org; 15 Feb 2024 08:19:50 +0000
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>
In-Reply-To: <86frxysxeq.fsf@HIDDEN> (message from Eli Zaretskii on Sun, 11
 Feb 2024 19:50:21 +0200)
References: <m11q9jngho.fsf@HIDDEN> <86il2vrlri.fsf@HIDDEN>
 <m1frxy3nja.fsf@HIDDEN> <86frxysxeq.fsf@HIDDEN>
X-Spam-Score: -4.2 (----)
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?

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#69056: 30.0.50; history-add-new-input and recursive minibuffers
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 15 Feb 2024 15:26:02 +0000
Resent-Message-ID: <handler.69056.B69056.17080107114138 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 69056
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eshel Yaron <me@HIDDEN>
Cc: 69056 <at> debbugs.gnu.org
Received: via spool by 69056-submit <at> debbugs.gnu.org id=B69056.17080107114138
          (code B ref 69056); Thu, 15 Feb 2024 15:26:02 +0000
Received: (at 69056) by debbugs.gnu.org; 15 Feb 2024 15:25:11 +0000
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>
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-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

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#69056: 30.0.50; history-add-new-input and recursive minibuffers
Resent-From: Eshel Yaron <me@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 15 Feb 2024 16:18:02 +0000
Resent-Message-ID: <handler.69056.B69056.17080138719719 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 69056
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: 69056 <at> debbugs.gnu.org
Received: via spool by 69056-submit <at> debbugs.gnu.org id=B69056.17080138719719
          (code B ref 69056); Thu, 15 Feb 2024 16:18:02 +0000
Received: (at 69056) by debbugs.gnu.org; 15 Feb 2024 16:17:51 +0000
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>
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-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


--=-=-=--

Last modified: Thu, 15 Feb 2024 16:30:02 UTC

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