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

Previous Next

Full log

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: João Távora <joaotavora <at> gmail.com>,
 50244 <at> debbugs.gnu.org, theo <at> thornhill.no, p.stephani2 <at> gmail.com
Subject: Re: bug#50244: 28.0.50; Support project-wide diagnostics reports in
 flymake.el
Date: Mon, 30 Aug 2021 02:27:52 +0300

On 29.08.2021 03:53, João Távora wrote:
> * In what new UI parts is the augmented information to be useful?
> 
>    Currently, I see only one place, the diagnostic listing buffer
>    obtained by M-x flymake-show-diagnostics-buffer.  That buffer is
>    usually associated with only one source buffer
>    (flymake--diagnostics-buffer-source).  Now it should start listing all
>    the diagnostics for buffers or files known to belong to the same
>    project, using 'project.el' functionality for that.

From what I know of this feature is usually organized, we have two 
possible kinds of sources of errors:

1. Per buffer, which is currently being edited.

2. For the whole project, where the notion of project is defined by the 
tool which produces the said list of errors. With that approach, when 
you fix an error which triggered some cascading errors in other files, 
you can see those other errors fixed too.

Is the idea to build a list of "project errors" using sources of type 1? 
That would seem inefficient, though I suppose some people might want 
this too.

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?

Previous Next

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