GNU bug report logs - #60040
29.0.50; flymake manual should document language support

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 60040 in the body.
You can then email your comments to 60040 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; flymake manual should document language support
Date: Tue, 13 Dec 2022 10:20:57 -0800

Severity: wishlist

Please consider adding a new chapter in (info "(flymake) Top") that
documents all built-in flymake support, and how to enable them
automatically.

I think such a chapter could also document the languages known to be
supported in packages on GNU ELPA and NonGNU ELPA.

It is currently hard to know which modes support flymake-mode, without
testing it in each mode.  For example, I don't see that
`flymake-texinfo' or `perl-flymake' are currently documented anywhere
outside of their docstrings.

You can use `M-x apropos-function RET flymake RET', of course, but that
requires users to know implementation details of flymake (how to
implement a backend), as well as know that the functions must be loaded
(or autoloaded) for that to work, and finally you need to filter out a
lot of internal flymake implementation details and similar.

Note in particular that this is useful whether or not it is already
documented in the documentation for the respective packages (which it
most often is not, AFAICT).

See also:
https://www.flycheck.org/en/29/languages.html#flycheck-languages

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

From: João Távora <joaotavora <at> gmail.com>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: 60040 <at> debbugs.gnu.org
Subject: Re: bug#60040: 29.0.50;
 flymake manual should document language support
Date: Tue, 13 Dec 2022 18:28:26 +0000

[Message part 1 (text/plain, inline)]

I don't think it's very useful to maintain this list by hand.

It's a duplication of information, and such things always
invariably end up outdated and useless.

I think it's more useful to write a program that collects
this information automatically.  The fact that you're
finding this task boring and repetitive is enough of a hint
that such a program can be written. I'd say start with
a dolist of known major modes and a temp buffer,
set the buffer in the major mode and check if there's
a buffer-local value of flymake-diagnostic-backends.

Also, given the advent of LSP, I think the trend is
for Flymake to be chiefly useful when connected
with something like Eglot.  Not exclusively so, but
rather predominantly so.

João

[Message part 2 (text/html, inline)]

Message #13 received at 60040-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: João Távora <joaotavora <at> gmail.com>
Cc: 60040-done <at> debbugs.gnu.org
Subject: Re: bug#60040: 29.0.50;
 flymake manual should document language support
Date: Sun, 10 Sep 2023 12:11:55 -0700

João Távora <joaotavora <at> gmail.com> writes:

> Also, given the advent of LSP, I think the trend is
> for Flymake to be chiefly useful when connected
> with something like Eglot.  Not exclusively so, but
> rather predominantly so.

I think you're completely right here, but this should be documented
prominently.  So I've installed commit 9549612c53d on emacs-29.

Feel free to tweak, extend, rewrite, or improve it.  It's very brief as
is, but I didn't know what more to say.  Unfortunately, there's not much
need for a lot of documentation when things just work.  ;-)

On a separate note, perhaps this note doesn't need to be on the first
page in Emacs 30.1:

       Historically, Flymake used to accept diagnostics from a single
    backend.  Although obsolete, it is still functional.  To learn how
    to use and customize it, *note The legacy Proc backend::.

Previous Next

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