bug#55388: 28.1; New libraries that neither belong to a package nor provide a feature

bug#55388: 28.1; New libraries that neither belong to a package nor provide a feature

[Jonas Bernoulli]

"lisp/emacs-lisp/shorthands.el" doesn't provide a feature and lacks
a "Package" library header.  I think "Package: emacs" should be added.

Like other files in that directory "lisp/leim/quail/cham.el" neither
provides a feature nor is it explicitly made part of a package.  Would
it make sense to add ("leim" . emacs) to `finder--builtins-alist'?

Maybe another such entry should be added for the "obsolete" directory?

Unlike other "epa-*" libraries, "lisp/epa-ks.el" isn't made part of
the "epa" package and fails to provide a feature.

bug#55388: 28.1; New libraries that neither belong to a package nor provide a feature

[Lars Ingebrigtsen]

Jonas Bernoulli <jonas@bernoul.li> writes:

> "lisp/emacs-lisp/shorthands.el" doesn't provide a feature and lacks
> a "Package" library header.  I think "Package: emacs" should be added.
>
> Like other files in that directory "lisp/leim/quail/cham.el" neither
> provides a feature nor is it explicitly made part of a package.  Would
> it make sense to add ("leim" . emacs) to `finder--builtins-alist'?

Are all .el files supposed to have either a Package: header or a
`provides' these days?  I wasn't aware of that...

Hm...  I see that Chong did something like that with all the preloaded
.el files in bd78fa1d544, so I guess that's true?

> Maybe another such entry should be added for the "obsolete" directory?
>
> Unlike other "epa-*" libraries, "lisp/epa-ks.el" isn't made part of
> the "epa" package and fails to provide a feature.

I think it's separate thing, but it should have a provides, so I've now
added that.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#55388: 28.1; New libraries that neither belong to a package nor provide a feature

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Jonas Bernoulli <jonas@bernoul.li> writes:
>
>> "lisp/emacs-lisp/shorthands.el" doesn't provide a feature and lacks
>> a "Package" library header.  I think "Package: emacs" should be added.

The same is true for smie.el, syntax.el, tabulated-list.el, testcover.el
and possibly others.  Should they have such a header as well?

>> Like other files in that directory "lisp/leim/quail/cham.el" neither
>> provides a feature nor is it explicitly made part of a package.  Would
>> it make sense to add ("leim" . emacs) to `finder--builtins-alist'?
>
> Are all .el files supposed to have either a Package: header or a
> `provides' these days?  I wasn't aware of that...
>
> Hm...  I see that Chong did something like that with all the preloaded
> .el files in bd78fa1d544, so I guess that's true?

It seems like it's not consistent.  What do we use such a header for?

bug#55388: 28.1; New libraries that neither belong to a package nor provide a feature

[Lars Ingebrigtsen]

Stefan Kangas <stefan@marxist.se> writes:

>> Hm...  I see that Chong did something like that with all the preloaded
>> .el files in bd78fa1d544, so I guess that's true?
>
> It seems like it's not consistent.  What do we use such a header for?

The commit message only says:

    Add "Package:" file headers to denote built-in packages.

So...  I don't know?  Perhaps Stefan M remembers; added to the CCs.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#55388: 28.1; New libraries that neither belong to a package nor provide a feature

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> Jonas Bernoulli <jonas@bernoul.li> writes:
>>> "lisp/emacs-lisp/shorthands.el" doesn't provide a feature and lacks
>>> a "Package" library header.  I think "Package: emacs" should be added.
> The same is true for smie.el, syntax.el, tabulated-list.el, testcover.el
> and possibly others.

Hmm... smie.el, syntax.el, and tabulated-list.el do `provide`
themselves, AFAICT.  Indeed it seems to be missing from `testcover.el`.

> Should they have such a header as well?
[...]
> It seems like it's not consistent.  What do we use such a header for?

IIRC the question is whether we want to present these files as "a
package" or as "a file part of some other package" in things like
the finder.


        Stefan

bug#55388: 28.1; New libraries that neither belong to a package nor provide a feature

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Hmm... smie.el, syntax.el, and tabulated-list.el do `provide`
> themselves, AFAICT.  Indeed it seems to be missing from `testcover.el`.

Yup.  I've now added one.

>> Should they have such a header as well?
> [...]
>> It seems like it's not consistent.  What do we use such a header for?
>
> IIRC the question is whether we want to present these files as "a
> package" or as "a file part of some other package" in things like
> the finder.

So somebody should go through all the files that lack a package: and see
if they feel it belongs in some package?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#55388: 28.1; New libraries that neither belong to a package nor provide a feature

[Stefan Kangas]

Version: 29.2

Jonas Bernoulli <jonas@bernoul.li> writes:

> "lisp/emacs-lisp/shorthands.el" doesn't provide a feature and lacks
> a "Package" library header.  I think "Package: emacs" should be added.

Done.

> Like other files in that directory "lisp/leim/quail/cham.el" neither
> provides a feature nor is it explicitly made part of a package.  Would
> it make sense to add ("leim" . emacs) to `finder--builtins-alist'?
>
> Maybe another such entry should be added for the "obsolete" directory?

Fixed in Bug#62751.

> Unlike other "epa-*" libraries, "lisp/epa-ks.el" isn't made part of
> the "epa" package and fails to provide a feature.

Done.

Thanks for paying attention to this aspect.  I installed the fixes on
emacs-29 (commit 71a1f0fdc9e), and am consequently closing this bug
report.