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 17.09.2021 02:36, João Távora wrote:
> Ultimately, those answers depend on the kinds of diagnostics functions
> people are going to write. LSP diagnostics, IIUC, can work with any of
> the options I described.

Yes, but currently they work in one specific way.  The new Flymake is
compatible to that way (and all the other backends way).  That's so that
"people" _don't_ have to write new backends or modify the existing ones,
to make at least partial use of new Flymake functionality, M-x
flymake-show-project-diagnostics

> But do they? Know nothing about it?

I think so, yes.  The Flymake backends that live in the Emacs source
tree are examples, and so are many that live in Elpa.  They are all
concerned with the buffer.

> Consider where "list diagnostics" can come from. If those span not
> just the current file and maybe a couple of files which it include<>-s
> (in the case of C/C++), they have to span a whole set of files, which
> often corresponds to the notion of the project, as understood by some
> tool or configuration file. So the knowledge about the project bounds
> seems necessary to even be able to generate the global diagnostics.

Yes, I see what you mean.  Here, again, is an attempt to explain what
how it works.  That's up to the backend: if it knows these things, and
if they are useful to its work, fine.  But they aren't required and
should not be required by Flymake.  The flymake-cc backend uses a
Makefile for example.  Is that "the project"?  Sometimes it is,
sometimes not.  Flymake, the framework, doesn't care.  It cares about
files in a file system.  Backends tell it about problems in the current
buffer and the associated files.  Now they are able to tell it about
other related files, within any criteria of relation they see fit.

> "Server sends" is an event source. It doesn't react to you calling
> diagnostic functions, it only vaguely reacts to user actions, which
> then get translated into notifications for the server, and those,
> asynchronously, result in diagnostic events.
>
> Events one could subscribe to.

I see.  There's nothing in LSP that tells me that model is correct, but
nothing telling me it's wrong either.

> It seems more like a technical decision rather than definition.

It's both.  Making working definitions is technical work.  I define
things so that I can operate on them comfortably and succintly.  I could
have defined "list only diagnostics" it in terms of Aunt Mary's cake,
but it would probably make for a lot more code to write, unfriendly
documentation API, etc.

It's just like you devising the definition of "subscription".  It's a
technical decision.  It's one yet to see light of day, but it's a
decision nonetheless.

> To put it another way: suppose each of
> flymake-global-diagnostic-functions returns a list of values of
> diagnostics. Would those be generally suitable for highlighting files?

I don't know!  I don't know that flymake-global-diagnostic-functions
does, because you haven't written it or described it suitably.  It's
very hard to be your imagination's interpreter.  You should type these
things in Elisp and then use the Elisp interpreter/compiler.

>> The _assumption_ is rather that when their files are
>> eventually visited by Emacs and flymake-mode, we _assume_ that the
>> regular ensuing syntax checks deriving from the visit and or from edits
>> to those already brings in diagnostics.
>
> If we're talking about LSP-based diagnostics, would those then come
> from some different source? Or would that just be the same
> information, repackaged through the classic hook?

If I understand you question correctly: the latter, but only sometimes.
Servers can provide new fresh info when you visit files, so it wouldn't
be the "same information".  But as for the "classic hook" being used for
that: yes.

>> And that is a good assumption,
>> if there's a traditional flymake-diagnostic-function capable of handling
>> that file, which there normally is.  This requires no change to that
>> existing part of the backend, which was desirable.
>
> I'm thinking that if LSP servers only provide "global" diagnostics,
> they could simply provide all their diagnostics through the new
> abnormal hook. Then changing the "existing part of the backend" might
> likewise be unnecessary.

Maybe that works. Maybe not.  To solve what problem? I don't know.  You
don't seem to describe this problem, am I incapable of devining it.  But
if you can see and you can program it, maybe it becomes obvious then.

>> where many "thinkos" that are only natural when imagining vapourware
>> solutions are already sorted, because reality sorted them for you.  It
>> happens a lot with me: imagining this and having to discard them once I
>> "hit the metal".
> That is entirely possible. I just wanted to touch on this discussion
> because it relates to a package I maintain. I'm not currently an LSP
> user, and other things require my attention.

I think, without wanting to overly judge your stance, that that is more
than slightly unproductive.  (1) I solve a problem which uses "your"
project.el library and its existing API (requests no changes to it).
(2) You argue long-windedly that there is a much better solution to
solve the problem, and presumably some other problems.  (3) Finally say
that you don't have direct contact and experience with the base matter,
and that you don't have time to develop your ideas formally.  I don't
even know if you've tried the solution that I've presented and
encoutered some difficulty.

I have to say that it feels a bit unfair for me who has sit down and
spent actual hours of my life working on something real.  This pattern
repeats more or less in many other parts of Emacs that I usually work
on.  I take Eli's frequent advice: "sit down and do the work".  It's
excellent advice.  Then my ideas are more convincing.  Others and I are
more happy and less exhausted to debate them.  I am going to snip the
rest of the conversation, which is repeating the same points.  I have
nothing to add.

Best regards,
João