Re: Adding Flycheck to NonGNU ELPA

[Philip Kaludercic]

"Bozhidar Batsov" <bozhidar@batsov.dev> writes:

> There is a detailed comparison here
> https://www.flycheck.org/en/latest/user/flycheck-versus-flymake.html

>From what I see, this comparison is outdated and somewhat one-sided.
Flymake has error explanations, and categories like "Automatic syntax
checking" seem disingenuous if the complaint is that there is not a
flymake-global-mode.  (It would have probably taken less time to write a
`define-globalized-minor-mode', than the time to write this point...)

> but many of the differences are probably not important to many
> people. You might remember that before Flycheck, Flymake was in a
> state of disarray and abandoment for years, so I'm pretty sure
> Flycheck making it almost obsolete back then was the trigger for some
> modernization around Emacs 26.1. 

Could you explain how this relates to the current state of Flymake
vs. Flycheck?  The fact that Flymake caught up, and in my eyes
deprecated Flycheck, seems like a success story.

>                                  And the contributors to Flycheck and
> Flymake were always pretty different - part of the reason Sebastien
> (the original author of Flycheck) quit Emacs were some attacks he was
> getting on emacs-devel.

For the sake of a constructive discussion, please don't make claims like
these without any further references.  Provocations like these, from
anyone, only make discussions like these more difficult.

> Many people are so off-put by the discourse there, that they want to
> have as little as possible with it. And that's the real value of
> alternative packages IMO - they allow us to harvest the energy of all
> contributors.

I don't think this is the problem you are making it out to be, and even
if it were, one could have a package like flymake-collection added to
NonGNU ELPA.

> Btw, flymake-flycheck was created only because Joao wouldn't agree to
> provide Flycheck support in Eglot (I know this from the author of
> flymake-flycheck). The whole situation with Elgot was a classic
> example of the hostility in Emacs towards packages some maintainers
> dislike... (https://github.com/joaotavora/eglot/issues/42)

I don't know how you infer, but again, it would be nice to keep the
discussion here on-topic instead of bringing up old drama between
GNU-adjacent/core development and MELPA/GitHub/anti-GNU people.

>> but considering that
>> more and more people rely on LSP for the information (and Eglot supports
>> Flymake OOTB), I don't know how valuable this is.
>
> Btw, Eglot is not the only LSP client for Emacs. :-) lsp-mode users
> flycheck by default for its error diagnostics. I'm not a big LSP user,
> though, and often prefer the simplicity of just shelling out to
> whatever lint tools I need.

The "lsp-mode" is not part of NonGNU ELPA, so I don't think that is a
problem in this case.

> You probably know that Flycheck is one of the most download packages
> on MELPA, so it has plenty of happy users. 

I do not follow MELPA development or statistics, but from what I recall
these are just accumulated downloads over all versions, right?  If so,
then the information we get from this fact is rather low.

(BTW. if we are to implement this feature for ELPA, then we should pay
attention to avoid this mistake, and only display the download counts
over some fixed time interval, e.g. the information currently available
in the access logs.)

>                                            
>                                            I'm one of them and that's
> why I took over the maintenance of the project. I felt that NonGNU
> ELPA existed to make it easier for popular stuff to be installed by
> users, but it seems to me MELPA won't be going away any time soon.

NonGNU ELPA is not only a means of making more useful packages readily
available to users OOTB (without having to search online blogs and fora
for code snippets that enable third-party archives and install dozens of
weirdly named packages replicating built-in functionality), but also a
chance to clean up the package landscape, and prune away some
experiments from the 2010s.  As you say, people will continue
maintaining third-party repositories that accept every brittle little
scripts anyone writes (I speak here from experience and personal
suffering), but I think it is a feature that ELPA has a more curated
policy.  I for my really try my best to raise the bar of package
submissions, and while it is not always easy, I hope that this helps
make the system more robust for everyone.  So once more, please do not
assume malice in these discussions, I don't think anyone here hates one
another or intentionally wants to hinder them personally.  It takes
effort to take others seriously, but it is worth undertaking if we want
to make Emacs better.

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.

> On Mon, Feb 19, 2024, at 7:44 PM, Philip Kaludercic wrote:
>> "Bozhidar Batsov" <bozhidar@batsov.dev> writes:
>> 
>> > Hey everyone,
>> >
>> > Just wanted to ask if there's any interested in adding Flycheck
>> > (https://www.flycheck.org/en/latest/), a popular alternative to
>> > Flymake, to NonGNU ELPA?
>> >
>> > You can find the codebase here https://github.com/flycheck/flycheck
>> > There's also some integration with Eglot 
>> > https://github.com/flycheck/flycheck-eglot
>> >
>> > I'm not sure what's the stance of adding alternatives to built-in
>> > packages in general, but I think providing some alternatives to the
>> > end users is not a bad thing overall.
>> 
>> My main question is what advantage Flycheck has over Flymake.  I
>> understand it has a database of tools built-in, but considering that
>> more and more people rely on LSP for the information (and Eglot supports
>> Flymake OOTB), I don't know how valuable this is.  In addition to that,
>> there are projects like
>> 
>> https://github.com/mohkale/flymake-collection
>> https://github.com/purcell/flymake-flycheck
>> 
>> that could help bridge the gap.
>> 
>>