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: Wed, 21 Feb 2024 20:19:19 +0200 Message-ID: <723d6c19-8865-4155-97e7-5aa5e1f89e04@gutov.dev> 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> 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="23683"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: joakim@verona.se, Bozhidar Batsov , Emacs Devel To: Philip Kaludercic Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Feb 21 19:20:13 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 1rcrCX-0005w4-5f for ged-emacs-devel@m.gmane-mx.org; Wed, 21 Feb 2024 19:20:13 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rcrBu-0005Uc-Jv; Wed, 21 Feb 2024 13:19:34 -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 1rcrBp-0005RH-66 for emacs-devel@gnu.org; Wed, 21 Feb 2024 13:19:30 -0500 Original-Received: from wout5-smtp.messagingengine.com ([64.147.123.21]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rcrBm-0002he-I8 for emacs-devel@gnu.org; Wed, 21 Feb 2024 13:19:28 -0500 Original-Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 54C8B3200A3B; Wed, 21 Feb 2024 13:19:23 -0500 (EST) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Wed, 21 Feb 2024 13:19:23 -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=1708539562; x=1708625962; bh=5ZGQ1VBzdek/XyUmbG8wKWG+uqq6JiiJbFwubr1S2A8=; b= CvisWFQdfpeYwTP17L5c1ALMKVQQNXb+SPPCZTTL7Bj4kwIBtsp6aYPDqxWAmKWV ZdBWOhQJaEfT9yP2AYMUFuSUEbTTWZUusbrTO3t4rwH1bisIvckDjaqdKBOp/PV0 EYy3aZ3Wrgy3PS4ITNM+R3HNEZUhMDwAs96lcJM45rV5x/uFt6cFIZxMbmK62bDr BzgdQzEhbw1tBs2kK3REBgQ5wienzMhblljZp82rW8viO7wIkvGXBD5OVke/ZqPE xJQYrkzqUPyChRcRerb8xCdNUaDE9y5sFZ2ohzBLD3/HgNck6lTWB2TBKNg+QXWo S79mUmVQ8zNPK/uyFF2aRg== 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=1708539562; x= 1708625962; bh=5ZGQ1VBzdek/XyUmbG8wKWG+uqq6JiiJbFwubr1S2A8=; b=I CuVJP0OgRDwY6Xj9cKhJGB20JHZ8RdO4oJ5KuWySYO5kt3UHe7BiyenGHIlr3aNd +84UOkgJZqKIm22JzHuCk6k8RqiHVXhSdzPJREev9QmfXneMERTnHrU+EgWyq6rJ RvKJzyp+q1UqFs3X0VFCvgRjAw4aeCxSET2bVTrea3Ar9sghnBK6FUhZKIpBqU+R DmtaLHtrI7sHDuPH3LaPmSqEQiVgUuhVt6u4+ROOdcT1BknzGpzPNLydVFMWzc59 RJBorVswyplumK3NRNHKLsEP9Qu2czN8R42a36zwFy7huwqyLtNmwDauoS3YnvqU VfqXxcFJdX3lqMXH6Tpow== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrfedvgdduuddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtvdejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepteduleejgeehtefgheegjeekueehvdevieekueeftddvtdevfefhvdevgedu jeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 21 Feb 2024 13:19:21 -0500 (EST) Content-Language: en-US In-Reply-To: <874je1ycpk.fsf@posteo.net> Received-SPF: pass client-ip=64.147.123.21; envelope-from=dmitry@gutov.dev; helo=wout5-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, 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:316426 Archived-At: 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.