Re: Adding Flycheck to NonGNU ELPA

[Dmitry Gutov]

On 20/02/2024 13:48, Philip Kaludercic wrote:

> If Flycheck were to use the same interface as Flymake, then the
> situation would be better, as it would only be a different UI with
> perhaps some other priorities.

Flycheck uses macros to define checkers and output parsers. Perhaps one 
day those could expand to Flymake's functional interface under the 
covers, but for that to happen, it would help a lot if we were more 
welcoming.

> > It might be an improvement, but AFAIK Flycheck still has an order of a
> > magnitude more checkers.
> >
> > Offhand,
> > https://github.com/mohkale/flymake-collection/tree/release/src/checkers
> > doesn't include anything for Rust or Golang.
> >
> > And Flycheck has several for both.
>
> This appears to be true, but this is not an inherent advantage, just the
> fact that people have invested effort into it.  It seems to be that a
> significant reason is that Flycheck has a convenient language for
> defining checkers, something that IIUC flymake-collection is also
> working on.  Giving this basis, we could look into perhaps even
> automatically translating the Checker specifications, which would help
> further "obsolete" Flycheck, given that this is apparently the only real
> "advantage" it provides (which again, is not architectural, just the
> accumulated labour over the last decade).

Nobody stops people from working on Flymake, improving the documentation 
and developer experience, and the list of built-in checkers.

In fact, I'm pretty sure this will happen faster with healthy 
competition in sight.

> > > > It also has a minor mode map, to invoke the errors buffer or jump
> > > > between the errors. Though the latter is easy-ish to port over.
> > > I agree, that that is an annoyance.  I have personally bound
> > > `flymake-goto-next-error' and `flymake-goto-prev-error' to M-n and M-p
> > > respectively, but it would be nice if we could find some keys to bind
> > > these commands to.
> >
> > Same.
>
> I'll look into submitting a bug report to propose such a change.

Very good.

> I wouldn't put it that way, but as mentioned above I do think that
> pushing towards a consistent UI that aligns with Emacs strengths
> (text-based, buffers in windows, ...) is worth the effort, even if some
> projects have to change or die in the process.  E.g. a positive example:
> I added support for the "dumb-jump" to use Xref instead of
> re-implementing the UI with custom commands and popups.  People appear
> to use that now.

Note that when Xref was introduced, there were no existing protocols out 
there, in third-party packages or not, that could be used for the same 
purpose (abstraction over code navigation sources).

A counter-example is Projectile, which predated project.el, and which we 
included in NonGNU ELPA to no particular detriment.

> > Let's remove Helm from NonGNU, then: its UI paradigm is also different
> > from the core Emacs, and IMHO it's rather ugly. And swiper/ivy from
> > ELPA, just because.
>
> While I am not a fan of Helm, it was initially added to provide popular
> packages that a number of people appeared to want to use.  Luckily these
> packages fall into the category of providing the front-end of a shared
> interface (completing-read; and that not without issues, because they
> tend to abuse completing-read's text expansion idea by focusing on
> narrowing and selecting).

Yes, Helm provides some support for completing-read, but it also has its 
own specific API which is bigger and more tailored for its UI, and is 
the reason there are Helm-specific plugins.

> And yes, there are packages that have hard
> dependencies on Helm, but usually when people submit these kinds of
> packages, we at least mention the idea of trying to generalise them, so
> that the front- and back-end can be disentangled from one another.

We can both accept Flycheck and suggest the maintainers work toward 
someday having a compatible API, at least on the functional level.

> I know that there are differences, and I hope that the situation
> improves, but to mention another negative that probably disqualifies
> adding the package just on its own: `lsp-install-server'.  The command
> can download arbitrary executable files as servers and runs them
> locally.

curl can download arbitrary executable files, and it's still free 
software. The question is which urls are pre-configured.

If we come to consider the inclusion of lsp-mode seriously (meaning, 
there would be some interest from the maintainers), I'm happy to discuss 
requesting that whatever proprietary servers are configured in (I think 
there is 1 proprietary option for PHP among the total 4 available, not 
sure what else) are split off into separate packages that we don't publish.