Moving from {flycheck, :checkers syntax} to Flymake

[jeetelongname]

Short post on moving from flycheck (the underpinning of the :checkers syntax module) to flymake

update

As of now flymake is part of the :checkers syntax module. To enable it you need to add the +flymake flag to the module. Most of these check boxes have been filled in as of now and its pretty seamless. Ill update the list below with what is done.

back to the post

I guess the first question is why? well

• its built in
• its the way the community is moving
• its probably going to be what doom moves to in time
• its less problematic

in any case doom already does a lot of the heavy lifiting for us, falling back to flymake when nothing else is there in a lot of use cases.

that being said there are a few things I have noticed a few things that need to be added.

Starting Flymake automatically

first off flymake does not start on its own, this is easy to fix though by adding it to the prog-mode hook like so

(add-hook! prog-mode #'flymake-mode)

this is mostly fine to do as back ends fail (mostly) silently if they do not provide an adequate response.

If you are also using lsp telling it to use flymake specifically is also good (it automatically defaults to flycheck if its found even if its just as a dependency for another package cough tide cough)

(after! lsp-mode
  (setq lsp-diagnostics-provider :flymake))

And for the most part this is it. If all you need is checking and all you use is lsp, then you are done, its not one to one but you get all the main things.

• diagnostics
• jumping to errors
• (for lack of a better term) squiggles

A lot of this is provided by the leagacy proc backend which you can read about in the manual

Adding your own back ends

if you have a back end (for example maybe flymake-vale?) then all you would need to do is add the checker to the flymake-diagnostic-functions hook. Though in many cases packages that provide checkers provide load functions that you can then add to a major-mode hook locally, this has the distinct advantage in the fact that checkers are not used globally which is both faster and cleaner

and example would be

(add-hook! MAJOR-MODE #'flymake-vale-load)

which is equivalent too

(add-hook! MAJOR-MODE 
  (defun flymake-vale-load ()
    (add-hook 'flymake-diagnostic-functions #'flymake-vale--checker nil t)))

To be continued

I will add to this as I find more (there is not a lot to find tbh, its pretty flawless) but some problems I am facing

• getting flymake vale to work Turns out reading the docs is helpful. (you need a .vale.ini file for vale to know how to lint the project)
• getting feedback in the modeline: feedback does show up but its silent when not checking, a better default could be in place.
• getting some more feature parity with the current module, (my usecase is light, if there is something your missing, do mention it!)
• adding in a +emacs-lisp-reduce-flycheck-errors-in-emacs-config-h alternative for flymake (this i am working on) This was the big one and is now part of the +emacs-lisp-non-package-mode

This may end up going towards working on flymake support in doom but we shall see how the cookie crumbles,

some resources to help

• the manual, especially helpful if your curious about writing your own backends
• flymake-vale, an example of a backend if you are curious
• flymake-collection, a set of abstractions and back ends for use.

[tecosaur]

GitHub - purcell/flymake-flycheck: Use any Emacs flycheck checker as a flymake backend is also notable.

[jeetelongname]

there is also GitHub - purcell/flymake-easy: Helpers for easily building Emacs flymake checkers if we are on the topic of purcell packages but yeah that does look pretty handy, I should prob mess with it to see how well it works (I would assume fine for the most part)

[gagbo]

So, I’ve been experimenting in my config with flymake for a bit, and the list of packages that might be interesting is a little longer, especially if you want to replicate some part of the UX that Flycheck proposes.

The main one I added is flymake-popon that uses the eponymous popon package to give hover information about a diagnostic in a small popup, both in TUI and GUI. To be totally honest I don’t like that by default it doesn’t seem to have a border around the window, but that’s probably impossible in TUI at least.

At least that post reminded me that I wanted to create an account and post an issue on the repo to find this out (https://codeberg.org/akib/emacs-popon/issues/8)

[jeetelongname]

Nice! I think that would probably be enough to start thinking about updating the syntax module (I aint doing that now but a nice amount of ground work is there)

Ill start playing with it.

Edit: I have been playing with it and I like it quite a bit. Its simple.

there is also GitHub - junyi-hou/flymake-childframe: childframe frontend for flymake which should bring around all three packages which basically makes it comparable. the problem with that is that it is kinda barebones in terms of package standards, I would not include it in doom but its worith mentioning.