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: [nongnu] main 74116339a8 2/3: * elpa-packages (anzu): New package Date: Thu, 06 Jan 2022 13:35:18 +0000 Message-ID: <87tueh3s2x.fsf@posteo.net> References: <164145738158.2838.5769558384331859964@vcs2.savannah.gnu.org> <20220106082302.0A19CC0DA1E@vcs2.savannah.gnu.org> <87k0fdmbat.fsf@posteo.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10012"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Stefan Kangas Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Jan 06 15:17:36 2022 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 1n5TaC-0002Ob-Fq for ged-emacs-devel@m.gmane-mx.org; Thu, 06 Jan 2022 15:17:36 +0100 Original-Received: from localhost ([::1]:33532 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n5TaA-0004Nr-Tg for ged-emacs-devel@m.gmane-mx.org; Thu, 06 Jan 2022 09:17:34 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:46838) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n5SvM-0008Hk-Vd for emacs-devel@gnu.org; Thu, 06 Jan 2022 08:35:25 -0500 Original-Received: from mout02.posteo.de ([185.67.36.66]:46011) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n5SvK-0004PE-PH for emacs-devel@gnu.org; Thu, 06 Jan 2022 08:35:24 -0500 Original-Received: from submission (posteo.de [89.146.220.130]) by mout02.posteo.de (Postfix) with ESMTPS id 9FD9A240103 for ; Thu, 6 Jan 2022 14:35:20 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1641476120; bh=u0ApYSSz9BVd06d4NOz2xCphAtaRoLgebbVuGTDiVPc=; h=From:To:Cc:Subject:Autocrypt:Date:From; b=SRAcZcqa9mU4/GZfA7NNB4AjudabaMIUcUpolbVCkyaRHFqMZA6u0iwPJhe8e6J2Q /UbaBeWT8rDKu772eIyZ4MPGUDzSopHOSRlKvPbKVA2p+kEeOnu5p3Z7a6lph2Anoc EZmEWAsypoJGdZ2VDHzD7T+XWJen393wWBzFP/3UtLwy6I1pQD/N+TOaFwXvlMWn+8 2no5OTZe4RWpeks4i0z/w5bcwLW18eUFJETNgBQosalCc2vo15CmsLXs5vJCxZn5nZ Ze3HI7uayc2U2Ukkl+LyQ0+dC7/plJO/2c7/gMcQFuB7eBwNUPNs0bqSnTW7usJ6XQ 28IQ2J1MTktmQ== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4JV6mR5tMYz9rxD; Thu, 6 Jan 2022 14:35:19 +0100 (CET) Autocrypt: addr=philipk@posteo.net; prefer-encrypt=nopreference; keydata= mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0 ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB In-Reply-To: (Stefan Kangas's message of "Thu, 6 Jan 2022 04:00:33 -0800") 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 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" Xref: news.gmane.io gmane.emacs.devel:284320 Archived-At: Stefan Kangas writes: > Philip Kaludercic writes: > >> Stefan Kangas writes: >> >>> branch: main >>> commit 74116339a852129b98ff79e2eb3aa35b387aa006 >>> Author: Stefan Kangas >>> Commit: Stefan Kangas >>> >>> * elpa-packages (anzu): New package >> >> Hasn't anzu been obsoleted by isearch-lazy-count? > > I don't know; I don't use isearch these days. I remember using anzu > when I did. > > I add packages mostly based on our formal rules, not on if I think they > are useful or good. Some notable exceptions to this are s.el and f.el, > where we have decided that it is strongly undesirable to promote such > short package prefixes. I have also skipped some other packages that > are clearly obsolete/no longer developed/bad or low effort, etc. I think this might be worth discussing. The impression I get is that a lot of packages/libraries are not being used because they are better, but because they are still recommended on outdated blog posts and fora (think of linum-mode vs. display-line-numbers-mode). More on this below. > I am currently focusing on highly popular packages, and anzu clearly fit > the bill with over 1 million downloads on MELPA.org. It also seems like > it is still maintained, with a new maintainer since March 2020, and > commits as late as October 2021. The "danger" is that MELPA might give the wrong impression of popularity: Their download counter is an absolute number, and does not account for the age of a package or the number of downloads that have been updates (this skews towards older packages and packages with frequent updates), or when a package was updated (this can be manually approximated for some packages via archive.org). > But feel free to tell me why I'm wrong; I'm not married to it and if you > think we should remove it again, I don't think I will have any > objections. This seems to be more of an general, open question on the direction that NonGNU ELPA should head: Do we want to collect as many packages as possible, even if the implementations and practices are sub-optimal, are displaced by alternative implementations in Emacs or ELPA, etc. or should we try to restrict the packages to popular, "good citizens" of the Emacs package space, in an effort to raise the standards and clean up "obsolete" and "redundant" packages. It is probably clear that I have an inclination towards the latter position: Going forward it seems preferable to have as many useful and idiomatic packages available directly via the ELPAs, without burdening newcomers with duplicate functionalities. My motivation in contributing to NonGNU ELPA is to further this goal. >From my restricted understanding of Emacs' history (mostly due to my age), MELPA and EmacsWiki before it contributed a substantial improvement (more packages, cleaner code, usage of libraries, ...) next to their respective formal improvements (package.el support, a centralised location for packages). It seems to me that MELPA leans towards completeness, adding anything from serious packages to fun and jokes. While I do understand the motivation/advantages, it appears to fuel the "there is a package for that" mentality (parallel to Apple's "there is an app for that"-slogan), that implies to download a package for every little change, instead of writing or even copying some Elisp. Given that package.el still makes it difficult to maintain your own changes while updating packages, I understand why people falsely claim Emacs has a "plug-in" system. (From what I remember you were intending to present a talk on a related topic at EmacsConf last year, right?) > BTW, maybe this should be raised as a ticket on the anzu bug tracker? What could they do with this information? I guess they would disagree, and that would be it. -- Philip Kaludercic