bug#50244: 28.0.50; Support project-wide diagnostics reports in flymake.el

[João Távora]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 13.09.2021 23:53, João Távora wrote:
>
>>> Anyway, I asked about this because because the use of global variable
>>> (flymake-list-only-diagnostics) seems like it would make supporting
>>> multiple projects at the same time more difficult.
>> I can't guess what you are hinting at, sorry.  You can call M-x
>> flymake-show-project-diagnostics in two or more projects, of course, and
>> you'll get separate listings.  I don't know if that counts as
>> "supporting multiple projects at the same time".
>
> If a backend reports diagnostics through
> flymake-list-only-diagnostics, woudln't one of those values be
> overridden when two backends offer reports?

No.  The variable is an alist (could be another type of map), so
backends only add and remove entries about the files they know about.
The "and remove" bit is still under study.  For now I've chosen to leave
the "remove" responsibility to backends, but I've experimented with
schemes in which flymake.el does the removal strategically.  I'll
re-study that.  Also, perhaps you're being confused by the variable's
docstring, which is not as good as its entry in the manual.  I'll try to
clarify later.

>> Again, I don't understand your suggestion, but if you can propose it in
>> the form of code it would be much better, since there would be no
>> ambiguity.  A word of caution though: making these things work correctly
>> in tandem with domestic diagnostics, new file visits and buffer killings
>> was relatively hard.  I tried many different approaches and settled on
>> these two ("foreign" and "list-only").  Of course if you can clearly
>> describe a use case where they are unsuitable, a third style may be
>> invented.  But I would first exhaust the possibilities in these two.
>
> I was thinking of a way to get by with only two types: "domestic" and
> "foreign", without adding a third one.

Those two already exist.

"foreign" diagnostics belong to a given source buffer's flymake-mode but
don't target the source, rather other buffers or unvisited files.  Like
"domestic" ones they are systematically updated as the source is
updated.

They are well suited for flymake-cc and strongly typed languages where a
compilation unit is created from the strongly coupled aggregation of
many files and checked as a whole.  As you know if you've ever done
C/C++ the locus of a syntactic mistake is usually spread out through one
.cpp file and multiple .h files.

LSP servers don't systematically provide this info -- as far as I have
witnessed, so Eglot can't do much with them.  If I'm wrong, then Eglot
will also use this functionality.  The LSP protocol doesn't forbid it.
Maybe I'll approach clangd developers with the idea.

Currently, what _can_ be seen in the logs is an LSP server shooting out
a once-only batch of diagnostics for the whole project of unvisited
files when the server is started.  That is better suited to "list-only"
diagnostics.  Why "list only"?  Because once the actual file is visited,
it is assumed that flymake-mode will kick in there proper and be able to
request fresh, domestic, highlightable, diagnostics to override the
initial "list only" that came in the starting batch.

> No code, sorry.

If you want a new abnormal hook (as you seemed to propose), you have to
say, at least in some kind of pseudo-code, _when_ that hook is going to
be activated.  Maybe by doing that I could start to see the problem that
it is solving (I also don't see that).

João