I can look at the options here at a later point. I haven't had much time to think about the future, given that I've assumed the Flycheck maintenance relatively soon. My short-term focus is harvesting some low-hanging fruit (like the package inclusion on NonGNU ELPA).

Compiling a reasonable long-term vision for the future (including some form of built-in interop with Flymake) will take some time and I think it'd better to discuss this separately.

> On 21/02/2024 23:19, Stefan Kangas wrote:
> 
> > Another thing is that we could use a good built-in macro to define
> > flymake backends.
> > 
> > Perhaps Steve Purcell (added to CC) could be convinced to contribute his
> > excellent flymake-flycheck[2] and flymake-easy[3] packages to core?
> > This would kill two (or more) birds with one stone, and also remove some
> > of the gripes that some users have with flymake.
> 
> There doesn't seem much point in having flymake-flycheck in the core 
> when flycheck is still required to use most of its backends (they're 
> part of the package). It also depends on flycheck at runtime anyway.
> 
> flymake-easy has another problem: IIUC it hasn't been updated for 10 
> years, and as such only uses the obsolete Flymake protocol (one we keep 
> in flymake-proc.el for compatibility). It also employs defadvice.
> 
> Back to flymake-flycheck, I wonder if it would be a better idea to have 
> it as part of the flycheck package itself (fewer things to install and 
> enable separately). But then it's not obvious at which point the 
> checkers should be made available to flymake. If that happens when 
> flycheck-mode is enabled, that would be too late: at that point the user 
> has seemingly indicated that they want to use flycheck as UI as well.
> 
> > [2]  https://github.com/purcell/flymake-flycheck
> > 
> > [3]  https://github.com/purcell/flymake-easy
> 
> 
>