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 21:03, João Távora wrote:
>> The only outstanding issue preventing me from landing this in main is
>> that I need to bump project.el's version so that the new
>> `project-buffers` API generic function becomes officially available to
>> the new bumped flymake.el version.  Dmitry is it OK for me to do so?
>
> Yes, please go ahead. All the latest additions seem stable.

Thanks.

> Like mentioned previously, I think using project.el for this is
> probably not ideal (rather, the diagnostic source can decide which
> diagnostics belong to the current default-directory),

Yes, it can, and it does (have you read the change?) In fact the
diagnostic source knows nothing about projects.  But at a certain point,
someone will have to know about "projects", because the request is not
for "default-directory-wide diagnostics", it's for project-wide
diagnostics.  I don't know what better library to use for segregating
diagnostics into projects other than project.el: it works quite well, to
be frank.

That said, if even that bothers you, the uses of project.el in
flymake.el are minimal and are the simplest part of this whole job.  If
you or someone can get rid of them and somehow keep a coherent M-x
flymake-show-project-diagnostics command, it's not unthinkable. Maybe
you'd prefer it renamed to M-x flymake-show-aggregated-diagnostics to
get the "project" word out of there.  But frankly I think the current
command name and implementation is really spot-on what was requested
here.  At least it seems to make sense to Theodor and me as a user.

Indeed, I even thought that flymake-show-project-diagnostics could go
into the 'C-x p' map.  But users can do that easily if they want to, so
I won't argue for that now.

João