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: Automatic Suggestion of Packages Date: Tue, 12 Nov 2024 03:00:13 +0000 Message-ID: <87ikstf96q.fsf@posteo.net> References: <87ttcjt9ht.fsf_-_@posteo.net> <87o72lmt58.fsf@posteo.de> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23083"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Mekeor Melire Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Nov 12 04:01: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 1tAh9f-0005rC-E2 for ged-emacs-devel@m.gmane-mx.org; Tue, 12 Nov 2024 04:01:23 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tAh8o-00069V-1c; Mon, 11 Nov 2024 22:00:30 -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 1tAh8j-00069G-2W for emacs-devel@gnu.org; Mon, 11 Nov 2024 22:00:26 -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 1tAh8g-0007aJ-US for emacs-devel@gnu.org; Mon, 11 Nov 2024 22:00:24 -0500 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 742DA240101 for ; Tue, 12 Nov 2024 04:00:16 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1731380416; bh=xdwZCyX3JbUYZV5R72JQSy2m4ADv2y/IgaLJnR3t4A8=; h=From:To:Cc:Subject:Autocrypt:OpenPGP:Date:Message-ID:MIME-Version: Content-Type:From; b=UiYe/QIorjo/caiLPJl3x7I5v9TI/1003YFFpSex6p9Qy+4rxPiIGLXOoiZE9vBTs qiWEYD4AnAL3r+klQWaSQg0Prql7vUXmE8RwtdlFpVhmhUQ539FDSPquc9VuuzZzHI 3VJZP7WaGQKDwSeZbPD/3LcCXNvh+uxdp5Y9L3L4m5FVeHB72UlsNm3Z3rVaQT9Q8u ++xEfq70Js/vtmO5aFBy4dQbiUtiZbnsO70H9gtxcpji56rmG7ZEHAOj2IcABIreho oTjRtlzW+gL6kTr1O1j33EGUCqVMoc4sQ9tHS7KkuTavIechCNTPERoE1gYWAP8Po+ rEHsnXCGl5tsw== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4XnWPC3Sdrz9rxD; Tue, 12 Nov 2024 04:00:15 +0100 (CET) In-Reply-To: <87o72lmt58.fsf@posteo.de> (Mekeor Melire's message of "Mon, 11 Nov 2024 20:07:15 +0000") Autocrypt: addr=philipk@posteo.net; keydata= mDMEZBBQQhYJKwYBBAHaRw8BAQdAHJuofBrfqFh12uQu0Yi7mrl525F28eTmwUDflFNmdui0QlBo aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0 ZW8ubmV0PoiWBBMWCAA+FiEEDg7HY17ghYlni8XN8xYDWXahwukFAmQQUEICGwMFCQHhM4AFCwkI BwIGFQoJCAsCBBYCAwECHgECF4AACgkQ8xYDWXahwulikAEA77hloUiSrXgFkUVJhlKBpLCHUjA0 mWZ9j9w5d08+jVwBAK6c4iGP7j+/PhbkxaEKa4V3MzIl7zJkcNNjHCXmvFcEuDgEZBBQQhIKKwYB BAGXVQEFAQEHQI5NLiLRjZy3OfSt1dhCmFyn+fN/QKELUYQetiaoe+MMAwEIB4h+BBgWCAAmFiEE Dg7HY17ghYlni8XN8xYDWXahwukFAmQQUEICGwwFCQHhM4AACgkQ8xYDWXahwukm+wEA8cml4JpK NeAu65rg+auKrPOP6TP/4YWRCTIvuYDm0joBALw98AMz7/qMHvSCeU/hw9PL6u6R2EScxtpKnWof z4oM OpenPGP: id=philipk@posteo.net; url="https://keys.openpgp.org/vks/v1/by-email/philipk@posteo.net"; 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, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:325417 Archived-At: Mekeor Melire writes: > Thanks, Philip, for working on this feature. > > As far as I can tell, your code is based on this workflow: Emacs > maintainers regularly locally build GNU Elpa as well as NonGNU > Elpa. They run the admin/scrape-elpa.el script which updates the > package-autosuggest.eld file that is part of the Emacs Git > repository. They review the changes and commit them. Right. > This has some disadvantages: It is quiet some work for the core Emacs > maintainers: They need to judge if a package is a valid package for a > certain file. This is true, but it would usually be the ELPA maintainers that update package-autosuggest.eld anyway, and I hope it should be manageable to just review the diff. > Only GNU and NonGNU Elpa packages are respected; other > package archives are not. Changes to the package-autosuggest.eld file > would not reach end-users until another Emacs release. These are valid points, though not unsubstantiated. Restricting the packages to {,Non}GNU ELPA is intentional, as all users should have these archives configured (unless they intentionally disabled them, which is unusual AFAIK). These packages should also align with Emacs free-software policy, to ensure that a upfront suggestion to install a package respects user-freedom. That being said, there have been discussions to update the package.el-API (the "archive-contents" file), in which case we could consider providing package suggestions. In that case I would like to add an option to filter what archives are allowed to make suggestions (following the above logic, this would be set to the ELPAs by default, but the user could add personal or third-party if they wish to the list). > More generally, I have the impression that this is not the right place > to implement this feature. I think every package should be able to > suggest itself for certain file extensions (or even file beginnings or > endings like magic-mode-alist). I suggest to introduce a new package > header similar to these: > > ;; Covered-File-Extensions: ("\\.c$" "\\.h$") > ;; Covered-Magic-Beginnings: ("^#!/bin/sh") > > These headers would become part of the package structure and would be > distributed by package archives and would end on the end-users' local > device. In particular, if you have Melpa set up locally, you would be > able to find out which Melpa-packages cover .c extensions by filtering > your local package list accordingly. > > This, of course, is much more work; but it seems to be the right thing > to do, to me. What do you think? The main issue is that we wouldn't have anything to work with right away. We could consider this in the future (along with the updated API idea, where archives could decide on how to implement this on their own), but my question is wouldn't these archives coincide with autoloaded `add-to-list' expressions? When would a package hint that it could be useful for .foo-files, but not update `auto-mode-alist'? The headers might be interesting to hint different priorities, so as to differentiate between something as foundational as a major mode and something nice-to-have like a minor-mode or a set of commands. -- Philip Kaludercic on siskin