GNU bug report logs - #79404
[BUG] eldoc-last-message should be a buffer-local variable

Previous Next

To reply to this bug, email your comments to 79404 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Lua Viana Reis <me <at> lua.blog.br>
To: bug-gnu-emacs <at> gnu.org
Subject: [BUG] eldoc-last-message should be a buffer-local variable
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).


kind regards,

Lua

Message #8 received at 79404 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: me <at> lua.blog.br, Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 79404 <at> debbugs.gnu.org
Subject: Re: bug#79404: [BUG] eldoc-last-message should be a buffer-local
 variable
Date: Sat, 13 Sep 2025 12:51:11 +0300

> From: Lua Viana Reis <me <at> lua.blog.br>
> 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?

Message #11 received at 79404 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: me <at> lua.blog.br, 79404 <at> debbugs.gnu.org
Subject: Re: bug#79404: [BUG] eldoc-last-message should be a buffer-local
 variable
Date: Sat, 13 Sep 2025 12:30:09 -0400

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

Message #14 received at 79404 <at> debbugs.gnu.org (full text, mbox):

From: Stéphane Marks <shipmints <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 79404 <at> debbugs.gnu.org, me <at> lua.blog.br
Subject: Re: bug#79404: [BUG] eldoc-last-message should be a buffer-local
 variable
Date: Sat, 13 Sep 2025 12:39:47 -0400

[Message part 1 (text/plain, inline)]

On Sat, Sep 13, 2025 at 12:31 PM Stefan Monnier via Bug reports for GNU
Emacs, the Swiss army knife of text editors <bug-gnu-emacs <at> gnu.org> 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 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.
>

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.

[Message part 2 (text/html, inline)]

Previous Next

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