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

Previous Next

Package: emacs;

Reported by: João Távora <joaotavora <at> gmail.com>

Date: Sun, 29 Aug 2021 00:54:02 UTC

Severity: wishlist

Found in version 28.0.50

Done: João Távora <joaotavora <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: João Távora <joaotavora <at> gmail.com>
Cc: 50244 <at> debbugs.gnu.org, Philipp Stephani <p.stephani2 <at> gmail.com>, Theodor Thornhill <theo <at> thornhill.no>
Subject: bug#50244: 28.0.50; Support project-wide diagnostics reports in flymake.el
Date: Tue, 14 Sep 2021 02:35:51 +0300
On 13.09.2021 23:53, João Távora wrote:

>> 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 a backend reports diagnostics through flymake-list-only-diagnostics, 
woudln't one of those values be overridden when two backends offer reports?

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

I was thinking of a way to get by with only two types: "domestic" and 
"foreign", without adding a third one. No code, sorry.

> In the meantime, please say if version-bumping project.el is OK.  That
> is the only thing holding up the merge.

Already replied to that on 13.09.2021, 23:11: yes, sure, go ahead.




This bug report was last modified 3 years and 266 days ago.

Previous Next


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