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:46:25 +0100 Message-ID: <4ba658dd-1a12-4baf-a850-c851274da722@app.fastmail.com> 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> <69829f55-511b-4543-9a1b-938a5e8ac08c@gutov.dev> <87zfvtwy2w.fsf@posteo.net> <706be920-cbd4-42d8-8c76-3abdb7e7b026@gutov.dev> <87edd5wv59.fsf@posteo.net> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=a27369f76c9a430182066b8422c2677e Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7656"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Cyrus-JMAP/3.11.0-alpha0-153-g7e3bb84806-fm-20240215.007-g7e3bb848 Cc: "Dmitry Gutov" , joakim@verona.se, "Emacs Devel" , "Steve Purcell" To: "Stefan Kangas" , "Stefan Monnier" , "Philip Kaludercic" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Feb 21 22:47:50 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 1rcuRP-0001ey-Ag for ged-emacs-devel@m.gmane-mx.org; Wed, 21 Feb 2024 22:47:49 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rcuQX-0000AS-Hg; Wed, 21 Feb 2024 16:46:53 -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 1rcuQV-0000AF-ST for emacs-devel@gnu.org; Wed, 21 Feb 2024 16:46:51 -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 1rcuQT-0007EF-LX for emacs-devel@gnu.org; Wed, 21 Feb 2024 16:46:51 -0500 Original-Received: from compute7.internal (compute7.nyi.internal [10.202.2.48]) by mailfhigh.west.internal (Postfix) with ESMTP id 67A461800125; Wed, 21 Feb 2024 16:46:46 -0500 (EST) Original-Received: from imap52 ([10.202.2.102]) by compute7.internal (MEProxy); Wed, 21 Feb 2024 16:46:47 -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=1708552005; x=1708638405; bh=nM/wKx6TKP KVpSeM2Zslm92580WiWny2U+uwRRFRsZs=; b=f/JGEGWVXni1Rbon1LwEbRluCL 0aNKQ+zjDW6HKyeWIbhAZg0o+WALP2mhxqwRoiRLdPs5aZvGuAUppkLQXT1AsH0G VQ7Ai1Cz9rUTWlOuM0gdJkc7YZoSRAUh2JbJxYeeLTOYBydvmoxMdhQbSWDWzs0/ JvVl3r3PTRULCGkG4A2UzFwNpltEYPGeuvr9oB12rkscOmjcy9KkkGUVPMmYdgdG 39ipH3/T9x4hiwZWqFTdXNbfcApXxzdjK7XMndTaz8gdIKbw28S+soUpq4folbyg SEl0Q7WHhOXTZRTt65KGwMGCtNsXT7qKllMNyytg8cgCY82/VpNmZeyZjwDA== 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=1708552005; x=1708638405; bh=nM/wKx6TKPKVpSeM2Zslm92580Wi Wny2U+uwRRFRsZs=; b=UVlzDlBWux4HgYGaA/UlYtEBOiywsOUAxMjEEFUPB4uI XL/jkaRNaocpPQF9OPSGA7FXK/zJRi1KwtbFn2etH85Hl0YJU0yCGauF5QacScHi MzBs0Tt1qCMVetHJj3qhEvE7wAR9c2Bv+BfI5OUxwkFJ+f9Uc62YEre693HdgM6F u670yFIB6I2v/Vdq7uST/hTVALFzy+kn+r4sm4080ZlR31Jzm4TBh4ApmoTVZPE2 MMKVKjFMb6tFW4NqBlkACDRf5v2c8nHm4SOmqXttsDxARyQ6nX4OkZzHpWEI4gKN BuHDrJCRVDs46gbnLueMxsN9WUtkJxOdr2tKlXdVJA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrfedvgdduheduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtsegrtderreerredtnecuhfhrohhmpedfueho iihhihgurghruceurghtshhovhdfuceosghoiihhihgurghrsegsrghtshhovhdruggvvh eqnecuggftrfgrthhtvghrnhepgeekkefghfffleetffdtkedvvdehieeghfelvdfhhfeu ueduledtteeuhfeitdejnecuffhomhgrihhnpehgihhthhhusgdrtghomhenucevlhhush htvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsohiihhhiuggrrhes sggrthhsohhvrdguvghv X-ME-Proxy: Feedback-ID: i025946a9:Fastmail Original-Received: by mailuser.nyi.internal (Postfix, from userid 501) id 6DFCFC60097; Wed, 21 Feb 2024 16:46:45 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface In-Reply-To: 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:316431 Archived-At: --a27369f76c9a430182066b8422c2677e Content-Type: text/plain > One idea would be to change flymake so that it can support flycheck > backends natively, without needing any third-party packages. That would > already go a long way to decrease the differences between the two > packages. I'd definitely encourage work on that. > > Another thing is that we could use a good built-in macro to define > flymake backends. > > Perhaps Steve Purcell (added to CC) could be convinced to contribute his > excellent flymake-flycheck[2] and flymake-easy[3] packages to core? > This would kill two (or more) birds with one stone, and also remove some > of the gripes that some users have with flymake. Pretty reasonable ideas IMO. > Yup. Historical kerfuffles notwithstanding, more collaboration and > interoperability can only help, whether or not that means that the > friendly competition[1] between flymake and flycheck remains or not. No argument from me. On Wed, Feb 21, 2024, at 10:19 PM, Stefan Kangas wrote: > Stefan Monnier writes: > > > Flycheck is a package that's well-written, popular, well-maintained, and > > that respects the users's freedom, so there's no reason not to include > > it in NonGNU ELPA, regardless if it comes with some bridge for Flymake. > > Agreed. > > > But I'll grant you that it's not 100% orthogonal: If we want to get > > a uniform interface between the two, the first thing to do would be to > > encourage cooperation rather than to put up barriers, so including it in > > NonGNU ELPA could help. > > Yup. Historical kerfuffles notwithstanding, more collaboration and > interoperability can only help, whether or not that means that the > friendly competition[1] between flymake and flycheck remains or not. > > One idea would be to change flymake so that it can support flycheck > backends natively, without needing any third-party packages. That would > already go a long way to decrease the differences between the two > packages. I'd definitely encourage work on that. > > Another thing is that we could use a good built-in macro to define > flymake backends. > > Perhaps Steve Purcell (added to CC) could be convinced to contribute his > excellent flymake-flycheck[2] and flymake-easy[3] packages to core? > This would kill two (or more) birds with one stone, and also remove some > of the gripes that some users have with flymake. > > Footnotes: > [1] If it hasn't always been friendly in the past, there's no reason not > to work on making sure it's friendly going forward. > > [2] https://github.com/purcell/flymake-flycheck > > [3] https://github.com/purcell/flymake-easy > > --a27369f76c9a430182066b8422c2677e Content-Type: text/html Content-Transfer-Encoding: quoted-printable
One idea would be to change flymake so t= hat it can support flycheck
backends natively, without nee= ding any third-party packages.  That would
already go= a long way to decrease the differences between the two
pa= ckages.  I'd definitely encourage work on that.

<= /div>
Another thing is that we could use a good built-in macro to de= fine
flymake backends.

Perhap= s Steve Purcell (added to CC) could be convinced to contribute his
excellent flymake-flycheck[2] and flymake-easy[3] packages to c= ore?
This would kill two (or more) birds with one stone, a= nd also remove some
of the gripes that some users have wit= h flymake.

Pretty reasonable i= deas IMO.

Yup.  Historical kerfuffles notwithstanding, more co= llaboration and
interoperability can only help, whether or= not that means that the
friendly competition[1] between f= lymake and flycheck remains or not.

No argument from me.

On Wed, Feb 21,= 2024, at 10:19 PM, Stefan Kangas wrote:
Stefan Monnier <monnier@iro.umontreal.ca> writes:
<= div>
> Flycheck is a package that's well-written, popul= ar, well-maintained, and
> that respects the users's fr= eedom, so there's no reason not to include
> it in NonG= NU ELPA, regardless if it comes with some bridge for Flymake.
<= div>
Agreed.

> But I'll gr= ant you that it's not 100% orthogonal: If we want to get
&= gt; a uniform interface between the two, the first thing to do would be = to
> encourage cooperation rather than to put up barrie= rs, so including it in
> NonGNU ELPA could help.

Yup.  Historical kerfuffles notwithstanding,= more collaboration and
interoperability can only help, wh= ether or not that means that the
friendly competition[1] b= etween flymake and flycheck remains or not.

One idea would be to change flymake so that it can support flycheck
=
backends natively, without needing any third-party packages.&= nbsp; That would
already go a long way to decrease the dif= ferences between the two
packages.  I'd definitely en= courage work on that.

Another thing is that= we could use a good built-in macro to define
flymake back= ends.

Perhaps Steve Purcell (added to CC) c= ould be convinced to contribute his
excellent flymake-flyc= heck[2] and flymake-easy[3] packages to core?
This would k= ill two (or more) birds with one stone, and also remove some
of the gripes that some users have with flymake.

Footnotes:
[1]  If it hasn't always been fri= endly in the past, there's no reason not
   = ;  to work on making sure it's friendly going forward.



--a27369f76c9a430182066b8422c2677e--