From unknown Sat Sep 13 17:04:05 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#79404 <79404@debbugs.gnu.org> To: bug#79404 <79404@debbugs.gnu.org> Subject: Status: [BUG] eldoc-last-message should be a buffer-local variable Reply-To: bug#79404 <79404@debbugs.gnu.org> Date: Sun, 14 Sep 2025 00:04:05 +0000 retitle 79404 [BUG] eldoc-last-message should be a buffer-local variable reassign 79404 emacs submitter 79404 me@lua.blog.br severity 79404 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 07 17:52:20 2025 Received: (at submit) by debbugs.gnu.org; 7 Sep 2025 21:52:20 +0000 Received: from localhost ([127.0.0.1]:46587 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uvNJ5-0005Of-TI for submit@debbugs.gnu.org; Sun, 07 Sep 2025 17:52:20 -0400 Received: from lists.gnu.org ([2001:470:142::17]:59560) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uvNJ0-0005OE-Qt for submit@debbugs.gnu.org; Sun, 07 Sep 2025 17:52:15 -0400 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 1uvNIq-000859-Gb for bug-gnu-emacs@gnu.org; Sun, 07 Sep 2025 17:52:05 -0400 Received: from fly.ash.relay.mailchannels.net ([23.83.222.61]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uvNIY-0007pq-UH for bug-gnu-emacs@gnu.org; Sun, 07 Sep 2025 17:52:03 -0400 X-Sender-Id: hostingeremailsmtpin|x-authuser|lua@lua.blog.br Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 7CA43323FBB for ; Sun, 7 Sep 2025 21:51:37 +0000 (UTC) Received: from fr-int-smtpout13.hostinger.io (100-107-6-26.trex-nlb.outbound.svc.cluster.local [100.107.6.26]) (Authenticated sender: hostingeremailsmtpin) by relay.mailchannels.net (Postfix) with ESMTPA id AA964323F26 for ; Sun, 7 Sep 2025 21:51:36 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1757281897; a=rsa-sha256; cv=none; b=MjXhThX7VBs2RGWgxsvGwje9q5D/IcnbrsW0Pur1IPnWT3+cNWskT6D5uy8tRv9IboJi6e PBbeeprW8BrV61MW6gcaWiApaMm/74DGMkolUsdlC9qGGPdpWkZL9sL1ZCPZxT/5gX+mDm X4Gugl9q30jp0E79DEDz1rbBolckCnAS3HouzOno8NYIEJX7zO/3fBf0+nFL5Ayxw+Lwjt 8LmU7Zp7o9Wp/bIQcbkmJR2niS6INCfzEe2ku3Ya9AgrOaTWKA4KVyp7D7jyeHjzUjxKDi dBDPHcNVwGBYTW5W2OLlxwfUstPMHpQk2W3AsKc1HXln3n2nEXyx1EyG0IQmpw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1757281897; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:dkim-signature; bh=HhOmZXIURtt7ozTwCwiRzKRUNjIGkaPCKFqODVD84BU=; b=mJ0mJIx0lT+wOdLQPjyMjvGQR4zSGLioFA6dNegmCqJciU2fdw4TnxgszMisSIibH4k4ON xNL2Lnjd0tifRlV1WDdpP629p3+BmrNpYCZs0rVVVzQFY011+vbt0Nc8GE2yN1mWI4F9sY SzKVkJNep1iKatPg2xR+F0m8LG+IJCYqaakYORPbb0U7IVLbCNvnoTvIGOZU5fPAMe3r4/ LK+/8E0VIAt8eGjjLycPXREeFWJc7c09O3wZ7k0O41kMm7LgOWUaItVWEjq3aABIEoYB8h SAVUHw08N6waglNj4TI2J9m8g/5xTMb7IxpCBE4IuWG7fMHzX6R3OdaUVbREDg== ARC-Authentication-Results: i=1; rspamd-8b9589799-kl5xh; auth=pass smtp.auth=hostingeremailsmtpin smtp.mailfrom=me@lua.blog.br X-Sender-Id: hostingeremailsmtpin|x-authuser|lua@lua.blog.br X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremailsmtpin|x-authuser|lua@lua.blog.br X-MailChannels-Auth-Id: hostingeremailsmtpin X-Tasty-Industry: 6c79b35f1028c636_1757281897224_2542720399 X-MC-Loop-Signature: 1757281897224:1631958111 X-MC-Ingress-Time: 1757281897223 Received: from fr-int-smtpout13.hostinger.io ([UNAVAILABLE]. [148.222.54.40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.107.6.26 (trex/7.1.3); Sun, 07 Sep 2025 21:51:37 +0000 Received: from [IPV6:2804:14d:8084:a662::337f] (unknown [IPv6:2804:14d:8084:a662::337f]) (Authenticated sender: lua@lua.blog.br) by smtp.hostinger.com (smtp.hostinger.com) with ESMTPSA id 4cKkLZ1rnqz158h for ; Sun, 7 Sep 2025 21:51:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lua.blog.br; s=hostingermail-a; t=1757281895; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=HhOmZXIURtt7ozTwCwiRzKRUNjIGkaPCKFqODVD84BU=; b=HPsV8Yz+gEYMUXbX3XDdteEfJEpe6fGpkfMzWO9T9jqKYhkZTuGziib1eZl2TdNESbxE9S dqBa75rN4nK4JOsqXxuoJHDkob/H9YouKwc4zo6YS6VLOPM3Bpq6zAWaInU8nDx/dWTijz r54jaPSXsEAMaKQTpHa1c5iiYgMft0CP6SvUQS3/1qWWUOZmKVGdrI3Bjl8kWxCwWv+2zd FJf9gzwkXhzj0XEJAX5CIZeVkkCrHSL2mlr9iTJmUei4yIe6PU/fRsMORQJwoaGoyaN39d jACj9kHv44z0ciTwyAN17WwHvd+unOgo7jgeBW3xYRPmqtGKEhulEIrtEpn4fA== Message-ID: <7b264787-424d-4009-aaab-647a4af8c98d@lua.blog.br> MIME-Version: 1.0 User-Agent: Betterbird (Linux) Content-Language: en-US, pt-BR To: bug-gnu-emacs@gnu.org From: Lua Viana Reis Subject: [BUG] eldoc-last-message should be a buffer-local variable Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Sun, 7 Sep 2025 21:51:33 +0000 (UTC) X-CM-Envelope: MS4xfNq99/YQ163+70HPD83Y5fvmqt59uqgzi6ngh8CqA9SKZF56LxlP9+ewMqR7fhoQ+fe45/jzhgCwlDcOVNRf/X9vNSvc4oFFom3KmGzSkGIbqFIGmyCM Yfd0irufzPlucf+hVjfp54NxDfwkNtfsnyc8vpww+7BQbipipEkvg6UEZ0ydYJJ/ma9LlVFqq6GkLI1P3HxdLSQA134D9CFI+x+lg5d3NaNgLh8XGoR5sD0Y X-CM-Analysis: v=2.4 cv=DJTd4DNb c=1 sm=1 tr=0 ts=68bdfe66 a=+I0ii6VlbupKkLXllcc6xg==:617 a=xqWC_Br6kY4A:10 a=IkcTkHD0fZMA:10 a=64d_UA3UoDNzmIRzlNYA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 X-AuthUser: lua@lua.blog.br Received-SPF: pass client-ip=23.83.222.61; envelope-from=me@lua.blog.br; helo=fly.ash.relay.mailchannels.net X-Spam_score_int: -19 X-Spam_score: -2.0 X-Spam_bar: -- X-Spam_report: (-2.0 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) 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: , Reply-To: me@lua.blog.br Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Hi all, Today I was wondering why the Eldoc echo area message kept flickering when I moved around the file. After inpecting eldoc.el, I found from the comment above the function "eldoc-pre-command-refresh-echo-area" that this should not be the case and something was broken: > ;; This function goes on pre-command-hook. > ;; Motion commands clear the echo area for some reason, > ;; which make eldoc messages flicker or disappear just before motion > ;; begins.  This function reprints the last eldoc message immediately > ;; before the next command executes, which does away with the flicker. > ;; This doesn't seem to be required for Emacs 19.28 and earlier. > ;; FIXME: The above comment suggests we don't really understand why > ;; this is needed.  Maybe it's not needed any more, but if it is > ;; we should figure out why. > (defun eldoc-pre-command-refresh-echo-area () >   "Reprint `eldoc-last-message' in the echo area." >   (and eldoc-last-message >        (not (minibufferp))      ;We don't use the echo area when in > minibuffer. >        (if (and (eldoc-display-message-no-interference-p) >         (eldoc--message-command-p this-command)) >        (eldoc--message eldoc-last-message) >          ;; No need to call eldoc--message since the echo area will be > cleared >          ;; for us, but do note that the last-message will be gone. >          (setq eldoc-last-message nil)))) So I used debug-on-variable-change to find out what was going on, and found that the variable eldoc-last-message was being set to nil immediately after being set. This variable is not buffer-local, and the "(special-mode)" call in eldoc-doc-buffer-separator (called on every eldoc message) would trigger "(global-eldoc-mode-enable-in-buffer)" which in turn resets the global value to nil. This is the bug, and I think the simple solution is to make it buffer-local, which fixes the issue: (make-variable-buffer-local 'eldoc-last-message) I don't see why this variable should be global, but if there is a good reason, then perhaps eldoc-last-message should not be set to nil in the (eldoc-mode) function, or something else should be done to prevent this feedback loop from happening. Perhaps this bug report can also serve as an explanation for the person who wrote "FIXME", because eldoc-pre-command-refresh-echo-area is still necessary to prevent the flicker (given that the main issue is solved). kind regards, Lua From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 13 05:51:25 2025 Received: (at 79404) by debbugs.gnu.org; 13 Sep 2025 09:51:26 +0000 Received: from localhost ([127.0.0.1]:53630 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uxMuj-0005MB-Cp for submit@debbugs.gnu.org; Sat, 13 Sep 2025 05:51:25 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:55650) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uxMuh-0005Lp-2I for 79404@debbugs.gnu.org; Sat, 13 Sep 2025 05:51:23 -0400 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 1uxMuZ-0000cN-B7; Sat, 13 Sep 2025 05:51:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=XYe7w6FhLOUTPf+uHzgQqbr0d6bdDfenIVVmYyxvDA8=; b=mlG3C1zG9XamCEX7vp5P aQRetlqquf35wKn/ucwyHYA/Qt4KvMwEAorlFkfyP5SvEZrpnbGXR0YwyhH4XmNsXGZqpBOW7EzP2 WjQPJN7okHDhdl+8Jod37dtTELVknH9GUxGshfoErUwQ4+7GvldzH/IFCUP+GJEqTmH3exYre3xf1 h/RrFmAd3FZIWEre9gn2wvjFEkwhO9bJ9CsfhQQiRayetDn1Quzun9Wn7BLrGpW0ZODQf1wtUKVRj kwjZaDM8iJSoLtydcpf876qi9LT1aTNZsi2SrnIjp2lN67cSuOFoDyWU5CrEgVNkGeY/l4O53w4li ob8mFi/ey/x1uw==; Date: Sat, 13 Sep 2025 12:51:11 +0300 Message-Id: <86ldmir88g.fsf@gnu.org> From: Eli Zaretskii To: me@lua.blog.br, Stefan Monnier In-Reply-To: <7b264787-424d-4009-aaab-647a4af8c98d@lua.blog.br> (message from Lua Viana Reis on Sun, 7 Sep 2025 21:51:33 +0000 (UTC)) Subject: Re: bug#79404: [BUG] eldoc-last-message should be a buffer-local variable References: <7b264787-424d-4009-aaab-647a4af8c98d@lua.blog.br> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79404 Cc: 79404@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: Lua Viana Reis > Date: Sun, 7 Sep 2025 21:51:33 +0000 (UTC) > > Hi all, > > Today I was wondering why the Eldoc echo area message kept flickering > when I moved around the file. After inpecting eldoc.el, I found from the > comment above the function "eldoc-pre-command-refresh-echo-area" that > this should not be the case and something was broken: > > > ;; This function goes on pre-command-hook. > > ;; Motion commands clear the echo area for some reason, > > ;; which make eldoc messages flicker or disappear just before motion > > ;; begins.  This function reprints the last eldoc message immediately > > ;; before the next command executes, which does away with the flicker. > > ;; This doesn't seem to be required for Emacs 19.28 and earlier. > > ;; FIXME: The above comment suggests we don't really understand why > > ;; this is needed.  Maybe it's not needed any more, but if it is > > ;; we should figure out why. > > (defun eldoc-pre-command-refresh-echo-area () > >   "Reprint `eldoc-last-message' in the echo area." > >   (and eldoc-last-message > >        (not (minibufferp))      ;We don't use the echo area when in > > minibuffer. > >        (if (and (eldoc-display-message-no-interference-p) > >         (eldoc--message-command-p this-command)) > >        (eldoc--message eldoc-last-message) > >          ;; No need to call eldoc--message since the echo area will be > > cleared > >          ;; for us, but do note that the last-message will be gone. > >          (setq eldoc-last-message nil)))) > > So I used debug-on-variable-change to find out what was going on, and > found that the variable eldoc-last-message was being set to nil > immediately after being set. This variable is not buffer-local, and the > "(special-mode)" call in eldoc-doc-buffer-separator (called on every > eldoc message) would trigger "(global-eldoc-mode-enable-in-buffer)" > which in turn resets the global value to nil. > > This is the bug, and I think the simple solution is to make it > buffer-local, which fixes the issue: > > (make-variable-buffer-local 'eldoc-last-message) > > I don't see why this variable should be global, but if there is a good > reason, then perhaps eldoc-last-message should not be set to nil in the > (eldoc-mode) function, or something else should be done to prevent this > feedback loop from happening. > > Perhaps this bug report can also serve as an explanation for the person > who wrote "FIXME", because eldoc-pre-command-refresh-echo-area is still > necessary to prevent the flicker (given that the main issue is solved). Thanks. Sounds right to me, but I'm not familiar with ElDoc enough to be sure. Stefan, does this sound right to you? If not, why is eldoc-last-message a global var? From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 13 12:30:21 2025 Received: (at 79404) by debbugs.gnu.org; 13 Sep 2025 16:30:21 +0000 Received: from localhost ([127.0.0.1]:56368 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uxT8n-0007ra-FP for submit@debbugs.gnu.org; Sat, 13 Sep 2025 12:30:21 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:34978) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uxT8k-0007q7-6Y for 79404@debbugs.gnu.org; Sat, 13 Sep 2025 12:30:18 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 45FE58167D; Sat, 13 Sep 2025 12:30:12 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1757781010; bh=EOaaeU3e/KqHgEIBIjurvPu3E0UGxIM0tyqePSYo+CY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=kSFqm/CtQDZD9xx98Krpux0t8JyUqUmf1UU/1JySnhlmEqa9dV02vWzFyvlxbqApG TBioX3Nh8aheGePrwssw+OwvuCGHU6TZCbOR9R/vnGBnkQmtD3ni3EmHj/icnP0Jti n5QYIE6JUHS8ACE/Kka/H9AIvd8B2WZrDAmtUuB2REeihstvKiHf8CNR2wSY259i0/ 6K/EBCbMQq+AVz1grR481Tf+nJKTCzxH4ABb0l9EZMX2ig08/NSwgekbL50iY+9HBM UxgwQeAUxdXfh5Y1toFhje3Wg6dAqQrBwdoRrwTQPk9FkQ6pNo+lhxL5GxoB9Fz6bS WBRv6ytqATMvw== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id C8B3C806F8; Sat, 13 Sep 2025 12:30:10 -0400 (EDT) Received: from pastel (unknown [104.247.225.131]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 997DF120403; Sat, 13 Sep 2025 12:30:10 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#79404: [BUG] eldoc-last-message should be a buffer-local variable In-Reply-To: <86ldmir88g.fsf@gnu.org> Message-ID: References: <7b264787-424d-4009-aaab-647a4af8c98d@lua.blog.br> <86ldmir88g.fsf@gnu.org> Date: Sat, 13 Sep 2025 12:30:09 -0400 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.257 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 X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79404 Cc: me@lua.blog.br, 79404@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 (---) >> So I used debug-on-variable-change to find out what was going on, and >> found that the variable eldoc-last-message was being set to nil >> immediately after being set. This variable is not buffer-local, and the >> "(special-mode)" call in eldoc-doc-buffer-separator (called on every >> eldoc message) would trigger "(global-eldoc-mode-enable-in-buffer)" >> which in turn resets the global value to nil. >> >> This is the bug, and I think the simple solution is to make it >> buffer-local, which fixes the issue: >> >> (make-variable-buffer-local 'eldoc-last-message) [...] > Stefan, does this sound right to you? If not, why is > eldoc-last-message a global var? I don't think anyone thought very deeply about whether it should be global or buffer-local when writing the code. The above suggest making it buffer-local could make sense, yet the actual display of the message is "global" in the sense that it's displayed in the echo area that is shared by all buffers. So, I'm personally not sure which of global or buffer-local is The Right Choice. The code that handles *re*displaying and *un*displaying the eldoc info is a bit too complex for me to figure out. OTOH, if the var is global, I can't see why the buffer-local `eldoc-mode` should set it to nil. Furthermore, maybe we should also look into why `eldoc-mode` is enabled during `eldoc-doc-buffer-separator`. E.g. it might make sense to change `eldoc--supported-p` so it returns nil in temp buffers. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 13 12:40:09 2025 Received: (at 79404) by debbugs.gnu.org; 13 Sep 2025 16:40:09 +0000 Received: from localhost ([127.0.0.1]:56421 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uxTIG-0000HK-3E for submit@debbugs.gnu.org; Sat, 13 Sep 2025 12:40:08 -0400 Received: from mail-vk1-xa31.google.com ([2607:f8b0:4864:20::a31]:56464) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uxTIC-0000DE-Of for 79404@debbugs.gnu.org; Sat, 13 Sep 2025 12:40:05 -0400 Received: by mail-vk1-xa31.google.com with SMTP id 71dfb90a1353d-54a1bef404fso1084564e0c.0 for <79404@debbugs.gnu.org>; Sat, 13 Sep 2025 09:40:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1757781598; x=1758386398; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Hf+/IkzqtuhjHH5zHcW5aO+3CJHuh9TQLBNeUkj1stY=; b=cFrwRlAAguiSTr2g3zx5b/8tzmszAGzVEubrZ7a6ES9oas9PBViYepv1l6H5c1gzM5 ITgF1NtyaUAF3H9FLI2xkOsbej+pfR9RT6smGJh6VGIoc6AxA6bB7ITqk4/CCBaLYfks /66X1jm1q2l99QkfAaoQhdLWIaPfNEB0fwkzrUrqc7bCSxg+mnPTRAZMq6JOL/aMlIDv QP5wDdsWc0ZKc7Ur0YPArUpH7ZuUnzFjks42oaYQWNmMnXnwqsx1zgY4LXzb0b/Tc9+m ozsXI5whA71JL820Fq1FJGJUJl44osB49gREbV220sTd9h+9IPOPKyEGE8GeTrqkWdh5 /mXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1757781598; x=1758386398; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Hf+/IkzqtuhjHH5zHcW5aO+3CJHuh9TQLBNeUkj1stY=; b=XcTk0gWtU6FHnGVraiTdBsDDulqee0OQXd2oV3LIZt1ns1LNDBjL8XQwHcMXvwAOzX U52xLWKfR3h+pTpXlkB2mB0n3hqhTSDDn3B9rVgj8Q1HZEGqJ21pydHlRqQxbBV/CGJC gx0hgYVIW9mWH1FFItT96FUO5UT4m5DdoDGXuHRaDPZgI4ROZ90/+fhpc9ZJFAvr78Ag mIaYDkxI6Kuc5gWTul6wZXxcIsoFUui/a+1PVsCLc4OG+3VUghS1DnJ1hzuAFjFLpwXe 61Q15StQyERSvqwZxozHL2VDwxDoo2RfRSYMqVNhxSjPwPuociluE6Qst4zrmLGg/rhq xnbw== X-Forwarded-Encrypted: i=1; AJvYcCV75TkJKDLtJtPOLotxhSzEXQhH8tbGI6k78DudvzttdI+w1jhexKdhNByYzhgEuEXqk5Px9w==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yxvg3lr5h/vxMZs8QtPS2MKKovaBd6PcEzpbAggD+WY2giy+Sx7 jZCkIURSyeKzO/vVpK/y0rBu0g6Ur3bfT9PqwXz3Emw5Si8trDN+GoIb5ma83v0crkG4sBXJ/lx lItSxTHGwAEB7iqDJpwFcYd5Gz3BsWOs= X-Gm-Gg: ASbGncso0r7grnN/d4gKqEm1JI5SOA5msB/VXIfTvQ/T98Sjg+OsReDIgW6G9lVoPyQ ANu7YRjNnvVT+QYexE2fZ+kNbqrJrpge+TUepoT9FrstyWF7JAdo/IYAl0Dw+enSQVKB/6i3DLl gHKe4fRWhFM2v2B/MVbJcIuH5gLWh0/1nPhrb1ei17O/cTuG7NIaQbDlsAHOFhROukW0dm7cmZ/ ahpvzLhD9IYMEp+yk2CCi8Z2+1pp8tgANLAKCdIvY19sj5J+f5h3Pb4mctN7h7656KsxDeuZDjT RSADrKC1iQ2okzs3cwmo+K9/qbje97oNgOe1+c+BaPyDW+hdb/cVYAb1mNYPkDskHfMWPoI5Hbe z0PdaFjiZEcVCZbMsPUZdJZQAbdxcFQ== X-Google-Smtp-Source: AGHT+IEPeLsZE06oCUfgS1ZggXcKqgoXDGTMSgEQrGSEMzyIwrrCh63CBFTnUUc8KrVNKa8zs1zMhnk0/rBLPPJDTjI= X-Received: by 2002:a05:6122:1d50:b0:537:b126:bf07 with SMTP id 71dfb90a1353d-54a16b1fc3fmr2673696e0c.1.1757781598473; Sat, 13 Sep 2025 09:39:58 -0700 (PDT) MIME-Version: 1.0 References: <7b264787-424d-4009-aaab-647a4af8c98d@lua.blog.br> <86ldmir88g.fsf@gnu.org> In-Reply-To: From: =?UTF-8?Q?St=C3=A9phane_Marks?= Date: Sat, 13 Sep 2025 12:39:47 -0400 X-Gm-Features: AS18NWBqgs2Ksqryc-9XW15vMHjWMLuvIQro_oMHQpZwjJtj4D-2VjcOkCiFv6c Message-ID: Subject: Re: bug#79404: [BUG] eldoc-last-message should be a buffer-local variable To: Stefan Monnier Content-Type: multipart/alternative; boundary="000000000000c51094063eb16bb3" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79404 Cc: Eli Zaretskii , 79404@debbugs.gnu.org, me@lua.blog.br 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 (-) --000000000000c51094063eb16bb3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Sep 13, 2025 at 12:31=E2=80=AFPM Stefan Monnier via Bug reports for= GNU Emacs, the Swiss army knife of text editors wrote: > >> So I used debug-on-variable-change to find out what was going on, and > >> found that the variable eldoc-last-message was being set to nil > >> immediately after being set. This variable is not buffer-local, and th= e > >> "(special-mode)" call in eldoc-doc-buffer-separator (called on every > >> eldoc message) would trigger "(global-eldoc-mode-enable-in-buffer)" > >> which in turn resets the global value to nil. > >> > >> This is the bug, and I think the simple solution is to make it > >> buffer-local, which fixes the issue: > >> > >> (make-variable-buffer-local 'eldoc-last-message) > [...] > > Stefan, does this sound right to you? If not, why is > > eldoc-last-message a global var? > > I don't think anyone thought very deeply about whether it should be > global or buffer-local when writing the code. The above suggest making > it buffer-local could make sense, yet the actual display of the message > is "global" in the sense that it's displayed in the echo area that is > shared by all buffers. > > So, I'm personally not sure which of global or buffer-local is The > Right Choice. The code that handles *re*displaying and *un*displaying > the eldoc info is a bit too complex for me to figure out. > > OTOH, if the var is global, I can't see why the buffer-local > `eldoc-mode` should set it to nil. Furthermore, maybe we should also > look into why `eldoc-mode` is enabled during > `eldoc-doc-buffer-separator`. E.g. it might make sense to change > `eldoc--supported-p` so it returns nil in temp buffers. > FWIW, I clear `eldoc-last-message` via `window-buffer-change-functions` to avoid cross-buffer cruft and would welcome the upgrade to a buffer-local. --000000000000c51094063eb16bb3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
= On Sat, Sep 13, 2025 at 12:31=E2=80=AFPM Stefan Monnier via Bug reports for= GNU Emacs, the Swiss army knife of text editors <bug-gnu-emacs@gnu.org> wrote:
<= div class=3D"gmail_quote gmail_quote_container">
>> So I used debug-on-variable-change to find = out what was going on, and
>> found that the variable eldoc-last-message was being set to nil >> immediately after being set. This variable is not buffer-local, an= d the
>> "(special-mode)" call in eldoc-doc-buffer-separator (cal= led on every
>> eldoc message) would trigger "(global-eldoc-mode-enable-in-bu= ffer)"
>> which in turn resets the global value to nil.
>>
>> This is the bug, and I think the simple solution is to make it >> buffer-local, which fixes the issue:
>>
>> (make-variable-buffer-local 'eldoc-last-message)
[...]
> Stefan, does this sound right to you?=C2=A0 If not, why is
> eldoc-last-message a global var?

I don't think anyone thought very deeply about whether it should be
global or buffer-local when writing the code.=C2=A0 The above suggest makin= g
it buffer-local could make sense, yet the actual display of the message
is "global" in the sense that it's displayed in the echo area= that is
shared by all buffers.

So, I'm personally not sure which of global or buffer-local is The
Right Choice.=C2=A0 The code that handles *re*displaying and *un*displaying=
the eldoc info is a bit too complex for me to figure out.

OTOH, if the var is global, I can't see why the buffer-local
`eldoc-mode` should set it to nil.=C2=A0 Furthermore, maybe we should also<= br> look into why `eldoc-mode` is enabled during
`eldoc-doc-buffer-separator`.=C2=A0 E.g. it might make sense to change
`eldoc--supported-p` so it returns nil in temp buffers.

FW= IW, I clear `eldoc-last-message` via `window-buffer-change-functions` to av= oid cross-buffer cruft and would welcome the upgrade to a buffer-local.
--000000000000c51094063eb16bb3--