Subject: flymake related locations (ancillary diagnostics)

From: Mattias Engdegård <[email-masked]>
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?