Flymake backends

Flymake backends

[Ergus]

Hi:

I have been using flymake instead of flycheck.

Without any configuration I found that flymake does not show any issue;
while flycheck shows multiple corrections. That's why flycheck contains
a simpler interface to implement basic backends and consequently it has
many buildt-in backends (i.e. cppcheck, gfortran etc).

The question is:

1) Is there any effort around to improve the flymake api to add
backends in a simpler way?

Because there are multiple functions the flymake code to simplify common
tasks, but they are intended for private use cases.

It may simplify integration with other build systems like ninja or
cmake.

So far something like flymake-quickdef, may help...

2) Is it desirable to add built-in backends to flymake for common/simple
tools generally available like cppcheck, flake and so on... to improve
the default experience and minimize configuration?

Best,
Ergus

Re: Flymake backends

[Philip Kaludercic]

Ergus <spacibba@aol.com> writes:

> Hi:
>
> I have been using flymake instead of flycheck.
>
> Without any configuration I found that flymake does not show any issue;
> while flycheck shows multiple corrections. That's why flycheck contains
> a simpler interface to implement basic backends and consequently it has
> many buildt-in backends (i.e. cppcheck, gfortran etc).
>
> The question is:
>
> 1) Is there any effort around to improve the flymake api to add
> backends in a simpler way?

There has been an attempt at abstracting over the current API in this
project: https://github.com/mohkale/flymake-collection

> Because there are multiple functions the flymake code to simplify common
> tasks, but they are intended for private use cases.
>
> It may simplify integration with other build systems like ninja or
> cmake.
>
> So far something like flymake-quickdef, may help...
>
> 2) Is it desirable to add built-in backends to flymake for common/simple
> tools generally available like cppcheck, flake and so on... to improve
> the default experience and minimize configuration?

I think that is of interest.  In Emacs 29 shellcheck was added for
instance, and I don't see why other systems shouldn't be supported
either (setting aside legal issues).

> Best,
> Ergus

Re: Flymake backends

[Ergus]

Hi Philip:


On Sun, Apr 16, 2023 at 07:17:08PM +0000, Philip Kaludercic wrote:
>Ergus <spacibba@aol.com> writes:
>
>
>There has been an attempt at abstracting over the current API in this
>project: https://github.com/mohkale/flymake-collection
>

Thanks for replying. I am looking the flymake-collection project and I
think that this is the kind of api we should offer to the user for
applications development. Even that one or a simplified version of that.

But sadly the project is not in elpa... so what should we do for that?


>> Because there are multiple functions the flymake code to simplify common
>> tasks, but they are intended for private use cases.
>>
>> It may simplify integration with other build systems like ninja or
>> cmake.
>>
>> So far something like flymake-quickdef, may help...
>>
>> 2) Is it desirable to add built-in backends to flymake for common/simple
>> tools generally available like cppcheck, flake and so on... to improve
>> the default experience and minimize configuration?
>
>I think that is of interest.  In Emacs 29 shellcheck was added for
>instance, and I don't see why other systems shouldn't be supported
>either (setting aside legal issues).
>

Then I think we should first provide a simpler api that we can maintain
better (i.e. bring functions like flymake-collection-define-rx to
vanilla)

And then we can make a list of the common backends we can support:

So far we only need to give a look to the backends supported by flycheck.

>> Best,
>> Ergus

Re: Flymake backends

[Philip Kaludercic]

Ergus <spacibba@aol.com> writes:

> Hi Philip:
>
>
> On Sun, Apr 16, 2023 at 07:17:08PM +0000, Philip Kaludercic wrote:
>>Ergus <spacibba@aol.com> writes:
>>
>>
>>There has been an attempt at abstracting over the current API in this
>>project: https://github.com/mohkale/flymake-collection
>>
>
> Thanks for replying. I am looking the flymake-collection project and I
> think that this is the kind of api we should offer to the user for
> applications development. Even that one or a simplified version of that.
>
> But sadly the project is not in elpa... so what should we do for that?

The topic was brought up
https://github.com/mohkale/flymake-collection/issues/2, and unless I was
mistaken, the author (Mohsin) has recently requested the CA.  I (hope
to) have CC'ed him in this message, so he can comment on the issue.

My personal opinion is that the current macro[0] is too brittle, and it
would make sense to re-think the specific approach.  Perhaps it could be
translated into a function, or we could make use of generic
functions/vc-like polymorphism to simplify the code.

[0] https://github.com/mohkale/flymake-collection/blob/release/src/flymake-collection-define.el#L134

>>> Because there are multiple functions the flymake code to simplify common
>>> tasks, but they are intended for private use cases.
>>>
>>> It may simplify integration with other build systems like ninja or
>>> cmake.
>>>
>>> So far something like flymake-quickdef, may help...
>>>
>>> 2) Is it desirable to add built-in backends to flymake for common/simple
>>> tools generally available like cppcheck, flake and so on... to improve
>>> the default experience and minimize configuration?
>>
>>I think that is of interest.  In Emacs 29 shellcheck was added for
>>instance, and I don't see why other systems shouldn't be supported
>>either (setting aside legal issues).
>
> Then I think we should first provide a simpler api that we can maintain
> better (i.e. bring functions like flymake-collection-define-rx to
> vanilla)
>
> And then we can make a list of the common backends we can support:
>
> So far we only need to give a look to the backends supported by flycheck.

This might also be a useful starting point:
https://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis.
It conveniently lists the licences each program is distributed under.

I think it would be productive to focus on languages that do not have
LSP support, as Eglot usually does a good job at helping out there.
Things like configuration files might be good candidates.

>>> Best,
>>> Ergus