From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "Bozhidar Batsov" Newsgroups: gmane.emacs.devel Subject: Re: Adding Flycheck to NonGNU ELPA Date: Mon, 19 Feb 2024 21:17:34 +0200 Message-ID: References: <41bdb94a-3f9c-4b46-b061-b0c5e31a403e@app.fastmail.com> <871q98bb7q.fsf@posteo.net> <72490bec-175b-46b6-aaf9-153b3c242b70@app.fastmail.com> <87le7g9tg9.fsf@posteo.net> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=86a6f06b12e64362832a37e414e196df Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30436"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Cyrus-JMAP/3.11.0-alpha0-144-ge5821d614e-fm-20240125.002-ge5821d61 Cc: "Emacs Devel" To: "Philip Kaludercic" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Feb 19 20:19:17 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rc9AZ-0007f8-Jg for ged-emacs-devel@m.gmane-mx.org; Mon, 19 Feb 2024 20:19:17 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rc99O-0006NF-PH; Mon, 19 Feb 2024 14:18:02 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rc99M-0006Mp-EL for emacs-devel@gnu.org; Mon, 19 Feb 2024 14:18:00 -0500 Original-Received: from out5-smtp.messagingengine.com ([66.111.4.29]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rc99J-0000YW-8h for emacs-devel@gnu.org; Mon, 19 Feb 2024 14:18:00 -0500 Original-Received: from compute7.internal (compute7.nyi.internal [10.202.2.48]) by mailout.nyi.internal (Postfix) with ESMTP id 4BF155C0089; Mon, 19 Feb 2024 14:17:55 -0500 (EST) Original-Received: from imap52 ([10.202.2.102]) by compute7.internal (MEProxy); Mon, 19 Feb 2024 14:17:55 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=batsov.dev; h=cc :cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1708370275; x=1708456675; bh=RhQCi7hqZr dqaPGQiQg5dAjL+4tD+2hG4xDPmefLl28=; b=fIcK0UZkCan4+4dPEsuaOWxmFG SrWmOnVR97CkRgUiUSWLWi8G2v0uc9Clk04wTqDhdhYfYFW0Sgy6VWGDZdGfYOfy B/xFj0bCTKbDpGCOQvbcrxLZrEgLEkon0VeRwvoegbTwF6qxEdcWilqODjfyjTSf b8kszQk3LqSaZjn5kR0A7EtV1/0GDcx5Fx6mkHjZh/iRoFqFg71FPyXVMGHYtp9h HwnmPYOuObuDAhYTzg2yTASEATxWfGi4kSJIpd046yIvr4wXNyw5ki/71FIKu+8T CKxVN5/cS4+LgBfMYWS4VWDazkrBV9UMbMWviRUMTsiq40Z+Q916lFYNPENA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1708370275; x=1708456675; bh=RhQCi7hqZrdqaPGQiQg5dAjL+4tD +2hG4xDPmefLl28=; b=kgmkKSurDl2xwGsxfeq6A0Zu5oC/wrmM8xl02JP/FdKz pochAf11F18oElTnKK5FnU4sY0ghxQopUICi1J6/Vd6dBT3hEvfevbfOLjU+5RHQ mXIGSBas6St0xS51gJcr/Pw04iWo+MEdKBDAy0MiGNNVapDsys7UTbkAm8D8iw7I h3714nyXwdQIbKVLH1u3pbHp0vOzKfra7TwUhxTZrGO4DyiKTA4WJdg9RvkqwwJU mqGzQHLmslkdDTdKrU5TebZRbuhtRoWnRzw3pvBu/CjPnxSz8anNNoFvrunApW7D tUbRMboMIDohsNzJIeEoX+gEHkWlqj+zc6S1AQQg8Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrvdekgdduvdduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtsegrtderreerredtnecuhfhrohhmpedfueho iihhihgurghruceurghtshhovhdfuceosghoiihhihgurghrsegsrghtshhovhdruggvvh eqnecuggftrfgrthhtvghrnhepudfggeeguedvgeejgeelhfelkedvleeuveegfffflefg teetkeeffffffeejjedtnecuffhomhgrihhnpehgnhhurdhorhhgpdhflhihtghhvggtkh drohhrghdpghhithhhuhgsrdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghr rghmpehmrghilhhfrhhomhepsghoiihhihgurghrsegsrghtshhovhdruggvvh X-ME-Proxy: Feedback-ID: i025946a9:Fastmail Original-Received: by mailuser.nyi.internal (Postfix, from userid 501) id 04DBDC60097; Mon, 19 Feb 2024 14:17:55 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface In-Reply-To: <87le7g9tg9.fsf@posteo.net> Received-SPF: pass client-ip=66.111.4.29; envelope-from=bozhidar@batsov.dev; helo=out5-smtp.messagingengine.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:316366 Archived-At: --86a6f06b12e64362832a37e414e196df Content-Type: text/plain > 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. Oh, damn - I mixed a private thread with Philip and the message I had sent here. (I had reached out to him before posting here, as I was hoping to avoid a public thread on the topic) :double-facepalm: Anyways, that's on me. > 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. Fair enough. Still, you don't get to #4 in the all-time rankings on past usage alone. I'm sorry that I can't provide better usage metrics to support my case. > 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. I'm afraid I don't have the time to do a detailed research on the current state of Flymake. I haven't written the comparison page myself and I agree some points there are small/subjective. I'm not sure how you came to the conclusion that Flycheck got deprecated, though. Any analysis that I would do would be subjective of course, from mine perspective and from yours, so I think it wouldn't change anything. To be clear I don't want to argue which project is better and what are the merits of Flycheck over Flymake, if any. If it's so big of a deal to have packages that duplicate core functionality in the official repos - fine. > 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. I get your point about quality, but here we're not talking about some random package of questionable provenance. You can inspect the codebase yourself if you want, but (subjectively speaking) has fairly clean codebase, lots of unit tests, and very detailed documentation. (and a sizeable, if hard to measure user-base) Flymake's docs (https://www.gnu.org/software/emacs/manual/html_node/emacs/Flymake.html) are pretty basic compared to Flycheck's so I feel you're applying double standards here. Anyways, I had a feeling I'd regret asking for the inclusion of Flycheck. I'll take is that my answer is "No". I really don't want to turn this into some heated debate, so we can just wrap up here. On Mon, Feb 19, 2024, at 8:53 PM, Philip Kaludercic wrote: > "Bozhidar Batsov" 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" 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. > >> > >> > > --86a6f06b12e64362832a37e414e196df Content-Type: text/html Content-Transfer-Encoding: quoted-printable
For the sake of a constructive discussio= n, please don't make claims like
these without any further= references.  Provocations like these, from
anyone, o= nly make discussions like these more difficult.

Oh, damn - I mixed a private thread with Philip and th= e message I had sent here. (I had reached out to him before posting here= , as I was hoping to avoid a public thread on the topic) :double-facepal= m: Anyways, that's on me.

I do not follow MELPA development or stati= stics, but from what I recall
these are just accumulated d= ownloads over all versions, right?  If so,
then the i= nformation we get from this fact is rather low.

Fair enough. Still, you don't get to #4 in the all-tim= e rankings on past usage alone. I'm sorry that I can't provide better us= age metrics to support my case.

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

<= div>I'm afraid I don't have the time to do a detailed research on the cu= rrent state of Flymake. I haven't written the comparison page myself and= I agree some points there are small/subjective. I'm not sure how you ca= me to the conclusion that Flycheck got deprecated, though. Any analysis = that I would do would be subjective of course, from mine perspective and= from yours, so I think it wouldn't change anything. 

To be clear I don't want to argue which project is bett= er and what are the merits of Flycheck over Flymake, if any. If it's so = big of a deal to have packages that duplicate core functionality in the = official repos - fine.

As you say, people will continue
maintaining third-p= arty 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 h= ope that this helps
make the system more robust for everyo= ne.

I get your point about qu= ality, but here we're not talking about some random package of questiona= ble provenance. You can inspect the codebase yourself if you want, but (= subjectively speaking) has fairly clean codebase, lots of unit tests, an= d very detailed documentation. (and a sizeable, if hard to measure user-= base) Flymake's docs (https://www.gnu.org/software/emacs/manu= al/html_node/emacs/Flymake.html) are pretty basic compared to Flyche= ck's so I feel you're applying double standards here.
Anyways, I had a feeling I'd regret asking for the inclusion= of Flycheck. I'll take is that my answer is "No".

I really don't want to turn this into some heated debate, so we = can just wrap up here.

On Mon, Feb 19, 202= 4, at 8:53 PM, Philip Kaludercic wrote:
"Bozhidar Batsov" <bozhidar@batsov.dev> writes:

=
> There is a detailed comparison here

From what I see, this compari= son is outdated and somewhat one-sided.
Flymake has error = explanations, and categories like "Automatic syntax
checki= ng" seem disingenuous if the complaint is that there is not a
<= div>flymake-global-mode.  (It would have probably taken less time t= o 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 tr= igger 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, se= ems like a success story.

>  &= nbsp;           &= nbsp;           &= nbsp;       And the contributors to Flyche= ck and
> Flymake were always pretty different - part of= the reason Sebastien
> (the original author of Flychec= k) quit Emacs were some attacks he was
> getting on ema= cs-devel.

For the sake of a constructive di= scussion, please don't make claims like
these without any = further references.  Provocations like these, from
an= yone, 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
> contributo= rs.

I don't think this is the problem you a= re making it out to be, and even
if it were, one could hav= e a package like flymake-collection added to
NonGNU ELPA.<= br>

> Btw, flymake-flycheck was created only= because Joao wouldn't agree to
> provide Flycheck supp= ort in Eglot (I know this from the author of
> flymake-= flycheck). The whole situation with Elgot was a classic
&g= t; 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 br= inging 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
>> Flym= ake OOTB), I don't know how valuable this is.
>
> Btw, Eglot is not the only LSP client for Emacs. :-) lsp-mod= e users
> flycheck by default for its error diagnostics= . I'm not a big LSP user,
> though, and often prefer th= e simplicity of just shelling out to
> whatever lint to= ols I need.

The "lsp-mode" is not part of N= onGNU ELPA, so I don't think that is a
problem in this cas= e.

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

I do not foll= ow 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 feat= ure for ELPA, then we should pay
attention to avoid this m= istake, and only display the download counts
over some fix= ed time interval, e.g. the information currently available
in the access logs.)

>   = ;            = ;            = ;            = ;     
>   &nbs= p;           &nbs= p;           &nbs= p;           &nbs= p;    I'm one of them and that's
> why I= took over the maintenance of the project. I felt that NonGNU
<= div>> ELPA existed to make it easier for popular stuff to be installe= d by
> users, but it seems to me MELPA won't be going a= way any time soon.

NonGNU ELPA is not only = a means of making more useful packages readily
available t= o 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 functional= ity), 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 repo= sitories that accept every brittle little
scripts anyone w= rites (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<= br>
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 discus= sions, I don't think anyone here hates one
another or inte= ntionally wants to hinder them personally.  It takes
= effort to take others seriously, but it is worth undertaking if we want<= br>
to make Emacs better.

To this= end, I repeat my question: What _technical functionality_ does
Flycheck _currently_ provide that Flymake does not?  A differ= ent way of
putting it is what architectural advantages doe= s Flycheck exemplify over
Flymake, that give it an inheren= t edge?  If there aren't too many
differences, I thin= k the cost of confusion (Flymake and Flycheck are
names th= at 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,
>> ><= br>
>> > Just wanted to ask if there's any interested= in adding Flycheck
>> > (https://www.flycheck.org/en/latest/), a pop= ular alternative to
>> > Flymake, to NonGNU ELPA?=
>> >
>> > You can find th= e codebase here ht= tps://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
>> unde= rstand it has a database of tools built-in, but considering that
>> more and more people rely on LSP for the information (an= d Eglot supports
>> Flymake OOTB), I don't know how = valuable this is.  In addition to that,
>> ther= e are projects like
>> 
>> 
= >> that could help bridge the gap.
>> 
>> 



--86a6f06b12e64362832a37e414e196df--