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: Mon, 19 Feb 2024 18:53:26 +0000 Message-ID: <87le7g9tg9.fsf@posteo.net> References: <41bdb94a-3f9c-4b46-b061-b0c5e31a403e@app.fastmail.com> <871q98bb7q.fsf@posteo.net> <72490bec-175b-46b6-aaf9-153b3c242b70@app.fastmail.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27866"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "Emacs Devel" To: "Bozhidar Batsov" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Feb 19 19:54:18 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 1rc8mP-00073Y-CC for ged-emacs-devel@m.gmane-mx.org; Mon, 19 Feb 2024 19:54:17 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rc8lj-00083E-PD; Mon, 19 Feb 2024 13:53:36 -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 1rc8lh-000834-QA for emacs-devel@gnu.org; Mon, 19 Feb 2024 13:53:33 -0500 Original-Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rc8lf-0003kJ-AI for emacs-devel@gnu.org; Mon, 19 Feb 2024 13:53:33 -0500 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 32965240027 for ; Mon, 19 Feb 2024 19:53:28 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1708368808; bh=phAJ5RnTNLdiNEMwCG0ju3kmO+Dt6W0ipdq3YZ3G1l4=; h=From:To:Cc:Subject:OpenPGP:Date:Message-ID:MIME-Version: Content-Type:From; b=ieMthLxXDX0bMY+28ry04e3mcOxaUDfRmC4EdF8CFLagEDb2oNPD5DCGUbbLMTayu KsJHNqXHuLrTzyvF8BnKPQQi/QaF1Vug9LPkmg+Ns4cGddC7w11/svi/x6zL93ySzy 4Uo7dI2rnxOxaaMTW+i/EFltIOzEyoEXf5tSpPSOx1PuzBCxqQt5qnwNWv2q2NA0gW zGh6E/o2+LFadoccRBZ8oUpzTejBLcJephanKG+dEarLcgDu5t9srEuo6YiA/ryJs6 tLcpxf8D+eSdtky8IXsunk/1IW6+UpkjKV0CWMMMuUoCrWoNs2GvuVDooYlrxTEzoa QKT4la613S/bQ== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4TdsBH0QqLz6twS; Mon, 19 Feb 2024 19:53:27 +0100 (CET) In-Reply-To: <72490bec-175b-46b6-aaf9-153b3c242b70@app.fastmail.com> (Bozhidar Batsov's message of "Mon, 19 Feb 2024 20:08:15 +0200") OpenPGP: id=7126E1DE2F0CE35C770BED01F2C3CC513DB89F66; url="https://keys.openpgp.org/vks/v1/by-fingerprint/7126E1DE2F0CE35C770BED01F2C3CC513DB89F66"; preference=signencrypt Received-SPF: pass client-ip=185.67.36.65; envelope-from=philipk@posteo.net; helo=mout01.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:316363 Archived-At: "Bozhidar Batsov" writes: > There is a detailed comparison here > https://www.flycheck.org/en/latest/user/flycheck-versus-flymake.html >From what I see, this comparison is outdated and somewhat one-sided. Flymake has error explanations, and categories like "Automatic syntax checking" seem disingenuous if the complaint is that there is not a flymake-global-mode. (It would have probably taken less time to write a `define-globalized-minor-mode', than the time to write this point...) > but many of the differences are probably not important to many > people. You might remember that before Flycheck, Flymake was in a > state of disarray and abandoment for years, so I'm pretty sure > Flycheck making it almost obsolete back then was the trigger for some > modernization around Emacs 26.1. Could you explain how this relates to the current state of Flymake vs. Flycheck? The fact that Flymake caught up, and in my eyes deprecated Flycheck, seems like a success story. > And the contributors to Flycheck and > Flymake were always pretty different - part of the reason Sebastien > (the original author of Flycheck) quit Emacs were some attacks he was > getting on emacs-devel. For the sake of a constructive discussion, please don't make claims like these without any further references. Provocations like these, from anyone, only make discussions like these more difficult. > Many people are so off-put by the discourse there, that they want to > have as little as possible with it. And that's the real value of > alternative packages IMO - they allow us to harvest the energy of all > contributors. I don't think this is the problem you are making it out to be, and even if it were, one could have a package like flymake-collection added to NonGNU ELPA. > Btw, flymake-flycheck was created only because Joao wouldn't agree to > provide Flycheck support in Eglot (I know this from the author of > flymake-flycheck). The whole situation with Elgot was a classic > example of the hostility in Emacs towards packages some maintainers > dislike... (https://github.com/joaotavora/eglot/issues/42) I don't know how you infer, but again, it would be nice to keep the discussion here on-topic instead of bringing up old drama between GNU-adjacent/core development and MELPA/GitHub/anti-GNU people. >> but considering that >> more and more people rely on LSP for the information (and Eglot supports >> Flymake OOTB), I don't know how valuable this is. > > Btw, Eglot is not the only LSP client for Emacs. :-) lsp-mode users > flycheck by default for its error diagnostics. I'm not a big LSP user, > though, and often prefer the simplicity of just shelling out to > whatever lint tools I need. The "lsp-mode" is not part of NonGNU ELPA, so I don't think that is a problem in this case. > You probably know that Flycheck is one of the most download packages > on MELPA, so it has plenty of happy users. I do not follow MELPA development or statistics, but from what I recall these are just accumulated downloads over all versions, right? If so, then the information we get from this fact is rather low. (BTW. if we are to implement this feature for ELPA, then we should pay attention to avoid this mistake, and only display the download counts over some fixed time interval, e.g. the information currently available in the access logs.) > > I'm one of them and that's > why I took over the maintenance of the project. I felt that NonGNU > ELPA existed to make it easier for popular stuff to be installed by > users, but it seems to me MELPA won't be going away any time soon. NonGNU ELPA is not only a means of making more useful packages readily available to users OOTB (without having to search online blogs and fora for code snippets that enable third-party archives and install dozens of weirdly named packages replicating built-in functionality), but also a chance to clean up the package landscape, and prune away some experiments from the 2010s. As you say, people will continue maintaining third-party repositories that accept every brittle little scripts anyone writes (I speak here from experience and personal suffering), but I think it is a feature that ELPA has a more curated policy. I for my really try my best to raise the bar of package submissions, and while it is not always easy, I hope that this helps make the system more robust for everyone. So once more, please do not assume malice in these discussions, I don't think anyone here hates one another or intentionally wants to hinder them personally. It takes effort to take others seriously, but it is worth undertaking if we want to make Emacs better. 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. > On Mon, Feb 19, 2024, at 7:44 PM, Philip Kaludercic wrote: >> "Bozhidar Batsov" writes: >> >> > Hey everyone, >> > >> > Just wanted to ask if there's any interested in adding Flycheck >> > (https://www.flycheck.org/en/latest/), a popular alternative to >> > Flymake, to NonGNU ELPA? >> > >> > You can find the codebase here https://github.com/flycheck/flycheck >> > There's also some integration with Eglot https://github.com/flycheck/flycheck-eglot >> > >> > I'm not sure what's the stance of adding alternatives to built-in >> > packages in general, but I think providing some alternatives to the >> > end users is not a bad thing overall. >> >> My main question is what advantage Flycheck has over Flymake. I >> understand it has a database of tools built-in, but considering that >> more and more people rely on LSP for the information (and Eglot supports >> Flymake OOTB), I don't know how valuable this is. In addition to that, >> there are projects like >> >> https://github.com/mohkale/flymake-collection >> https://github.com/purcell/flymake-flycheck >> >> that could help bridge the gap. >> >>