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

Previous Next

Full log

View this message in rfc822 format

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

On 30 August 2021 01:27:52 CEST, Dmitry Gutov <dgutov <at> yandex.ru> wrote:
>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.
>

Yes, and some LSP servers may only deliver this. Typically, though, servers send to gravitate towards 2 these days


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

In the case of elm-language-server, with which I use the most along OmniSharp and F#, all of them report all diags in all files known to the project (as defined by LSP) on the first load, then all potential diags across all files per edit afterwards. This case get super chatty very fast, but since it always flushes everything one can at least rely on what you get. The pr I made works pretty well performance wise in a medium large repo (~70k loc elm), at least considering it isn't very polished, awaiting this discussion.


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

Not in the case of LSP, no. 

In addition, the structure the error buffer uses would be nice to expose so that one can build utility functions like the ones in the pr.

Theo

Previous Next

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