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: Wed, 21 Feb 2024 22:24:57 +0100 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> <874je413vo.fsf@tanaka.verona.se> <87le7f1hlq.fsf@posteo.net> <874je1ycpk.fsf@posteo.net> <723d6c19-8865-4155-97e7-5aa5e1f89e04@gutov.dev> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=7fa3613199504eb2921c00adebab94e5 Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22856"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Cyrus-JMAP/3.11.0-alpha0-153-g7e3bb84806-fm-20240215.007-g7e3bb848 Cc: joakim@verona.se, "Emacs Devel" To: "Dmitry Gutov" , "Philip Kaludercic" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Feb 21 22:30:05 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 1rcuAF-0005e5-Iq for ged-emacs-devel@m.gmane-mx.org; Wed, 21 Feb 2024 22:30:05 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rcu5o-0008QN-DN; Wed, 21 Feb 2024 16:25:28 -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 1rcu5m-0008Dk-Fb for emacs-devel@gnu.org; Wed, 21 Feb 2024 16:25:26 -0500 Original-Received: from wfhigh5-smtp.messagingengine.com ([64.147.123.156]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rcu5j-00033N-Cp for emacs-devel@gnu.org; Wed, 21 Feb 2024 16:25:26 -0500 Original-Received: from compute7.internal (compute7.nyi.internal [10.202.2.48]) by mailfhigh.west.internal (Postfix) with ESMTP id 1F4D418000B8; Wed, 21 Feb 2024 16:25:19 -0500 (EST) Original-Received: from imap52 ([10.202.2.102]) by compute7.internal (MEProxy); Wed, 21 Feb 2024 16:25:19 -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=1708550718; x=1708637118; bh=6lqVa6FXpN 47aA9eVoqGNA+E7DPM8Z4qrLJR2C6ECCU=; b=gPs1CkunqW/v0P6OvO765U6Ais BudUjQuTFglNXS3y1ZYlY1tkhEQaVznYLDhTcgK3uOnZq0IH3huJ0mdgwlLPoBZA 5sBMulEMHvslb6P4rCWyRSLR39lj67HQumetnR1+gbLgNzo9TRzx/1EfaKXQ7/u8 g4Wh/i2yiMLWA4xNpt8Ad3daLllym5Ps4izI9p60MVDzzuu/TMYcgHnQoGP5g0Nc nos2nyE1o6UB6AfMiRlmak2+qWwUPFYTKgLkYJLx3UmC5gvu7djG5BfwWOJwi65a DM4v6DdMtMZuQ0mNckDOk1dXm51QJbX+qalRtbdkr4Ip1hqfj7D1CMj9cZEQ== 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=1708550718; x=1708637118; bh=6lqVa6FXpN47aA9eVoqGNA+E7DPM 8Z4qrLJR2C6ECCU=; b=ZieoaUPGj7MwXJ2csiaBdPO0ocrbDKqfBAYEvgj8Ahi8 i9mne0BQK7CpOt9N5fIn5BkSy/gfQhP6u1dbDeKf6AKmUDJmOu/yLlt+qWCbVD6b w955nhvm+nXgtNLl7s/rPdJxzhLuEVB1Veq8lijCZzO5xnMuSRz0X+2QyA2MJXTZ nwSK+XyJMaHfw2U/qRKsp9ycWVVycs9w1rfC3JohCY+2EsGR6QkjeecGRPxSImpP dgyq78XSPvy5QXryBhS+8mW/R0P+hUADowweq8KI0X8W7TLjsnjLkwBhskUao5mU kFjKMyNEbFynL+L8k/Cw3bHsVAVA2VbFH0HlJKmUHQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrfedvgddugeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtsegrtderreerredtnecuhfhrohhmpedfueho iihhihgurghruceurghtshhovhdfuceosghoiihhihgurghrsegsrghtshhovhdruggvvh eqnecuggftrfgrthhtvghrnhepfedtkefgvdfgheeuffehjeduheekgfffffehkedttedv jefgleehieeihfffffegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomhepsghoiihhihgurghrsegsrghtshhovhdruggvvh X-ME-Proxy: Feedback-ID: i025946a9:Fastmail Original-Received: by mailuser.nyi.internal (Postfix, from userid 501) id BE4C1C60098; Wed, 21 Feb 2024 16:25:17 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface In-Reply-To: <723d6c19-8865-4155-97e7-5aa5e1f89e04@gutov.dev> Received-SPF: pass client-ip=64.147.123.156; envelope-from=bozhidar@batsov.dev; helo=wfhigh5-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_NONE=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:316430 Archived-At: --7fa3613199504eb2921c00adebab94e5 Content-Type: text/plain I also think we're discussing some orthogonal issues here. Let's take things one step at a time - I'm open to discussing whatever concerns some people have about Flycheck and some form of collaboration with Flymake (e.g. common standard for checker definitions) down the road. Thanks to Dmitry and Stefan for supporting the inclusion of Flycheck to NonGNU ELPA! On Wed, Feb 21, 2024, at 7:19 PM, Dmitry Gutov wrote: > On 21/02/2024 19:00, Philip Kaludercic wrote: > > Dmitry Gutov 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. > > Should I point out that Flycheck's staying out of built-in ELPA sources > still didn't help Flymake grow a comparable library of checkers during > the years that passed? > > Mohsin's efforts are commendable, but I don't think either will take > away from another. Because anyway, when writing a checker the hard[er] > part is determining which commands to use and with which arguments, > rather than the code that does it (which is normally fairly similar > between checkers). Porting them over in either direction is easy enough. > > > 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. > > If there is wrong information in their public documentation or > statements, we definitely should ask them to issue corrections. > > >> 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. > > Yes, people indeed ask questions. Just like they asked about the > difference between lsp-mode and eglot, and still continue to do so. That > did spur better competition for a time, with both sides playing catchup > in different aspects. > > I don't see how anybody is going to stop asking about Flycheck vs > Flymake--they're still doing it now. And Flycheck has much better > visibility in the community anyway. > > > 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. > > It's a good argument which would have probably worked better if the > difference in development speed and release frequency between core Emacs > and 3rd party packages weren't so big. > > But we can still use it to encourage potential contributors to take up > the effort. > > One of the handy bits that Flycheck has, though, it the provision of > several checkers for many of the languages. And (I think?) and interface > the switch between them. That might not fit the major-mode-hook model so > neatly; with Flymake, we usually limit ourselves to automatic detection > and failover. > > >>> 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). > > I'm pretty sure it only does that when asked. And if said software is > FLOSS, I don't see the problem--finding the sources is easy enough. > > >> 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. > > Not at the moment, and there are pretty obvious factors playing into it. > But we should leave that door open. > > --7fa3613199504eb2921c00adebab94e5 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
I also think we= 're discussing some orthogonal issues here. Let's take things one step a= t a time - I'm open to discussing whatever concerns some people have abo= ut Flycheck and some form of collaboration with Flymake (e.g. common sta= ndard for checker definitions) down the road.

<= div>Thanks to Dmitry and Stefan for supporting the inclusion of Flycheck= to NonGNU ELPA! 

On Wed, Feb 21, 202= 4, at 7:19 PM, Dmitry Gutov wrote:
On 21/02/2024 19:00, Philip Kaludercic wrote:
> Dmitry Gutov <dm= itry@gutov.dev> writes:
> 
&g= t;> On 20/02/2024 13:48, Philip Kaludercic wrote:
>&= gt;
>>> If Flycheck were to use the same interfac= e as Flymake, then the
>>> situation would be bet= ter, 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 function= al interface under the
>> covers, but for that to ha= ppen, it would help a lot if we were more
>> welcomi= ng.
> 
> That is what flymake-col= lection is supposedly working on.

Should I = point out that Flycheck's staying out of built-in ELPA sources 
=
still didn't help Flymake grow a comparable library of checke= rs during 
the years that passed?

<= /div>
Mohsin's efforts are commendable, but I don't think either wil= l take 
away from another. Because anyway, when writi= ng a checker the hard[er] 
part is determining which = commands to use and with which arguments, 
rather tha= n the code that does it (which is normally fairly similar 
between checkers). Porting them over in either direction is easy e= nough.

> No, but effort is wasted on dev= eloping incompatible backends.  If
> Flycheck coul= d 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 s= ide to converge to a common denominator.

If= there is wrong information in their public documentation or 
statements, we definitely should ask them to issue corrections.=

>> Note that when Xref was introduce= d, there were no existing protocols
>> out there, in= third-party packages or not, that could be used for the
&= gt;> same purpose (abstraction over code navigation sources).
> 
> True, but that only made it easier.=   If there had been some MELPA
> package called "j= umpy" of whatever, then some packages would support
> x= ref, the others "jumpy", others again would have to try and support
<= /div>
> both.  People would constantly be asking "what is th= e difference between
> xref and jumpy", and others agai= n wouldn't notice xref at all because
> they assume tha= t every feature in Emacs has to be installed via some
>= external package.

Yes, people indeed ask q= uestions. Just like they asked about the 
difference = between lsp-mode and eglot, and still continue to do so. That 
<= /div>
did spur better competition for a time, with both sides playin= g catchup 
in different aspects.

I don't see how anybody is going to stop asking about Flycheck = vs 
Flymake--they're still doing it now. And Flycheck= has much better 
visibility in the community anyway.=

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

It's a good argument whi= ch would have probably worked better if the 
differen= ce in development speed and release frequency between core Emacs 
and 3rd party packages weren't so big.

But we can still use it to encourage potential contributors to = take up 
the effort.

One= of the handy bits that Flycheck has, though, it the provision of <= br>
several checkers for many of the languages. And (I think?)= and interface 
the switch between them. That might n= ot fit the major-mode-hook model so 
neatly; with Fly= make, we usually limit ourselves to automatic detection 
<= div>and failover.

>>> I know that = there are differences, and I hope that the situation
>&= gt;> improves, but to mention another negative that probably disquali= fies
>>> adding the package just on its own: `lsp= -install-server'.  The command
>>> can downl= oad arbitrary executable files as servers and runs them
&g= t;>> locally.
>>
>> curl c= an download arbitrary executable files, and it's still free
>> software. The question is which urls are pre-configured.
<= /div>
> 
> The objection is not that lsp-mo= de is not free software, it is that it
> doesn't respec= t their users by downloading arbitrary binaries from the
&= gt; 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).

I'm pretty sure it only does that= when asked. And if said software is 
FLOSS, I don't = see the problem--finding the sources is easy enough.

<= /div>
>> If we come to consider the inclusion of lsp-mode seri= ously (meaning,
>> there would be some interest from= the maintainers), I'm happy to
>> discuss requestin= g 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 s= eparate packages
>> that we don't publish.
=
> 
> My impression of the lsp-mode maintai= ners is that they have no interest
> in collaborating w= ith core development.

Not at the moment, an= d there are pretty obvious factors playing into it. 
= But we should leave that door open.



--7fa3613199504eb2921c00adebab94e5--