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

[Theodor Thornhill]

On 30 August 2021 01:27:52 CEST, Dmitry Gutov <dgutov@yandex.ru> wrote:
>On 29.08.2021 03:53, João Távora wrote:
>> * In what new UI parts is the augmented information to be useful?
>> 
>>    Currently, I see only one place, the diagnostic listing buffer
>>    obtained by M-x flymake-show-diagnostics-buffer.  That buffer is
>>    usually associated with only one source buffer
>>    (flymake--diagnostics-buffer-source).  Now it should start listing all
>>    the diagnostics for buffers or files known to belong to the same
>>    project, using 'project.el' functionality for that.
>
> From what I know of this feature is usually organized, we have two 
>possible kinds of sources of errors:
>
>1. Per buffer, which is currently being edited.
>

Yes, and some LSP servers may only deliver this. Typically, though, servers 
send to gravitate towards 2 these days


>2. For the whole project, where the notion of project is defined by the 
>tool which produces the said list of errors. With that approach, when 
>you fix an error which triggered some cascading errors in other files, 
>you can see those other errors fixed too.
>
>Is the idea to build a list of "project errors" using sources of type 1? 
>That would seem inefficient, though I suppose some people might want 
>this too.
>

In the case of elm-language-server, with which I use the most along OmniSharp 
and F#, all of them report all diags in all files known to the project (as 
defined by LSP) on the first load, then all potential diags across all files 
per edit afterwards. This case get super chatty very fast, but since it always 
flushes everything one can at least rely on what you get. The pr I made works 
pretty well performance wise in a medium large repo (~70k loc elm), at least 
considering it isn't very polished, awaiting this discussion.


>But I thought the original discussion was about errors from sources of 
>type 2? Then the whole list provided by the source already belongs to 
>the same project (how the LSP server understands it, if we use the LSP 
>example).
>
>Is there a need for further filtering?

Not in the case of LSP, no. 

In addition, the structure the error buffer uses would be nice to expose so 
that one can build utility functions like the ones in the pr.

Theo