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 15:56:02 +0000 Resent-Message-ID: <handler.69056.B.170766691219123 <at> debbugs.gnu.org> Resent-Sender: help-debbugs@HIDDEN X-GNU-PR-Message: report 69056 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 69056 <at> debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@HIDDEN Received: via spool by submit <at> debbugs.gnu.org id=B.170766691219123 (code B ref -1); Sun, 11 Feb 2024 15:56:02 +0000 Received: (at submit) by debbugs.gnu.org; 11 Feb 2024 15:55:12 +0000 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> 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.
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
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: Sun, 11 Feb 2024 16:48:02 +0000 Resent-Message-ID: <handler.69056.B69056.170767006227723 <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.170767006227723 (code B ref 69056); Sun, 11 Feb 2024 16:48:02 +0000 Received: (at 69056) by debbugs.gnu.org; 11 Feb 2024 16:47:42 +0000 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> In-Reply-To: <m11q9jngho.fsf@HIDDEN> (bug-gnu-emacs@HIDDEN) References: <m11q9jngho.fsf@HIDDEN> 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 (---) > 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.
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: Sun, 11 Feb 2024 17:51:02 +0000 Resent-Message-ID: <handler.69056.B69056.17076738496473 <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.17076738496473 (code B ref 69056); Sun, 11 Feb 2024 17:51:02 +0000 Received: (at 69056) by debbugs.gnu.org; 11 Feb 2024 17:50:49 +0000 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> 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> 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 (---) > 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.
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.
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?
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
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 --=-=-=--
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.