Re: Adding Flycheck to NonGNU ELPA

[Philip Kaludercic <philipk@posteo.net>]

joakim@verona.se writes:


[...]

> Maybe having more alternatives in Elpa/Melpa would actually lead to more
> code re-use between the alternatives? That would be nice but I guess
> history indicates otherwise.

I am afraid that this is not the case, instead of leads to more glue
code having to be written.  If we want to be more efficient, we should
focus on promoting generic interfaces (Xref, Imenu, Flymake, ...) and
writing back-end implementations.  As an added bonus, we improve the
consistency of the user experience.

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.

Dmitry Gutov <dmitry@gutov.dev> writes:

> On 19/02/2024 21:52, Philip Kaludercic wrote:
>> Dmitry Gutov <dmitry@gutov.dev> writes:
>> 
>>> On 19/02/2024 20:53, Philip Kaludercic wrote:
>>>> To this end, I repeat my question: What_technical functionality_  does
>>>> Flycheck_currently_  provide that Flymake does not?  A different way of
>>>> putting it is what architectural advantages does Flycheck exemplify over
>>>> Flymake, that give it an inherent edge?  If there aren't too many
>>>> differences, I think the cost of confusion (Flymake and Flycheck are
>>>> names that are easy to confuse) and of inducing choice-fatigue among new
>>>> users is not something we should ignore.
>>>
>>> I'm fairly sure the main answer is "lots of built-in checkers", much
>>> more than flymake still has now.
>> Do you think that adding "flymake-collection" to NonGNU ELPA could
>> help
>> improve the situation sufficiently?  See also
>> https://github.com/mohkale/flymake-collection/issues/2.
>
> 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).

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

>>> On the subject of choice fatigue, would we hesitate to include
>>> lsp-mode in NonGNU ELPA, now that Eglot is in the core? I feel that
>>> would be the wrong move.
>> FWIW I would argue against it.  Setting aside issues of
>> dependencies, it
>> is my impression that the "lsp-mode" tries to superficially convert
>> Emacs into some VSCode like experience, introducing a lot of transient
>> information that cannot be operated on normally, popup windows that
>> cannot be selected/persisted/searched or otherwise re-creating UI
>> features that already exist in Emacs.
>
> Are we going to police UIs now?

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.

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

> lsp-mode is not just eye candy anyway.
>
> Just as I've discovered last week (I'm not a heavy user of either), it
> has a handy test runner integration and more reliable errors reporting
> (for syntax, etc). And that's with Flymake.
>
> Also, it's average latency for completion was lower in my benchmarking
> not too long ago. Though that's probably the fault of Eglot's
> expensive pretty-printing in logging.
>
> And the popup windows are easily turned off.

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.  From what I see there is no reference to any software licenses
or where to find the source code.  To be fair, this is partially due to
the mentality that Microsoft had when writing VSCode (remember that a
number of the most popular extensions and servers written by Microsoft
are explicitly non-free software that must be used together with the
official signed release of VSCode), which the "lsp-mode" developers
appears to accept uncritically.