GNU bug report logs - #78459
flymake related locations (ancillary diagnostics)

Previous Next

Full log

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

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: Emacs Bug Report <bug-gnu-emacs <at> gnu.org>
Cc: Spencer Baugh <sbaugh <at> janestreet.com>
Subject: flymake related locations (ancillary diagnostics)
Date: Fri, 16 May 2025 17:42:01 +0200

Flymake does not seem to have a way to attach related locations to a diagnostic. These are 'info' or 'note'-level messages that follow an error or warning and point out locations of interest, such as definitions or conflicting code. Current, they become independent diagnostics with no connection to the main message.

This is unfortunate, because:

* As interfaces typically sort diagnostics by location, these messages often become detached from their context. The text is usually not meant to be read in isolation, only as part of a single warning or error. Example:

myprog.q:98: error: variable 'zurk' is assigned an integer here
myprog.q:12: note: declared with type string here

When messages are sorted these come in the wrong order, possibly separated with several unrelated messages in-between.

* Since these info-messages make little sense on their own, it might be useful to hide them (from the table of diagnostics and in-code annotations) until the user selects their parent warning or error. That also cuts down on colliding squiggly underlines or whatever is used to mark locations in the code buffer.

* The LSP protocol has explicit provisions for ancillary messages ('relatedInformation') but Flymake cannot make use of it without some additional hacks.

There are various ways to fix this. For example:

A. Keep a list of auxiliary diagnostics in the diagnostic object. This seems easiest to work with and what I would suggest. It also corresponds directly to LSP, if I understand it right.

B. Tag all diagnostics that belong together in a group. This is what Flycheck does and would make interoperability easier, but doesn't say which diagnostic is the main one and in what order the auxiliary diagnostics should come.

What do you think?

Previous Next

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