From unknown Sun Aug 10 09:45:44 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#69056 <69056@debbugs.gnu.org> To: bug#69056 <69056@debbugs.gnu.org> Subject: Status: 30.0.50; history-add-new-input and recursive minibuffers Reply-To: bug#69056 <69056@debbugs.gnu.org> Date: Sun, 10 Aug 2025 16:45:44 +0000 retitle 69056 30.0.50; history-add-new-input and recursive minibuffers reassign 69056 emacs submitter 69056 Eshel Yaron severity 69056 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 11 10:55:12 2024 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 ) id 1rZCAi-0004yM-DP for submit@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 ) id 1rZCAh-0004y4-2r for submit@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 ) id 1rZCAL-0001V3-8z for bug-gnu-emacs@gnu.org; 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 ) id 1rZCAJ-00030X-FG for bug-gnu-emacs@gnu.org; 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 To: bug-gnu-emacs@gnu.org 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: 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@eshelyaron.com; 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@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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. From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 11 11:47:42 2024 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 ) id 1rZCzW-0007D3-46 for submit@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 ) id 1rZCzS-0007Ci-U6 for 69056@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 ) 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@gnu.org> From: Eli Zaretskii To: Eshel Yaron In-Reply-To: (bug-gnu-emacs@gnu.org) Subject: Re: bug#69056: 30.0.50; history-add-new-input and recursive minibuffers References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 69056 Cc: 69056@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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" > > > 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. From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 11 12:50:49 2024 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 ) id 1rZDya-0001gJ-Td for submit@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 ) id 1rZDyY-0001fv-Qv for 69056@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 ) 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@gnu.org> From: Eli Zaretskii To: Eshel Yaron In-Reply-To: (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: <86il2vrlri.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 69056 Cc: 69056@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Eshel Yaron > Cc: 69056@debbugs.gnu.org > Date: Sun, 11 Feb 2024 18:42:49 +0100 > > Eli Zaretskii 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. From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 11 13:02:43 2024 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 ) id 1rZEA7-0002GL-Gt for submit@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 ) id 1rZEA5-0002GD-2V for 69056@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 To: Eli Zaretskii Subject: Re: bug#69056: 30.0.50; history-add-new-input and recursive minibuffers In-Reply-To: <86il2vrlri.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 11 Feb 2024 18:47:13 +0200") References: <86il2vrlri.fsf@gnu.org> Date: Sun, 11 Feb 2024 18:42:49 +0100 Message-ID: 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@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii 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" >> >> >> 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. From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 15 03:19:50 2024 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 ) id 1raWyE-0000Ad-BW for submit@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 ) id 1raWyC-0000AQ-7C for 69056@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 ) 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@gnu.org> From: Eli Zaretskii To: Stefan Kangas , Stefan Monnier In-Reply-To: <86frxysxeq.fsf@gnu.org> (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: <86il2vrlri.fsf@gnu.org> <86frxysxeq.fsf@gnu.org> X-Spam-Score: -4.2 (----) X-Debbugs-Envelope-To: 69056 Cc: 69056@debbugs.gnu.org, me@eshelyaron.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.2 (-----) > Cc: 69056@debbugs.gnu.org > Date: Sun, 11 Feb 2024 19:50:21 +0200 > From: Eli Zaretskii > > > From: Eshel Yaron > > Cc: 69056@debbugs.gnu.org > > Date: Sun, 11 Feb 2024 18:42:49 +0100 > > > > Eli Zaretskii 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? From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 15 10:25:11 2024 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 ) id 1radbq-00014g-MJ for submit@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 ) id 1radbo-00014T-Nr for 69056@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 To: Eshel Yaron Subject: Re: bug#69056: 30.0.50; history-add-new-input and recursive minibuffers In-Reply-To: (Eshel Yaron's message of "Sun, 11 Feb 2024 16:54:43 +0100") Message-ID: References: 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@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 15 11:17:51 2024 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 ) id 1raeQo-0002Wh-KH for submit@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 ) id 1raeQm-0002WY-HW for 69056@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 To: Stefan Monnier Subject: Re: bug#69056: 30.0.50; history-add-new-input and recursive minibuffers In-Reply-To: (Stefan Monnier's message of "Thu, 15 Feb 2024 10:24:45 -0500") References: X-Hashcash: 1:20:240215:monnier@iro.umontreal.ca::/rjAqgxFdq3PtMPI:uNo X-Hashcash: 1:20:240215:69056@debbugs.gnu.org::DkJa9f3AjDEDikY1:3cmx Date: Thu, 15 Feb 2024 17:17:26 +0100 Message-ID: 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@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.9 (--) --=-=-= Content-Type: text/plain Stefan Monnier 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 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 --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 15 12:57:13 2024 Received: (at 69056) by debbugs.gnu.org; 15 Feb 2024 17:57:13 +0000 Received: from localhost ([127.0.0.1]:56917 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rafyy-00088O-Q3 for submit@debbugs.gnu.org; Thu, 15 Feb 2024 12:57:13 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:60056) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rafyw-000886-Ki for 69056@debbugs.gnu.org; Thu, 15 Feb 2024 12:57:11 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id B6F121000C3; Thu, 15 Feb 2024 12:56:45 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1708019804; bh=gl/OKg7Bqn0jvu519k1/eJAc4QxcI9IK8mToY5dMj50=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=DI+NuYMA6sXDAEUSKNUzIw9ZZotz5Pvqfr+Qc0KXiCZXTeya1J41Y+usoYFvVMhbw UGrvmdXczD4eU0+zDAqQj2/5e8B0UTH+qG739uptJnrANzjLiS5keo+rRBykl/Z92k GVrtYUvndpvZaZBPsKGxl+HnprhTGWwB7eGK2+bLTZEPy8tJkXa5+gK8JHmtRO2uWn vPJHJtrWSljWeMXkcibg35+5qzYoRlhvDlYBCMssbMYuy3HBerQXAhFY948/QUEbe1 7zUQa72MT2z+i83/BW7GB447v1+G2M+zc/7fSq7wDvV8yk6pN/fOfCro8J1EwE0QG9 8aAi1HYPivVJA== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id B6EC910004B; Thu, 15 Feb 2024 12:56:44 -0500 (EST) Received: from alfajor (unknown [23.233.149.155]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 9AB0A120713; Thu, 15 Feb 2024 12:56:44 -0500 (EST) From: Stefan Monnier To: Eshel Yaron Subject: Re: bug#69056: 30.0.50; history-add-new-input and recursive minibuffers In-Reply-To: (Eshel Yaron's message of "Thu, 15 Feb 2024 17:17:26 +0100") Message-ID: References: Date: Thu, 15 Feb 2024 12:56:43 -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.108 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@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.2 (-----) > Thanks, that's what I thought too. Here's an attempt do just that: Looks pretty good. I do have some comments/questions: > @@ -902,6 +903,9 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt, > /* Don't allow the user to undo past this point. */ > bset_undo_list (current_buffer, Qnil); > > + /* Cache the buffer-local value. */ > + nohist = NILP (find_symbol_value (Qhistory_add_new_input)); Why not use `Vhistory_add_new_input`? [ Also, it's not really "cache" (which implies it impacts only performance). More like "remember". ] > @@ -965,7 +969,7 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_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); > > /* If Lisp form desired instead of string, parse it. */ IIUC this change is needed because by the time we get here the buffer-local value of `history-add-new-input` has been flushed by `minibuffer-inactive-mode` called by `read_minibuf_unwind`, itself run by the `unbind_to` a few lines above. So maybe we can simplify this by just moving the above 2 lines before the `unbind_to`, WDYT? Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 15 13:40:54 2024 Received: (at 69056) by debbugs.gnu.org; 15 Feb 2024 18:40:54 +0000 Received: from localhost ([127.0.0.1]:57028 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ragfF-0003pf-FZ for submit@debbugs.gnu.org; Thu, 15 Feb 2024 13:40:54 -0500 Received: from mail.eshelyaron.com ([107.175.124.16]:60922 helo=eshelyaron.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ragfD-0003pW-7d for 69056@debbugs.gnu.org; Thu, 15 Feb 2024 13:40:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com; s=mail; t=1708022431; bh=VvYE+E/GmpWVACKZr7it1Baw+pNFoaheM2ArwZIzxbc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=oLYlaRRze5C3K524GNJqJUgnPjo8sohWjaVUa2zhdOl13RljD6ledzuLsaQCp8CB0 rnpFPV/6rGN2oB9eVF5ayYk+yOVW/7TZ6h87q+jybNrZX8xLl5r/6rqDW3zDxM8FGh X/Et23HzlAUcOXkW3zwDymNGJBrGR5GcTZiGkLOz2/1Xvxf6jiCqA4NhsoyLNnCx/7 Buy1Y6Wvfd8cAxylzm7x9CLExv+/NTxjo9PK/Qh5pLFl4TdwlQOLv7kfUzBtKzXDKg 6fGL8bfhuWnuRdq/WtJWUhRE/KzKIa0g+F2n4I4W0xGR74+rDu6vu1mx+TgFS4VsDS BnBkiVh1VHiEQ== From: Eshel Yaron To: Stefan Monnier Subject: Re: bug#69056: 30.0.50; history-add-new-input and recursive minibuffers In-Reply-To: (Stefan Monnier's message of "Thu, 15 Feb 2024 12:56:43 -0500") References: Date: Thu, 15 Feb 2024 19:40:29 +0100 Message-ID: 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@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.9 (--) --=-=-= Content-Type: text/plain Stefan Monnier writes: >> Thanks, that's what I thought too. Here's an attempt do just that: > > Looks pretty good. I do have some comments/questions: > >> @@ -902,6 +903,9 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt, >> /* Don't allow the user to undo past this point. */ >> bset_undo_list (current_buffer, Qnil); >> >> + /* Cache the buffer-local value. */ >> + nohist = NILP (find_symbol_value (Qhistory_add_new_input)); > > Why not use `Vhistory_add_new_input`? Good question, I guess for some reason I assumed that `NILP (Vfoo)` doesn't check the buffer-local value like `find_symbol_value (Qfoo)` does... > [ Also, it's not really "cache" (which implies it impacts only > performance). More like "remember". ] >> @@ -965,7 +969,7 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_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); >> >> /* If Lisp form desired instead of string, parse it. */ > > IIUC this change is needed because by the time we get here the > buffer-local value of `history-add-new-input` has been flushed by > `minibuffer-inactive-mode` called by `read_minibuf_unwind`, > itself run by the `unbind_to` a few lines above. > So maybe we can simplify this by just moving the above 2 lines before > the `unbind_to`, WDYT? Oh, that's much simpler indeed. And it seems to work just as well. Here's an updated patch (v2): --=-=-= Content-Type: text/x-patch; charset=utf-8 Content-Disposition: attachment; filename=v2-0001-Use-buffer-local-value-of-history-add-new-input-i.patch Content-Transfer-Encoding: quoted-printable >From 66fc69ff23911aa6e91e290a71568cf14d076d58 Mon Sep 17 00:00:00 2001 From: Eshel Yaron Date: Sun, 11 Feb 2024 16:18:48 +0100 Subject: [PATCH v2] 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. (Bug#69056) --- doc/lispref/minibuf.texi | 6 +++--- lisp/isearch.el | 12 +++++++----- lisp/replace.el | 36 +++++++++++++++++++----------------- lisp/simple.el | 4 ++-- src/minibuf.c | 12 ++++++------ 5 files changed, 37 insertions(+), 33 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..88993659b90 100644 --- a/src/minibuf.c +++ b/src/minibuf.c @@ -948,6 +948,12 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Li= sp_Object prompt, else histstring =3D Qnil; =20 + /* 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))) + call2 (Qadd_to_history, histvar, histstring); + /* The appropriate frame will get selected in set-window-configuration. */ unbind_to (count, Qnil); @@ -962,12 +968,6 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Li= sp_Object prompt, calling_frame)))) call2 (Qselect_frame_set_input_focus, calling_frame, Qnil); =20 - /* 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))) - call2 (Qadd_to_history, histvar, histstring); - /* If Lisp form desired instead of string, parse it. */ if (expflag) val =3D string_to_object (val, defalt); --=20 2.42.0 --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 15 14:20:39 2024 Received: (at 69056) by debbugs.gnu.org; 15 Feb 2024 19:20:39 +0000 Received: from localhost ([127.0.0.1]:57085 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rahHj-0004x9-7o for submit@debbugs.gnu.org; Thu, 15 Feb 2024 14:20:39 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:38391) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rahHf-0004wg-R5 for 69056@debbugs.gnu.org; Thu, 15 Feb 2024 14:20:38 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 6B9A61000C3; Thu, 15 Feb 2024 14:20:10 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1708024809; bh=OGxQN897ymGsmqog4wFnheuFbr5rx+F4evb3ZgSh0pU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=lxoEwTCjK2HC9KFPlznfMlxUCytqLn5rSIBRRDZ3zCGyByzlcp9b6kQKTz34liBc0 +w1sdYpxD0l6HZT7x5wIRSVJ+YXcLlNJN2+5xjpXxAr0c2znI+hFXWlL9E2fgIJSlw d1iBraNPOkBpfxCuN5+hipHngmp0UFJJrmcCYaVJuri5iFeqstRx2+ETastOpveP0p t/B+tisZWb5twhfSq8VK976cdySzbJAobVJWqz5fA4LYs667VCk8qMF8Am3nPH8kXs KCqwZ1eJArdwb+k32ps+n94B33c74pHZD9ioeGe6msFtZVNOl6rIn2gHUtgzv78dSV JSuKTnZYlL+Kg== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 7490510004B; Thu, 15 Feb 2024 14:20:09 -0500 (EST) Received: from alfajor (unknown [23.233.149.155]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 59DD812027F; Thu, 15 Feb 2024 14:20:09 -0500 (EST) From: Stefan Monnier To: Eshel Yaron Subject: Re: bug#69056: 30.0.50; history-add-new-input and recursive minibuffers In-Reply-To: (Eshel Yaron's message of "Thu, 15 Feb 2024 19:40:29 +0100") Message-ID: References: Date: Thu, 15 Feb 2024 14:20:08 -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.099 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@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.2 (-----) >> Why not use `Vhistory_add_new_input`? > Good question, I guess for some reason I assumed that `NILP (Vfoo)` > doesn't check the buffer-local value like `find_symbol_value (Qfoo)` > does... The handling of Vfoo is quite delicate, but it does give you the value in the current-buffer (i.e. they're changed as needed whenever we go through `set_buffer`). > Oh, that's much simpler indeed. And it seems to work just as well. > Here's an updated patch (v2): LGTM. Eli&Stefan, any objection? Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 15 14:30:27 2024 Received: (at 69056) by debbugs.gnu.org; 15 Feb 2024 19:30:27 +0000 Received: from localhost ([127.0.0.1]:57098 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rahRD-0005FE-CR for submit@debbugs.gnu.org; Thu, 15 Feb 2024 14:30:27 -0500 Received: from eggs.gnu.org ([209.51.188.92]:57912) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rahRA-0005Ey-PO for 69056@debbugs.gnu.org; Thu, 15 Feb 2024 14:30:25 -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 ) id 1rahOe-0004cf-Iq; Thu, 15 Feb 2024 14:27:48 -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=zT7krack6pLGNZa/JVFw93aJaLAGfcX0EH0g59hRLTA=; b=OnL43HSsB20L wyT93oTjPqqSXkaiwqBVp+nl9u9hI0fhgX44HUzGeJJP09Wr3g0dS4i5knL5XBDRa2LySqUMLvIw+ /nU979NSb/nPZmzVmyBja638A2eQSZVMdfWYQFoASsNgYArLtqSOHGoa54t5huvygRuyBmTPwWF9p p6856Osv7oYo5wsMJp/GthO86ezvoz3lyo83YmCTlpwtPMUt3eZgPN7boUCxn0XHJWu/GvwvRG4Me N7EuXvjbkKPszjKHoBB4vrXPMxoYD6g4SOorhzRvJiekHnJDTmBzXPUbKFdUNkSj/SXhff7Bb65d6 KgqjN/jlKKBDZ/T50BzXBQ==; Date: Thu, 15 Feb 2024 21:27:44 +0200 Message-Id: <8634ttwmrz.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (bug-gnu-emacs@gnu.org) Subject: Re: bug#69056: 30.0.50; history-add-new-input and recursive minibuffers References: X-Spam-Score: -4.2 (----) X-Debbugs-Envelope-To: 69056 Cc: 69056@debbugs.gnu.org, me@eshelyaron.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.2 (-----) > Cc: 69056@debbugs.gnu.org > Date: Thu, 15 Feb 2024 12:56:43 -0500 > From: Stefan Monnier via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > > Thanks, that's what I thought too. Here's an attempt do just that: > > Looks pretty good. Is this really worthwhile? It might solve some problems with commands invoked from the recursive edit, but it doesn't solve all of them, because the value of history-add-new-input is still set in that minibuffer. And it introduces tricky effects due to the variable being buffer-local for any code that let-binds history-add-new-input, and could potentially break something because of that. I'm afraid I don't like this change, for those reasons. From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 15 14:34:43 2024 Received: (at 69056) by debbugs.gnu.org; 15 Feb 2024 19:34:43 +0000 Received: from localhost ([127.0.0.1]:57108 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rahVL-0005Mh-G4 for submit@debbugs.gnu.org; Thu, 15 Feb 2024 14:34:43 -0500 Received: from eggs.gnu.org ([209.51.188.92]:51582) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rahVJ-0005MR-Qn for 69056@debbugs.gnu.org; Thu, 15 Feb 2024 14:34:42 -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 ) id 1rahUu-0005yG-1d; Thu, 15 Feb 2024 14:34:16 -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=n0yeLMZxOzvbTa8aWc+xzE6Tu5GC1MqpVZ0RS4PcvAQ=; b=iGrC2j3EgFim csMIVqQBf5xkXWWWvanrmHZgMICDw5usNRILd+tnOW3TPpg3rYfCorgfQ1cpnDklr17GBvQnNUm9S f5osxSbnZxJS9Msk8rLa1uGU3isi+W0nKbzxmWTufj4DQyEQrmTUCs6okTg1MO2y8p20VjiipPzqC ve1dBXI+6eEv8cYOzv1HOZu5rOrdGdtF/dlvwK+LZfH5UfvNc+syAnQn4aFEhZnvQKYGuzi/uZAXR ggOx+7M487E75KnURRdS8+jnoKtcSlJJXtTOawWnax4CiauyFnnUFYviQw6G3RSNYQa+Yh0D+9JFK VLzarKwS80pCxCJQGufO9w==; Date: Thu, 15 Feb 2024 21:34:09 +0200 Message-Id: <86zfw1v7wu.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (bug-gnu-emacs@gnu.org) Subject: Re: bug#69056: 30.0.50; history-add-new-input and recursive minibuffers References: X-Spam-Score: -4.2 (----) X-Debbugs-Envelope-To: 69056 Cc: 69056@debbugs.gnu.org, me@eshelyaron.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.2 (-----) > Cc: 69056@debbugs.gnu.org > Date: Thu, 15 Feb 2024 14:20:08 -0500 > From: Stefan Monnier via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > >> Why not use `Vhistory_add_new_input`? > > Good question, I guess for some reason I assumed that `NILP (Vfoo)` > > doesn't check the buffer-local value like `find_symbol_value (Qfoo)` > > does... > > The handling of Vfoo is quite delicate, but it does give you the value > in the current-buffer (i.e. they're changed as needed whenever we go > through `set_buffer`). > > > Oh, that's much simpler indeed. And it seems to work just as well. > > Here's an updated patch (v2): > > LGTM. > Eli&Stefan, any objection? Yes, see my other message. I feel like we are making an effort to change the internals, which runs the usual risk of breaking things, for very little gain. The more general issue with let-binding variables around APIs that enter the minibuffer stays, so I see little sense to fix just this one problem in an incomplete way that could on top of that break existing code. From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 15 14:54:35 2024 Received: (at 69056) by debbugs.gnu.org; 15 Feb 2024 19:54:35 +0000 Received: from localhost ([127.0.0.1]:57120 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rahoZ-000635-EV for submit@debbugs.gnu.org; Thu, 15 Feb 2024 14:54:35 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:47615) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rahoX-00062r-LD for 69056@debbugs.gnu.org; Thu, 15 Feb 2024 14:54:34 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 33F421000C3; Thu, 15 Feb 2024 14:54:09 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1708026848; bh=j6hGusEZ11e6yivysAkXD/oW5VlmoyHAVgHGOKBAlZY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=jOOsxVs9T56RM/8UX05uu3iVg9FnTkQaQYqnXyr1+l+soUP5GI76hdoJDdK4W8Yqe WDds4XiSg0Ov4mM6K+F7jjeZVkFbRkHRvYteJgQ4La42ZowPiX5iSzuH/cKD6ebsbS VtfUEb9vHHm8j/G1hBahYVr32dR39RZNUOGfPsDlPVmPMGrBX+qQSYc+rosLiDxTJZ AZ9v3ic5ZMLPl26KVigOtlUae2uuxEloe4DiGicf0Fdmjzfy0QhXFvEPIap4eQQxHR +T4HbyUF3kAwKh+WL7DfJ23zPF4LgiZQj8Pe5mMu7Ch0jsYpQD8zP1ayYWe13lMWbw xwZgJerUzB6Hw== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 25DDC10004B; Thu, 15 Feb 2024 14:54:08 -0500 (EST) Received: from alfajor (unknown [23.233.149.155]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 033C4120131; Thu, 15 Feb 2024 14:54:07 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#69056: 30.0.50; history-add-new-input and recursive minibuffers In-Reply-To: <86zfw1v7wu.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 15 Feb 2024 21:34:09 +0200") Message-ID: References: <86zfw1v7wu.fsf@gnu.org> Date: Thu, 15 Feb 2024 14:54:07 -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.091 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@debbugs.gnu.org, me@eshelyaron.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.2 (-----) > for very little gain. The more general issue with let-binding > variables around APIs that enter the minibuffer stays, so I see little I agree that it would be good to tackle this more general problem. Basically, should we treat recursive-edits as if they were run in a sort of separate thread (with the original thread blocked until the new thread exits)? I think we can't do that in general, since I think we sometimes do want let-bindings performed around `read-from-minibuffer` to affect the command executed inside the minibuffer. But we should maybe experiment with it to get a clearer idea of where we do want/need it and where we don't. Stefan From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 16 02:11:36 2024 Received: (at 69056) by debbugs.gnu.org; 16 Feb 2024 07:11:36 +0000 Received: from localhost ([127.0.0.1]:57801 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rasNj-00052S-Sr for submit@debbugs.gnu.org; Fri, 16 Feb 2024 02:11:36 -0500 Received: from eggs.gnu.org ([209.51.188.92]:52620) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rasNh-00052D-1W for 69056@debbugs.gnu.org; Fri, 16 Feb 2024 02:11:34 -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 ) id 1rasLB-0007Zl-5S; Fri, 16 Feb 2024 02:08:57 -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=cDQi7O6/pONbdgXweKp+Nogv7+jLy9jqlUaFufnPfrA=; b=kmGAeQT1r/ut zQg/UcBKAjdgNytuqzuQkpzygwja54tF4z3Mgp18BfmOZpDDdwbRKQhESJtjiZesX6TDPfd2/rjUZ oVZliWQ1xu2jiXMJ1SrvXOh9E1IWfQBm62aqaVMLMf/ljwfCIgP4sgFDtwqU/AUTCXWkn+5On5JWM f4HUyMfOQPva6ltp9bj/T6DTCsBM6fSrvd9JGXXU6ybe3drd2+lAUqc0TA0fXXxFVw3CytxkNfVMl BpS8MgSZ+26m3Yhsyny7EBCbwPLuSyD/T87b9iP/laG+DyZ6O6mbSC9uycxHRrYYk/XTE1pTZhj6w a9HGvHnV3TSe2qiu2sJzGQ==; Date: Fri, 16 Feb 2024 09:08:52 +0200 Message-Id: <86y1bkvqbf.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Thu, 15 Feb 2024 14:54:07 -0500) Subject: Re: bug#69056: 30.0.50; history-add-new-input and recursive minibuffers References: <86zfw1v7wu.fsf@gnu.org> X-Spam-Score: -4.2 (----) X-Debbugs-Envelope-To: 69056 Cc: 69056@debbugs.gnu.org, me@eshelyaron.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.2 (-----) > From: Stefan Monnier > Cc: me@eshelyaron.com, 69056@debbugs.gnu.org > Date: Thu, 15 Feb 2024 14:54:07 -0500 > > > for very little gain. The more general issue with let-binding > > variables around APIs that enter the minibuffer stays, so I see little > > I agree that it would be good to tackle this more general problem. > > Basically, should we treat recursive-edits as if they were run in a sort > of separate thread (with the original thread blocked until the new > thread exits)? I don't think we can do that by default. We need some evidence that this is the intent. > I think we can't do that in general, since I think we sometimes do want > let-bindings performed around `read-from-minibuffer` to affect the > command executed inside the minibuffer. Exactly. And doing so is a very wide-spread paradigm in Emacs. Which is one reason why enable-recursive-minibuffers is not turned on by default, and should be considered an advanced feature for users who "know what they are doing" and are ready to sustain the consequences. > But we should maybe experiment with it to get a clearer idea of > where we do want/need it and where we don't. Perhaps. But I'd like to hear concrete ideas for such experiments before I have an opinion on their value.