From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Kangas Newsgroups: gmane.emacs.bugs Subject: bug#62751: 29.0.90; New libraries that still need to be assigned to packages Date: Sat, 16 Sep 2023 07:23:23 -0700 Message-ID: References: <87zg7fyjka.fsf@bernoul.li> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28568"; mail-complaints-to="usenet@ciao.gmane.io" To: Jonas Bernoulli , 62751@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Sep 16 16:24:17 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1qhWDZ-0007D7-Ne for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 16 Sep 2023 16:24:17 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qhWDE-0001vl-IQ; Sat, 16 Sep 2023 10:23:56 -0400 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 1qhWDC-0001v9-UM for bug-gnu-emacs@gnu.org; Sat, 16 Sep 2023 10:23:54 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qhWDC-00016q-JS for bug-gnu-emacs@gnu.org; Sat, 16 Sep 2023 10:23:54 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qhWDJ-000586-Jr for bug-gnu-emacs@gnu.org; Sat, 16 Sep 2023 10:24:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Kangas Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 16 Sep 2023 14:24:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62751 X-GNU-PR-Package: emacs Original-Received: via spool by 62751-submit@debbugs.gnu.org id=B62751.169487422019688 (code B ref 62751); Sat, 16 Sep 2023 14:24:01 +0000 Original-Received: (at 62751) by debbugs.gnu.org; 16 Sep 2023 14:23:40 +0000 Original-Received: from localhost ([127.0.0.1]:48220 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qhWCy-00057O-8E for submit@debbugs.gnu.org; Sat, 16 Sep 2023 10:23:40 -0400 Original-Received: from mail-lj1-x231.google.com ([2a00:1450:4864:20::231]:59677) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qhWCv-00056x-70 for 62751@debbugs.gnu.org; Sat, 16 Sep 2023 10:23:38 -0400 Original-Received: by mail-lj1-x231.google.com with SMTP id 38308e7fff4ca-2bcd7a207f7so49105431fa.3 for <62751@debbugs.gnu.org>; Sat, 16 Sep 2023 07:23:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1694874204; x=1695479004; darn=debbugs.gnu.org; h=to:subject:message-id:date:mime-version:references:in-reply-to:from :from:to:cc:subject:date:message-id:reply-to; bh=OeBXQvmpGxSepYfzBUPcPJF0BEDNEDboh5OeVkRj8XI=; b=Qcf2DWZxTbwvxFOGAYkUFhXWcV9bxU4iaOu3xzWR0pgvPi33GheXLGmH5H7q2ERiTL 7mZMSozVur9MLRbDtkN4V4jQKPBkVtETS2Bp5vf4+jKRx4w5e/b/uxs4FgGa7aIa2a6S 9oVyLT6DpGGI3OOEuYqUfju05+Yl3zlDOE0ytSjb4dIPPENDqeM0ggY4ScI8FdGZrvdg pE3RGJ39OubKgd3N9UBWPwcJHI7prNH8uUGmPvTJiR4oRaPt5w/P/ymg3G7zE1ozKM9M CQECKf22yA+4YjV5INAXC8MZMdKYJ5R92wmzpcFQteLxiMUHGuoayIEY9JxYCb/lwpq4 PIwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694874204; x=1695479004; h=to:subject:message-id:date:mime-version:references:in-reply-to:from :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=OeBXQvmpGxSepYfzBUPcPJF0BEDNEDboh5OeVkRj8XI=; b=BuymGMRdMGw5bbYpHZtrFPL+XIUG9XOJSFHGaC2h/NkGd/cYSBQqa/qK6LyjJiDSuY jU/dx/WuB3gQ0Lir3XCmoBoyAYlyZHDiGxSOg1wcf9qPUKzGb5k5IGqkf0zJoboZqSNY KUfSIWKk4nNJcxRWlBiw0bVpzR9dJreDNQD1rmMVyKa2023gf3InLNOT9A/PzMBEveRy 9bQz5dKLV0BQMg7sM0cZUo6KYdltHXON4cS3xe09oJ7fdhurjM6dE+qgUZcjmHN2LuYO ZYfv1BURGi42ApONd3cwMaast5tzbvBI9zKDrC5kQ31MFImCS0YLLnBCW0zkyWDD0qlU LErw== X-Gm-Message-State: AOJu0YyhSVjUqIuivrilVSADFp9ctsbe7ujpm6CEyGn374M7pEmIkDZB vZEef7zKiX/ONGKi4u22UMkUgRw6H13mEikj3BM= X-Google-Smtp-Source: AGHT+IG5bW9XYESuYHp0b6mLsceGgBGHfCL87AiCDeqISzgh1S6KxI9StiR0ID9D298BsK9FW7vC8iOyHpQ8cRbhhtI= X-Received: by 2002:a2e:740b:0:b0:2bc:d3a8:974a with SMTP id p11-20020a2e740b000000b002bcd3a8974amr3993650ljc.24.1694874203821; Sat, 16 Sep 2023 07:23:23 -0700 (PDT) Original-Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Sat, 16 Sep 2023 07:23:23 -0700 In-Reply-To: <87zg7fyjka.fsf@bernoul.li> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:270621 Archived-At: fixed 62751 30.1 thanks Jonas Bernoulli writes: > Some new libraries still need to be assigned to a package in > `package--builtins'. > > In some cases it seems clear to me, or at least likely, that we forgot > to declare the package when adding the new library. I.e., that treating > them as packages in their own right, was not intentional, but the result > of that being the fallback behavior when no package is explicitly > specified. Thanks, I've fixed most of these items now. Note that you need to make bootstrap before it will take effect. > 1. ietf-drums-date.el (summary: "parse time/date for ietf-drums.el"), > should be part of ietf-drums. Done. > 3. package-vc.el should probably be treated as a package separate > from Package, to make it easier to distribute Package on GNU ELPA. I think this is already the case, but I copied in Philip in case he has any comments. > 4. All, or most, of the *-ts-mode.el probably should be treated as > separate packages. I might be missing something, but isn't this already the case? > 5. c-ts-common.el should probably not be a separate package. Maybe it > should be part of c-ts-mode, or maybe even all the *-ts-mode.el, that > depend on this library, should be part of a single c-ts-mode? It seems to me an implementation detail of these packages: ./progmodes/js.el:57:(require 'c-ts-common) ; For comment indent and filling. ./progmodes/java-ts-mode.el:32:(require 'c-ts-common) ; For comment indent and filling. ./progmodes/csharp-mode.el:37:(require 'c-ts-common) ; For comment indenting and filling. ./progmodes/c-ts-mode.el:70:(require 'c-ts-common) ./progmodes/typescript-ts-mode.el:33:(require 'c-ts-common) ; For comment indent and filling. ./progmodes/rust-ts-mode.el:32:(require 'c-ts-common) ; For comment indent and filling. I think it makes the most sense to simply make c-ts-common.el a part of the emacs package, and let the others remain as first-class citizens in their own packages. So I made that change. > The following packages are also listed separately in package--builtins, > but I tend to think that is not intentional. > > part of?: > 6. lisp/keymap.el emacs > 7. lisp/emacs-lisp/oclosure.el emacs > 8. lisp/net/tramp-container.el tramp Michael already fixed (8), and I've now fixed 6 and 7. > 9. It seems a bit excessive to consider each use-package*.el a separate > package. Maybe they should all be part of a single use-package > package. An entry in finder--builtins-alist should be used to > accomplish that. Done. > 10. All the lisp/net/eudc*.el should probably be part of a single eudc > package. Done. > 11. All the lisp/image/image-dired*.el should probably be part of a > single image-dired package. Done. > Maybe we should stop falling though to assign a new library to its own > separate package, if nothing else is specified explicitly? It is of > course nice not having to either add a "Package" library header or a > finder--builtins-alist entry, but it also makes it easy to forget to > explicitly specify the package when doing that would be necessary. Hmm, yes that might make more sense. One would have to add package statements to a ton of libraries, though. So there'll be a lot of churn. Maybe it's worth it in the end, I don't know. > Speaking of finder--builtins-alist, what about adding these entries?: > ("leim" . emacs) > ("obsolete" . emacs) Done.