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: Thu, 22 Feb 2024 08:15:17 +0100 Message-ID: <3e7f0437-f84e-470a-936c-c2c5ef3b493e@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> <553db84b-e29b-4622-a02d-77e250f2d1d2@gutov.dev> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=a83c0de7ae00450f9ed56c26e2591e75 Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29663"; 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" , "Steve Purcell" To: "Dmitry Gutov" , "Stefan Kangas" , "Stefan Monnier" , "Philip Kaludercic" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Feb 22 08:16:10 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 1rd3JO-0007Lu-QO for ged-emacs-devel@m.gmane-mx.org; Thu, 22 Feb 2024 08:16:08 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rd3J3-0006lC-Ty; Thu, 22 Feb 2024 02:15:45 -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 1rd3J2-0006kE-Aw for emacs-devel@gnu.org; Thu, 22 Feb 2024 02:15:44 -0500 Original-Received: from wfhigh3-smtp.messagingengine.com ([64.147.123.154]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rd3Iz-0006ZY-W3 for emacs-devel@gnu.org; Thu, 22 Feb 2024 02:15:44 -0500 Original-Received: from compute7.internal (compute7.nyi.internal [10.202.2.48]) by mailfhigh.west.internal (Postfix) with ESMTP id 5696418000B3; Thu, 22 Feb 2024 02:15:39 -0500 (EST) Original-Received: from imap52 ([10.202.2.102]) by compute7.internal (MEProxy); Thu, 22 Feb 2024 02:15:40 -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=1708586138; x=1708672538; bh=1VWFswJQl0 hDXL3ovAnh68I7LZXZAd2IkepdwcrSmUo=; b=TgqHAXLUxW1gSaSjcrkF/lPGq0 z+1FbtwgKzIVr3grsFbjk3/eE6pWEpR+ZqLVBizbqdAUfr/BKZitB+vdhsh0q1mX Ygeg0sgojSW3nr/t/2PBHhUVEFj1rr3HN5zASWsdjkqPA+wNtjVg0tktaO6Wmpu8 lU382MuEcROTZ4789wdEKTkZJhC5m0Gf48KxvyeWygaJT/WtyA9BFvw6fS/VuPj9 OOgUw4csf2vCYdCSNcwpGThpaqbZ8CbX48T2KZbMmrAX2xo/tBuON//7/GDE6mg8 3cn4ziipajluX0ydrvmbF54l6Iwqx1BPosyVkMJOJGRWzN0kROu24DHx/H2A== 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=1708586138; x=1708672538; bh=1VWFswJQl0hDXL3ovAnh68I7LZXZ Ad2IkepdwcrSmUo=; b=JIyQzmxzM+FOx3+XvMokgiRUZdlgvybR0UK0koayx03L lfXLRABj/IrDS1AkgNW9cYU5efdgvjdGUhZLEMfDR487Sr4hUG4BD2vgwXz9q4wb ebU/u1TcfuEN7AXZvGFzjyWmh9uHB0+oU3lvPnfhUxRTQgWf32NxmRCCbvKGvZ/h lrWHrwea8WuuOPA6dblPy7RgU2i7GsB1WJC2Dk/L4HFIylUbK5XyqRUlCryPEVZS VR79ZdNrhgyncGqU9clNwdwTmWYUbQMjvfhZEbfQV2jWHYzfk5Wdv07OaCO44nat m7O62UWNHAQJi731UoBk+8kqqlgNmZYPnxKNCGXQBA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrfeefgddutdegucetufdoteggodetrfdotf 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 2EEF5C60097; Thu, 22 Feb 2024 02:15:38 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface In-Reply-To: <553db84b-e29b-4622-a02d-77e250f2d1d2@gutov.dev> Received-SPF: pass client-ip=64.147.123.154; envelope-from=bozhidar@batsov.dev; helo=wfhigh3-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:316441 Archived-At: --a83c0de7ae00450f9ed56c26e2591e75 Content-Type: text/plain I can look at the options here at a later point. I haven't had much time to think about the future, given that I've assumed the Flycheck maintenance relatively soon. My short-term focus is harvesting some low-hanging fruit (like the package inclusion on NonGNU ELPA). Compiling a reasonable long-term vision for the future (including some form of built-in interop with Flymake) will take some time and I think it'd better to discuss this separately. > On 21/02/2024 23:19, Stefan Kangas wrote: > > > 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. > > There doesn't seem much point in having flymake-flycheck in the core > when flycheck is still required to use most of its backends (they're > part of the package). It also depends on flycheck at runtime anyway. > > flymake-easy has another problem: IIUC it hasn't been updated for 10 > years, and as such only uses the obsolete Flymake protocol (one we keep > in flymake-proc.el for compatibility). It also employs defadvice. > > Back to flymake-flycheck, I wonder if it would be a better idea to have > it as part of the flycheck package itself (fewer things to install and > enable separately). But then it's not obvious at which point the > checkers should be made available to flymake. If that happens when > flycheck-mode is enabled, that would be too late: at that point the user > has seemingly indicated that they want to use flycheck as UI as well. > > > [2] https://github.com/purcell/flymake-flycheck > > > > [3] https://github.com/purcell/flymake-easy > > > --a83c0de7ae00450f9ed56c26e2591e75 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
I can look at t= he options here at a later point. I haven't had much time to think about= the future, given that I've assumed the Flycheck maintenance relatively= soon. My short-term focus is harvesting some low-hanging fruit (like th= e package inclusion on NonGNU ELPA).

Compil= ing a reasonable long-term vision for the future (including some form of= built-in interop with Flymake) will take some time and I think it'd bet= ter to discuss this separately.

On 21/02/2024 23:19, Stefan Kangas w= rote:

> Another thing is that we could u= se a good built-in macro to define
> flymake backends.<= br>
> 
> Perhaps Steve Purcell (added= to CC) could be convinced to contribute his
> excellen= t flymake-flycheck[2] and flymake-easy[3] packages to core?
> This would kill two (or more) birds with one stone, and also remo= ve some
> of the gripes that some users have with flyma= ke.

There doesn't seem much point in having= flymake-flycheck in the core 
when flycheck is still= required to use most of its backends (they're 
part = of the package). It also depends on flycheck at runtime anyway.

flymake-easy has another problem: IIUC it hasn't be= en updated for 10 
years, and as such only uses the o= bsolete Flymake protocol (one we keep 
in flymake-pro= c.el for compatibility). It also employs defadvice.

Back to flymake-flycheck, I wonder if it would be a better idea= to have 
it as part of the flycheck package itself (= fewer things to install and 
enable separately). But = then it's not obvious at which point the 
checkers sh= ould be made available to flymake. If that happens when 
<= div>flycheck-mode is enabled, that would be too late: at that point the = user 
has seemingly indicated that they want to use f= lycheck as UI as well.

> 

=


--a83c0de7ae00450f9ed56c26e2591e75--