* Flymake backends [not found] <hsryxz6ppcdsvv7i2ebdwoimldlg5b7xewgh43vz2jbbjsqe6d.ref@o6naxb3fkymi> @ 2023-04-16 15:07 ` Ergus 2023-04-16 19:17 ` Philip Kaludercic 0 siblings, 1 reply; 4+ messages in thread From: Ergus @ 2023-04-16 15:07 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Flymake backends 2023-04-16 15:07 ` Flymake backends Ergus @ 2023-04-16 19:17 ` Philip Kaludercic 2023-04-16 20:35 ` Ergus 0 siblings, 1 reply; 4+ messages in thread From: Philip Kaludercic @ 2023-04-16 19:17 UTC (permalink / raw) To: Ergus; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Flymake backends 2023-04-16 19:17 ` Philip Kaludercic @ 2023-04-16 20:35 ` Ergus 2023-04-17 13:21 ` Philip Kaludercic 0 siblings, 1 reply; 4+ messages in thread From: Ergus @ 2023-04-16 20:35 UTC (permalink / raw) To: Philip Kaludercic; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Flymake backends 2023-04-16 20:35 ` Ergus @ 2023-04-17 13:21 ` Philip Kaludercic 0 siblings, 0 replies; 4+ messages in thread From: Philip Kaludercic @ 2023-04-17 13:21 UTC (permalink / raw) To: Ergus; +Cc: emacs-devel, mohkalex 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2023-04-17 13:21 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <hsryxz6ppcdsvv7i2ebdwoimldlg5b7xewgh43vz2jbbjsqe6d.ref@o6naxb3fkymi> 2023-04-16 15:07 ` Flymake backends Ergus 2023-04-16 19:17 ` Philip Kaludercic 2023-04-16 20:35 ` Ergus 2023-04-17 13:21 ` Philip Kaludercic
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.