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

["João Távora" <joaotavora@gmail.com>]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 29.08.2021 03:53, João Távora wrote:

> Is the idea to build a list of "project errors" using sources of type
> 1?

No.  The current idea is, in short, to not have Flymake discard
information of what you call "type 2" (and which I described in my
email).  As I wrote there, examples of discarded information can be
project-wide diagnostics sent by LSP servers on server startup, among
others.  For a non-LSP example, consider references to errors .c in
files when editing .h files.

In other words, this is a "best effort service" by flymake.el: the topic
of this bug#50244 is _not_ to augment flymake.el to somehow change the
way that diagnostics are requested so that somehow more of what you call
"type 2" can be gathered.  To be clear, after this feature is done,
diagnosics are _still_ requested per-buffer. Eminently, on buffer
changes and less frequently on occasions like visiting a file.

The idea is simply to not discard what I called "piggy-backed" or
"sideband" information about diagnostics in other places, which will
frequently originate from the aforementioned per-buffer requests.

> 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?

Yes, and even in the .c/.h non-LSP example that is true.  But depending
on what data-structures are employed (I'm still thinking about them),
utilizing project.el's basic features for composing M-x
flymake-diagnostics-buffer _may_ come in handy.  This is pretty
secondary at this point, in my view at least.  I first want to have the
information recorded and correctly updated in Elisp memory.  Then I will
think about how to present it to the user.

João