> One idea would be to change flymake so that it can support flycheck
> backends natively, without needing any third-party packages.  That would
> already go a long way to decrease the differences between the two
> packages.  I'd definitely encourage work on that.
> 
> 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.

Pretty reasonable ideas IMO. 

> Yup.  Historical kerfuffles notwithstanding, more collaboration and
> interoperability can only help, whether or not that means that the
> friendly competition[1] between flymake and flycheck remains or not.

No argument from me. 

On Wed, Feb 21, 2024, at 10:19 PM, Stefan Kangas wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
> > Flycheck is a package that's well-written, popular, well-maintained, and
> > that respects the users's freedom, so there's no reason not to include
> > it in NonGNU ELPA, regardless if it comes with some bridge for Flymake.
> 
> Agreed.
> 
> > But I'll grant you that it's not 100% orthogonal: If we want to get
> > a uniform interface between the two, the first thing to do would be to
> > encourage cooperation rather than to put up barriers, so including it in
> > NonGNU ELPA could help.
> 
> Yup.  Historical kerfuffles notwithstanding, more collaboration and
> interoperability can only help, whether or not that means that the
> friendly competition[1] between flymake and flycheck remains or not.
> 
> One idea would be to change flymake so that it can support flycheck
> backends natively, without needing any third-party packages.  That would
> already go a long way to decrease the differences between the two
> packages.  I'd definitely encourage work on that.
> 
> 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.
> 
> Footnotes:
> [1]  If it hasn't always been friendly in the past, there's no reason not
>      to work on making sure it's friendly going forward.
> 
> [2]  https://github.com/purcell/flymake-flycheck
> 
> [3]  https://github.com/purcell/flymake-easy
> 
>