From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Philip Kaludercic Newsgroups: gmane.emacs.devel Subject: Re: Adding Flycheck to NonGNU ELPA Date: Tue, 20 Feb 2024 11:48:49 +0000 Message-ID: <87le7f1hlq.fsf@posteo.net> 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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35649"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Dmitry Gutov , Bozhidar Batsov , Emacs Devel To: joakim@verona.se Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Feb 20 12:49:45 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 1rcOd6-000920-OP for ged-emacs-devel@m.gmane-mx.org; Tue, 20 Feb 2024 12:49:44 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rcOcM-0003nA-Vf; Tue, 20 Feb 2024 06:48:58 -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 1rcOcL-0003mq-7q for emacs-devel@gnu.org; Tue, 20 Feb 2024 06:48:57 -0500 Original-Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rcOcI-000680-OA for emacs-devel@gnu.org; Tue, 20 Feb 2024 06:48:57 -0500 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id A1F69240101 for ; Tue, 20 Feb 2024 12:48:51 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1708429731; bh=YZtT+UVKZS19xyPuh9LP0S9C2QHpSTuTB/eKUYhGGqo=; h=From:To:Cc:Subject:OpenPGP:Date:Message-ID:MIME-Version: Content-Type:From; b=PvR2E2QGer9tF93nXYKEeDS0sG1h0Myx7NuDohxAp5w864Lgb4+ZCDayRiTZxFjG/ BbcjnSK8vyUI16GfDb75aqNSNLlTWcXbFnd0FLAw9bW6whelSpeTBohTYcyKRzW8Nk CvQofqvKpGg+wUi19IM4hNNxfI2s169iBywrhOW1Ax8WHk2tZHlm3/rjTrnpaDiweO iQ1U7p78S9LLoihIqMkZAOQAHbM/q3l2nUv5LoGIfc8buXx1KmGb0x6gjMAxU+1cFa AjCQSb1xRDuenqBzK9WN9YYv2GQ1mVhEYWz8uCeW/hY3C4tvgHRZLVS1DYYaIYRxXH lk90SKRBLcdVg== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4TfHjt0Pytz6tvZ; Tue, 20 Feb 2024 12:48:50 +0100 (CET) In-Reply-To: <874je413vo.fsf@tanaka.verona.se> (joakim@verona.se's message of "Mon, 19 Feb 2024 23:32:59 +0100") OpenPGP: id=7126E1DE2F0CE35C770BED01F2C3CC513DB89F66; url="https://keys.openpgp.org/vks/v1/by-fingerprint/7126E1DE2F0CE35C770BED01F2C3CC513DB89F66"; preference=signencrypt Received-SPF: pass client-ip=185.67.36.66; envelope-from=philipk@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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:316394 Archived-At: joakim@verona.se writes: [...] > Maybe having more alternatives in Elpa/Melpa would actually lead to more > code re-use between the alternatives? That would be nice but I guess > history indicates otherwise. I am afraid that this is not the case, instead of leads to more glue code having to be written. If we want to be more efficient, we should focus on promoting generic interfaces (Xref, Imenu, Flymake, ...) and writing back-end implementations. As an added bonus, we improve the consistency of the user experience. 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. Dmitry Gutov writes: > On 19/02/2024 21:52, Philip Kaludercic wrote: >> Dmitry Gutov writes: >> >>> On 19/02/2024 20:53, Philip Kaludercic wrote: >>>> To this end, I repeat my question: What_technical functionality_ does >>>> Flycheck_currently_ provide that Flymake does not? A different way of >>>> putting it is what architectural advantages does Flycheck exemplify over >>>> Flymake, that give it an inherent edge? If there aren't too many >>>> differences, I think the cost of confusion (Flymake and Flycheck are >>>> names that are easy to confuse) and of inducing choice-fatigue among new >>>> users is not something we should ignore. >>> >>> I'm fairly sure the main answer is "lots of built-in checkers", much >>> more than flymake still has now. >> Do you think that adding "flymake-collection" to NonGNU ELPA could >> help >> improve the situation sufficiently? See also >> https://github.com/mohkale/flymake-collection/issues/2. > > 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). >>> 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. >>> On the subject of choice fatigue, would we hesitate to include >>> lsp-mode in NonGNU ELPA, now that Eglot is in the core? I feel that >>> would be the wrong move. >> FWIW I would argue against it. Setting aside issues of >> dependencies, it >> is my impression that the "lsp-mode" tries to superficially convert >> Emacs into some VSCode like experience, introducing a lot of transient >> information that cannot be operated on normally, popup windows that >> cannot be selected/persisted/searched or otherwise re-creating UI >> features that already exist in Emacs. > > Are we going to police UIs now? 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. > 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). 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. > lsp-mode is not just eye candy anyway. > > Just as I've discovered last week (I'm not a heavy user of either), it > has a handy test runner integration and more reliable errors reporting > (for syntax, etc). And that's with Flymake. > > Also, it's average latency for completion was lower in my benchmarking > not too long ago. Though that's probably the fault of Eglot's > expensive pretty-printing in logging. > > And the popup windows are easily turned off. 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. From what I see there is no reference to any software licenses or where to find the source code. To be fair, this is partially due to the mentality that Microsoft had when writing VSCode (remember that a number of the most popular extensions and servers written by Microsoft are explicitly non-free software that must be used together with the official signed release of VSCode), which the "lsp-mode" developers appears to accept uncritically.