[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#62751: 29.0.90; New libraries that still need to be assigned to pack
From: |
Jonas Bernoulli |
Subject: |
bug#62751: 29.0.90; New libraries that still need to be assigned to packages |
Date: |
Mon, 18 Sep 2023 00:06:33 +0200 |
Thanks!
Stefan Kangas <stefankangas@gmail.com> writes:
> Jonas Bernoulli <jonas@bernoul.li> writes:
>> 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?
It is.
>> 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.
Maybe lisp/use-package/bind-key.el should be a separate package (and
maybe it should be moved out of that directory).
>> 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.
Probably not, but "carefully check any additions to package--builtins"
should be added to the release steps.
For the Emacsmirror I run code similar to `finder-compile-keywords'.
(I don't use that function, mainly because I need more details for the
Emacsmirror database, but also because for the last few releases there
have always been issues like this, which I had to override.)
For 29.1 I opened this issue, for 28.1 bug#55388. I have done that
early enough so that it could have been taken into account before these
releases shipped with questionable entries in package--builtins.
I intend to do that well before the next release again.
By the way, IMO it would make sense to apply these on "emacs-29", not
just "master".
>> Speaking of finder--builtins-alist, what about adding these entries?:
>> ("leim" . emacs)
>> ("obsolete" . emacs)
>
> Done.
I think that has to be extended for "leim", similar to how there is a
separate entry for every subdirectory of "lisp/semantic":
("leim" . emacs)
+("ja-dic" . emacs)
+("quail" . emacs)
In addition to adding an entry for "lisp/obsolete", the "Package" header
should be removed from all files in that directory.
Please also have a look at bug#55388, a similar report for Emacs 28.1,
which also has not been fully addressed yet.
"lisp/emacs-lisp/shorthands.el" should provide a feature and be added to
the "emacs" package.
- bug#62751: 29.0.90; New libraries that still need to be assigned to packages, Stefan Kangas, 2023/09/05
- bug#62751: 29.0.90; New libraries that still need to be assigned to packages, Stefan Kangas, 2023/09/16
- bug#62751: 29.0.90; New libraries that still need to be assigned to packages,
Jonas Bernoulli <=
- bug#62751: 29.0.90; New libraries that still need to be assigned to packages, Stefan Kangas, 2023/09/18
- bug#62751: 29.0.90; New libraries that still need to be assigned to packages, Eli Zaretskii, 2023/09/18
- bug#62751: 29.0.90; New libraries that still need to be assigned to packages, Stefan Kangas, 2023/09/18
- bug#62751: 29.0.90; New libraries that still need to be assigned to packages, Eli Zaretskii, 2023/09/18
- bug#62751: 29.0.90; New libraries that still need to be assigned to packages, Stefan Kangas, 2023/09/20
- bug#62751: 29.0.90; New libraries that still need to be assigned to packages, Stefan Monnier, 2023/09/20
- bug#62751: 29.0.90; New libraries that still need to be assigned to packages, Stefan Kangas, 2023/09/21
- bug#62751: 29.0.90; New libraries that still need to be assigned to packages, Stefan Monnier, 2023/09/21
- bug#62751: 29.0.90; New libraries that still need to be assigned to packages, Stefan Kangas, 2023/09/22
- bug#62751: 29.0.90; New libraries that still need to be assigned to packages, Eli Zaretskii, 2023/09/21