From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: Adding Flycheck to NonGNU ELPA Date: Tue, 20 Feb 2024 22:04:33 +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> <874je413vo.fsf@tanaka.verona.se> <87le7f1hlq.fsf@posteo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32843"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: Bozhidar Batsov , Emacs Devel To: Philip Kaludercic , joakim@verona.se Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Feb 20 21:05:23 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 1rcWMk-0008Dm-IJ for ged-emacs-devel@m.gmane-mx.org; Tue, 20 Feb 2024 21:05:23 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rcWM8-0002CG-Au; Tue, 20 Feb 2024 15:04:44 -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 1rcWM6-0002Bt-MP for emacs-devel@gnu.org; Tue, 20 Feb 2024 15:04:42 -0500 Original-Received: from wout3-smtp.messagingengine.com ([64.147.123.19]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rcWM4-000536-Il for emacs-devel@gnu.org; Tue, 20 Feb 2024 15:04:42 -0500 Original-Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 975023200A16; Tue, 20 Feb 2024 15:04:37 -0500 (EST) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Tue, 20 Feb 2024 15:04:38 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding: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=fm2; t=1708459477; x=1708545877; bh=ev4BLAnpqsuD0AvOu9koH12s13LTdlAWqsxO8GM2jlc=; b= eYzWH1WOHO3eJs4HH/LYDZ2Xgok5jMJmURcTcacjAGPkTmmYIJ9OXryYHG82Xfc9 e85JdNxq2m1s8AimkSjHuFwVFMuSgQTnnUBAnpyQD2bhQtHce5Nlex2j2ogJFHy9 V19qf656wS+ZtROgUCLoPg8eWjqVsNQJwELb1pYteca0Rj5c0vo64EG2vHR4XOF5 /9cb+oysT6XuXNWXA08ByLyQzs2F3UnRhk+u3QVEG9SrX88zhLb4GRknqqAxbKD1 kDr4dwkcaDmp4i8j4vJcZIqhS5vbzbUWKXX1rD5OJZNfTP4RD7Ru3rsn7zK0eXAl KiPeq5maRj9b30f2teLgoQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :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=1708459477; x= 1708545877; bh=ev4BLAnpqsuD0AvOu9koH12s13LTdlAWqsxO8GM2jlc=; b=p EKnF1ubqvi6BT2RQ79I8r1grtbRYM7d84tyfC7yXOo+5JTY0H9za2lpxxdz3f2MK mIyy4Gm3ZV7IekhehlQf5zHhgCOTAqH1tX22ulxtjBJQwddzQ1qFgXHHyhkav005 mdf5+TPI0FGuxonZVa8ScmaRh9bxIDw350hbiSh0Dx78nymk+gWO0rus0ob34Uz2 22ErkINl0TrtDP6thtctJD72Ule/jaFJVxeLtEILsQNVJubEwbbOBXBm0aJsNMEv RxdpSerpwo89xJK4gx2ZGc2JT45cxTVhb5pzoOISmmSPv4WzTGvq7FzeDUpcaJ/f kwJTdChe3d6iwoGqwoJug== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrfedtgddufeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtvdejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepfeekheeuteeigeevledtjeefheefheehjeehkeeuhfeffeelveffleehfefh vdevnecuffhomhgrihhnpehgihhthhhusgdrtghomhenucevlhhushhtvghrufhiiigvpe dtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumhhithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 20 Feb 2024 15:04:35 -0500 (EST) Content-Language: en-US In-Reply-To: <87le7f1hlq.fsf@posteo.net> Received-SPF: pass client-ip=64.147.123.19; envelope-from=dmitry@gutov.dev; helo=wout3-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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, 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:316404 Archived-At: 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. >> It might be an improvement, but AFAIK Flycheck still has an order of a >> magnitude more checkers. >> >> Offhand, >> https://github.com/mohkale/flymake-collection/tree/release/src/checkers >> doesn't include anything for Rust or Golang. >> >> And Flycheck has several for both. > > This appears to be true, but this is not an inherent advantage, just the > fact that people have invested effort into it. It seems to be that a > significant reason is that Flycheck has a convenient language for > defining checkers, something that IIUC flymake-collection is also > working on. Giving this basis, we could look into perhaps even > automatically translating the Checker specifications, which would help > further "obsolete" Flycheck, given that this is apparently the only real > "advantage" it provides (which again, is not architectural, just the > accumulated labour over the last decade). Nobody stops people from working on Flymake, improving the documentation and developer experience, and the list of built-in checkers. In fact, I'm pretty sure this will happen faster with healthy competition in sight. >>>> It also has a minor mode map, to invoke the errors buffer or jump >>>> between the errors. Though the latter is easy-ish to port over. >>> I agree, that that is an annoyance. I have personally bound >>> `flymake-goto-next-error' and `flymake-goto-prev-error' to M-n and M-p >>> respectively, but it would be nice if we could find some keys to bind >>> these commands to. >> >> Same. > > I'll look into submitting a bug report to propose such a change. Very good. > I wouldn't put it that way, but as mentioned above I do think that > pushing towards a consistent UI that aligns with Emacs strengths > (text-based, buffers in windows, ...) is worth the effort, even if some > projects have to change or die in the process. E.g. a positive example: > I added support for the "dumb-jump" to use Xref instead of > re-implementing the UI with custom commands and popups. People appear > to use that now. 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). A counter-example is Projectile, which predated project.el, and which we included in NonGNU ELPA to no particular detriment. >> Let's remove Helm from NonGNU, then: its UI paradigm is also different >> from the core Emacs, and IMHO it's rather ugly. And swiper/ivy from >> ELPA, just because. > > While I am not a fan of Helm, it was initially added to provide popular > packages that a number of people appeared to want to use. Luckily these > packages fall into the category of providing the front-end of a shared > interface (completing-read; and that not without issues, because they > tend to abuse completing-read's text expansion idea by focusing on > narrowing and selecting). Yes, Helm provides some support for completing-read, but it also has its own specific API which is bigger and more tailored for its UI, and is the reason there are Helm-specific plugins. > And yes, there are packages that have hard > dependencies on Helm, but usually when people submit these kinds of > packages, we at least mention the idea of trying to generalise them, so > that the front- and back-end can be disentangled from one another. We can both accept Flycheck and suggest the maintainers work toward someday having a compatible API, at least on the functional level. > 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. 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.