GNU bug report logs - #50244
28.0.50; Support project-wide diagnostics reports in flymake.el

Previous Next

Full log

Message #44 received at 50244 <at> debbugs.gnu.org (full text, mbox):

From: João Távora <joaotavora <at> gmail.com>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 50244 <at> debbugs.gnu.org, Philipp Stephani <p.stephani2 <at> gmail.com>,
 Theodor Thornhill <theo <at> thornhill.no>
Subject: Re: bug#50244: 28.0.50; Support project-wide diagnostics reports in
 flymake.el
Date: Mon, 13 Sep 2021 21:53:20 +0100

Dmitry Gutov <dgutov <at> 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 <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.