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