GNU bug report logs - #78459
flymake related locations (ancillary diagnostics)

Previous Next

Full log

View this message in rfc822 format

From: João Távora <joaotavora <at> gmail.com>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: Mattias Engdegård <mattias.engdegard <at> gmail.com>, 78459 <at> debbugs.gnu.org
Subject: bug#78459: flymake related locations (ancillary diagnostics)
Date: Tue, 20 May 2025 20:24:10 +0100

On Tue, May 20, 2025 at 7:56 PM Spencer Baugh <sbaugh <at> janestreet.com> wrote:

Hi Spencer, thanks for adding me. 

> > * As interfaces typically sort diagnostics by location, these
> > messages often become detached from their context. The text is
> > usually not meant to be read in isolation, only as part of a single
> > warning or error.  * Since these info-messages make little sense on
> > their own, it might be useful to hide them

I more or less sympathize with this change request, as I use a lot of
C/C++ and there are these types of diagnostics.  There's a specific case
where they bother me and it wasn't listed here.

It's when multiple errors hark back to the same misnamed variable/symbol
and there is an immense repetition of the green "note:" diagnostics such
as here:

int fo{};
    ├──────────────────────── 'fo' declared here
    ├────────────────────── 'fo' declared here
    └──────────────────── 'fo' declared here
void f1() { foo = 42; }
            └──────────────── Use of undeclared identifier 'foo'; did you mean 'fo'? 
void f2() { foo = 43; }
            └──────────────── Use of undeclared identifier 'foo'; did you mean 'fo'?
void f3() { foo = 44; }
            └──────────────── Use of undeclared identifier 'foo'; did you mean 'fo'?


However, not only doesn't this bother me that much, but it's really not
clear to me what could be done with this ancillary information.

Similarly, you succinctly describe two cases, but what does "selecting a
diagnostic" even mean?  I don't understand.

Let's forget the implementation for a while and think exactly what one
would want to the UI of:

1) the Flymake diagnostics buffer 
2) the in-code annotations (including the overlays created when flymake-show-diagnostics-at-end-of-line is non-nil).
3) the counters in the mode-line
4) the ElDoc outlet

...that could somehow take into account these groups or relations
between diagnostics.

Currently, except in rare cases, diagnostics are not interactive (in
those cases the UI is given by an external library, such as Eglot).
There is also no way to "filter" them unless a special UI outside of
Flymake is used.

Only after cleanly describing this UI should we worry about other
stuff. And yes, there is a plenty to worry about, such as what to do if
a backend tells Flymake to replace diagnostics in a region that link to
or are linked by a diagnostic outside that region.  And what to do if
linked diagnostics are in different loci (a locus may not be a buffer).

João

Previous Next

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