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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: João Távora <joaotavora <at> gmail.com>
Cc: sbaugh <at> janestreet.com, aqua0210 <at> foxmail.com, 78862 <at> debbugs.gnu.org, matthewktromp <at> gmail.com
Subject: bug#78862: 31.0.50; Eglot couldn't refresh Flymake diagnostics on Rust project
Date: Sat, 02 Aug 2025 17:01:05 +0300

Ping! Can we make some further progress with this issue?

> From: João Távora <joaotavora <at> gmail.com>
> Date: Thu, 24 Jul 2025 01:40:42 +0100
> Cc: Eason Huang <aqua0210 <at> foxmail.com>, Eli Zaretskii <eliz <at> gnu.org>, 
> 	Spencer Baugh <sbaugh <at> janestreet.com>, 78862 <at> debbugs.gnu.org
> 
> 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

Previous Next

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