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 09:48, João Távora wrote:
>> On Mon, Sep 13, 2021 at 1:08 AM Dmitry Gutov<dgutov@yandex.ru>  wrote:
>> 
>>> Or maybe you will have unique "show diagnostics" buffers for every
>>> project, to be invoked manually?
>> This.  But it doesn't seem impossible to make a global diagnostics
>> buffer for every project one has open.
>
> 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 global diagnostics are only reported to a particular buffer,
> perhaps we could do without the global variable by tying refreshes to
> a callback.

I don't fully understand what you're suggesting, because I don't
understand your working concepts. In the new manual section "Foreign and
list-only diagnostics", you can read that the new API allows a form of
reporting diagnostics for other buffers/files in a way that is tied to a
callback.  Maybe that that what you mean?

Anyway, for the specific of case of Eglot/LSP -- which reports
neighboring diagnostics _sporadically_ (i.e. not systematically) -- the
"list only" diagnostics seem more suitable.  For the purposes that I
envisioned (only listing, as the name implies) a global variable also
seems suitable.

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.

In the meantime, please say if version-bumping project.el is OK.  That
is the only thing holding up the merge.

João