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

Previous Next

Full log

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

From: João Távora <joaotavora <at> gmail.com>
To: 50244 <at> debbugs.gnu.org, p.stephani2 <at> gmail.com, theo <at> thornhill.no
Cc: Dmitry Gutov <dgutov <at> yandex.ru>
Subject: 28.0.50; Support project-wide diagnostics reports in flymake.el
Date: Sat, 11 Sep 2021 02:08:42 +0100

> The idea is simply to not discard what I called "piggy-backed" or
> "sideband" information about diagnostics in other places, which will
> frequently originate from the aforementioned per-buffer requests.

Hi, I've been working on this quite intensively and am finally
approaching sometehing stable.  You may check my ongoing work in the
branch scratch/bug-50244.

As expected, I abandoned/reformulated much of my original design ideas
many times as I faced new edge cases.  It was quite challenging to
support the main new command, M-x flymake-show-project-diagnostics, when
e.g. .c files referencing problems in .h files are killed and vice-versa
in various orders.

If you're interested in understanding how it works, the main entry point
are the additions to the existing documentation, the manual that lives
in flymake.texi and the docstrings.

As is explained in the manual, there are two types of Flymake
diagnostics: (1) the usual diagnostics for the current buffer, and (2)
so-called non-domestic diagnostics, which might be "foreign" diagnostics
or "list-only" diagnostics.  The difference is explained in the new
manual section "Foreign and list-only diagnostics".  How does this
matter in practice?

- For the examples of .c/.h files (and the flymake-cc backend, which I
  also updated), "foreign diagnostics" are used.

- For LSP, likely "list-only diagnostics" should be used.  So basically
  Eglot will soon learn to tell Flymake about the "list-only
  diagnostics" that it receives from some LSP servers.  Once that is
  done, M-x flymake-show-project-diagnostics should ideally do most
  things that Theodor wants.

Even though the protocol is already designed, flymake.el is still
missing the implementation of "list-only diagnostics".  It should, in
principle, be much simpler than the "foreign diagnostics", which as I
hinted above are much harder to keep up to date.

I hope you can have a look,
Thank you,
João

Previous Next

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