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