On Wed, Jul 23, 2025 at 5:53 PM <matthewktromp@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