Re: Adding Flycheck to NonGNU ELPA

[Philip Kaludercic]

Dmitry Gutov <dmitry@gutov.dev> writes:

> 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.

That is what flymake-collection is supposedly working on.

>>> 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.

No, but effort is wasted on developing incompatible backends.  If
Flycheck could take a similar route like Company in recommending to
develop against the default/built-in interface (CAPF and Flymake
respectively), then I really wouldn't mind having a second UI, but
considering the misinformation that Flycheck still promote, I don't see
any interest from their side to converge to a common denominator.

>>>>> 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).

True, but that only made it easier.  If there had been some MELPA
package called "jumpy" of whatever, then some packages would support
xref, the others "jumpy", others again would have to try and support
both.  People would constantly be asking "what is the difference between
xref and jumpy", and others again wouldn't notice xref at all because
they assume that every feature in Emacs has to be installed via some
external package.

This also reminds me of another point: Xref, Flymake, CAPF, ... are all
interfaces, that don't have to bring with them implementations for all
kinds of languages.  That is the job of a major mode, and it is a lot
more reasonable for a major mode to implement this interface, if
provided by a core package, than if they had to use an third-party
package that is not even part of GNU ELPA.

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

FWIW I think having "Projectile" is a mistake as well (I didn't want to
voice the position at the time, because people were still belittling
NonGNU ELPA at the time), but at least the effect is not that
significant since it appears that not that many Projectile-based
packages?

>>> 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.

I know, having this kind of a parallel society of functionality is sad,
but as I said, it is a consequence of the way `completing-read' is used
and misunderstood.

Communicating with the package developers of these selection frameworks
to create a new interface would be an interesting task.

>> 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'd say that should be the sine qua non.  If I could decide, Flycheck
should be reduced to a UI, their interface should be deprecated and the
backends translated to Flymake.  That would have the best long-term
consequences for users.  But adding Flycheck just like that will
certainly just perpetuate the unnecessary schism and confusion.

>> 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.

The objection is not that lsp-mode is not free software, it is that it
doesn't respect their users by downloading arbitrary binaries from the
net and running them on their own machines, even if all the servers were
free (which I don't know, I haven't checked all of them).

> 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.

My impression of the lsp-mode maintainers is that they have no interest
in collaborating with core development.