bug#62751: 29.0.90; New libraries that still need to be assigned to packages

[Stefan Kangas]

fixed 62751 30.1
thanks

Jonas Bernoulli <jonas@bernoul.li> 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.