GNU bug report logs - #78862
31.0.50; Eglot couldn't refresh Flymake diagnostics on Rust project

Previous Next

Full log

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

From: João Távora <joaotavora <at> gmail.com>
To: matthewktromp <at> gmail.com
Cc: Spencer Baugh <sbaugh <at> janestreet.com>, Eason Huang <aqua0210 <at> foxmail.com>,
 78862 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#78862: 31.0.50; Eglot couldn't refresh Flymake diagnostics on
 Rust project
Date: Thu, 24 Jul 2025 01:40:42 +0100

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

On Wed, Jul 23, 2025 at 5:53 PM <matthewktromp <at> gmail.com> wrote:
>
> I ran a git bisect and found that commit
> 0ff82eb48725e15bb87a75d4f937b75c2482c59b appears to be the first commit
> to exhibit this behavior, although I'm not entirely sure why.

That would probably be the change that I called:

     (flymake-mode): Don't nuke overlays here.

> My understanding is this: every time flymake recomputes diagnostics
> (e.g. on file save), it queries all of the backends in
> `flymake-diagnostic-functions' to get new diagnostics.  When it gets new
> diagnostics from a backend, it goes through the buffer, removes all the
> existing diagnostics produced by that backend, and inserts the new
> diagnostics that it just got.
>
> Before running eglot, `flymake-diagnostic-functions' is equal to
> (rust-ts-flymake t) (I'm not sure what the significance of the t is).

The t means "this is a local value of the hook, but run the functions
in the global hook in this position".  That's because
flymake-diagnostic-functions is a hook variable (execute with run-hooks).

> When you start eglot, this line in `eglot--managed-mode' replaces the
>
> value of flymake-diagnostic-functions:
> (eglot--setq-saving flymake-diagnostic-functions '(eglot-flymake-backend))
> Then it has flymake refresh its diagnostics.  Since rust-ts-flymake is
> no longer in flymake-diagnostic-functions, flymake doesn't request any
> new diagnostics from it.

Well done! Thanks for the diagnosis.  I understand it now.

> The attached patch fixes this by adding code to flymake-start which goes
> through flymake--state and removes all diagnostics and their overlays
> from any backend which is no longer in flymake-diagnostic-functions.

This patch isn't bad, though I think it's missing a
`flymake--clear-foreign-diags`
for completeness.  However, the point -- at least the point in time --
where
flymake-diagnostic-functions is hacked by Eglot seems like a better place
to do the cleanup.  I've never used them, but I think we have so-called
variable
watchers in recent Emacsen.  They probably get the before and after values
of a touched variable.  I wonder if using one of these things for
flymake-diagnostic-functions wouldn't be cleaner than adding
this "paranoia" to all invocations of flymake-start.

Another option is to tell clients of this particular Flymake entry point,
like  Eglot, that messing with flymake-diagnostic-functions while
Flymake is on involves shutting it down and up again, or calling
some "cleanup" entry point.

As a workaround, users affected by this can probably add 'flymake' to
'eglot-stay-out-of' and _keep_ both Flymake backends

João

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