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

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

[Jonas Bernoulli]

Hello,

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.

1. ietf-drums-date.el (summary: "parse time/date for ietf-drums.el"),
   should be part of ietf-drums.

3. package-vc.el should probably be treated as a package separate
   from Package, to make it easier to distribute Package on GNU ELPA.

4. All, or most, of the *-ts-mode.el probably should be treated as
   separate packages.

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?

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

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.

10. All the lisp/net/eudc*.el should probably be part of a single eudc
    package.

11. All the lisp/image/image-dired*.el should probably be part of a
    single image-dired package.

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.

Speaking of finder--builtins-alist, what about adding these entries?:
  ("leim" . emacs)
  ("obsolete" . emacs)

     Cheers,
     Jonas

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

[Eli Zaretskii]

> From: Jonas Bernoulli <jonas@bernoul.li>
> Date: Mon, 10 Apr 2023 15:04:53 +0200
> 
> 4. All, or most, of the *-ts-mode.el probably should be treated as
>    separate packages.

This is an issue we couldn't resolve in Emacs 29.  There are various
aspects of that, basically related to the current decision to make
these modes completely optional and yet allow users to activate them
easily.  If you are interested in details, please search the
emacs-devel list for relevant discussions, between November and now.
We will need to revisit this after Emacs 29 is released ad we get some
user feedback.

> 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?

We made it a separate package because its settings are shared by
several other modes, which users should be able to activate
independently.  Again, look up relevant discussions around the time
the file was created, and you will see the problems it was intended to
solve (and did solve).

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

[Michael Albinus]

Jonas Bernoulli <jonas@bernoul.li> writes:

> Hello,

Hi Jonas,

> The following packages are also listed separately in package--builtins,
> but I tend to think that is not intentional.
>
>                                    part of?:
> 8. lisp/net/tramp-container.el     tramp

I cannot reproduce it. Tested with a fresh checkout of the emacs-29
branch:

# ~/src/emacs-29/src/emacs
M-x package-list-packages

No "tramp-container".

C-h v package--builtins

No "tramp-container".

(But you are right, tramp-container.el is part of the Tramp package).

>      Cheers,
>      Jonas

Best regards, Michael.

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

[Jonas Bernoulli]

Michael Albinus <michael.albinus@gmx.de> writes:

>>                                    part of?:
>> 8. lisp/net/tramp-container.el     tramp
>
> I cannot reproduce it. Tested with a fresh checkout of the emacs-29
> branch:

You are right.  Don't know what happened, maybe my finder-inf.el was
outdated.

     Sorry for the noise,
     Jonas

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

[Stefan Kangas]

Jonas Bernoulli <jonas@bernoul.li> writes:

> Michael Albinus <michael.albinus@gmx.de> writes:
>
>>>                                    part of?:
>>> 8. lisp/net/tramp-container.el     tramp
>>
>> I cannot reproduce it. Tested with a fresh checkout of the emacs-29
>> branch:
>
> You are right.  Don't know what happened, maybe my finder-inf.el was
> outdated.
>
>      Sorry for the noise,
>      Jonas

I'm therefore closing this bug report.

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

[Stefan Kangas]

reopen 62751
thanks

Stefan Kangas <stefankangas@gmail.com> writes:

> I'm therefore closing this bug report.

Sorry, I see that there are several other issues here that needs
resolving.  Reopening.

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.

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

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

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]

Jonas Bernoulli <jonas@bernoul.li> writes:

>>> 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).

Right, so we either need to remove the "use-package" from
package--builtins, or move it out of the lisp/use-package directory.
Otherwise, it will show up in `M-x package-list-packages' as "available"
rather than "built-in" (as it's now considered part of 'use-package').

Given that it is its own package on GNU ELPA, I can see some logic in
moving it out of the use-package directory.  It's never ideal to move
files with git, but OTOH it's not been with us for that long yet.

Eli, Stefan, any opinions/preferences?

>>> 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.

Yes, that's the other option.  That's also less than ideal, as it
involves tedious manual work.

Do we have some way to list new additions to package--builtins?

> 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.

Thanks again for paying attention to this aspect.

> By the way, IMO it would make sense to apply these on "emacs-29", not
> just "master".

You're right, now 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)

Also done, on emacs-29.

> In addition to adding an entry for "lisp/obsolete", the "Package" header
> should be removed from all files in that directory.

Is that needed given the entry in finder--builtins-alist?

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

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Mon, 18 Sep 2023 00:34:42 -0700
> Cc: Eli Zaretskii <eliz@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca>
> 
> Jonas Bernoulli <jonas@bernoul.li> writes:
> 
> > Maybe lisp/use-package/bind-key.el should be a separate package (and
> > maybe it should be moved out of that directory).
> 
> Right, so we either need to remove the "use-package" from
> package--builtins, or move it out of the lisp/use-package directory.
> Otherwise, it will show up in `M-x package-list-packages' as "available"
> rather than "built-in" (as it's now considered part of 'use-package').
> 
> Given that it is its own package on GNU ELPA, I can see some logic in
> moving it out of the use-package directory.  It's never ideal to move
> files with git, but OTOH it's not been with us for that long yet.
> 
> Eli, Stefan, any opinions/preferences?

You mean, move bind-key.el out of lisp/use-package, right?

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

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stefan Kangas <stefankangas@gmail.com>
>> Date: Mon, 18 Sep 2023 00:34:42 -0700
>> Cc: Eli Zaretskii <eliz@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca>
>>
>> Jonas Bernoulli <jonas@bernoul.li> writes:
>>
>> > Maybe lisp/use-package/bind-key.el should be a separate package (and
>> > maybe it should be moved out of that directory).
>>
>> Right, so we either need to remove the "use-package" from
>> package--builtins, or move it out of the lisp/use-package directory.
>> Otherwise, it will show up in `M-x package-list-packages' as "available"
>> rather than "built-in" (as it's now considered part of 'use-package').
>>
>> Given that it is its own package on GNU ELPA, I can see some logic in
>> moving it out of the use-package directory.  It's never ideal to move
>> files with git, but OTOH it's not been with us for that long yet.
>>
>> Eli, Stefan, any opinions/preferences?
>
> You mean, move bind-key.el out of lisp/use-package, right?

Yes.

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

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Mon, 18 Sep 2023 04:10:32 -0700
> Cc: jonas@bernoul.li, 62751@debbugs.gnu.org, monnier@iro.umontreal.ca
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Stefan Kangas <stefankangas@gmail.com>
> >> Date: Mon, 18 Sep 2023 00:34:42 -0700
> >> Cc: Eli Zaretskii <eliz@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca>
> >>
> >> Jonas Bernoulli <jonas@bernoul.li> writes:
> >>
> >> > Maybe lisp/use-package/bind-key.el should be a separate package (and
> >> > maybe it should be moved out of that directory).
> >>
> >> Right, so we either need to remove the "use-package" from
> >> package--builtins, or move it out of the lisp/use-package directory.
> >> Otherwise, it will show up in `M-x package-list-packages' as "available"
> >> rather than "built-in" (as it's now considered part of 'use-package').
> >>
> >> Given that it is its own package on GNU ELPA, I can see some logic in
> >> moving it out of the use-package directory.  It's never ideal to move
> >> files with git, but OTOH it's not been with us for that long yet.
> >>
> >> Eli, Stefan, any opinions/preferences?
> >
> > You mean, move bind-key.el out of lisp/use-package, right?
> 
> Yes.

Fine by me, and I think this is preferable, and even clearly TRT for a
package that is not limited to its parent package.

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

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> > You mean, move bind-key.el out of lisp/use-package, right?
>>
>> Yes.
>
> Fine by me, and I think this is preferable, and even clearly TRT for a
> package that is not limited to its parent package.

Do you see any reason why that change would be dangerous, or could we do
it on the release branch?

The other option is to move it on master, while installing a less
intrusive patch on emacs-29 that removes "use-package" from
finder--builtins-alist again, and adds "Package" headers to the files in
the use-package directory instead.

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

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

> The other option is to move it on master, while installing a less
> intrusive patch on emacs-29 that removes "use-package" from
> finder--builtins-alist again, and adds "Package" headers to the files in
> the use-package directory instead.

Can't we just add a `;; Package: bind-key` header to `bind-key.el`?


        Stefan

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

[Stefan Kangas]

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

>> The other option is to move it on master, while installing a less
>> intrusive patch on emacs-29 that removes "use-package" from
>> finder--builtins-alist again, and adds "Package" headers to the files in
>> the use-package directory instead.
>
> Can't we just add a `;; Package: bind-key` header to `bind-key.el`?

I already tried that, but finder--builtins-alist seems to take
preference.  So the answer unfortunately seems to be no.

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

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

>>> The other option is to move it on master, while installing a less
>>> intrusive patch on emacs-29 that removes "use-package" from
>>> finder--builtins-alist again, and adds "Package" headers to the files in
>>> the use-package directory instead.
>>
>> Can't we just add a `;; Package: bind-key` header to `bind-key.el`?
>
> I already tried that, but finder--builtins-alist seems to take
> preference.

Sounds like a bug we should fix, rather than try and work around it.


        Stefan

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

[Stefan Kangas]

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

>>>> The other option is to move it on master, while installing a less
>>>> intrusive patch on emacs-29 that removes "use-package" from
>>>> finder--builtins-alist again, and adds "Package" headers to the files in
>>>> the use-package directory instead.
>>>
>>> Can't we just add a `;; Package: bind-key` header to `bind-key.el`?
>>
>> I already tried that, but finder--builtins-alist seems to take
>> preference.
>
> Sounds like a bug we should fix, rather than try and work around it.

Fine by me, but it's probably better to do that on master.

I installed the more minimal fix on emacs-29 for now.

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

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Wed, 20 Sep 2023 17:15:04 -0700
> Cc: jonas@bernoul.li, 62751@debbugs.gnu.org, monnier@iro.umontreal.ca
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> > You mean, move bind-key.el out of lisp/use-package, right?
> >>
> >> Yes.
> >
> > Fine by me, and I think this is preferable, and even clearly TRT for a
> > package that is not limited to its parent package.
> 
> Do you see any reason why that change would be dangerous, or could we do
> it on the release branch?

I honestly don't know.  Maybe we should ask the users of use-package?

John, do you see any potential problems with that?

One issue to consider is what will happen to use-package and bind-key
on ELPA -- will you make bind-key a separate package there??

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

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> One issue to consider is what will happen to use-package and bind-key
> on ELPA -- will you make bind-key a separate package there??

It already is:

    https://elpa.gnu.org/packages/bind-key.html
    https://elpa.gnu.org/packages/use-package.html

It makes sense to me at least, because the functionality is useful also
outside of use-package.

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

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stefan Kangas <stefankangas@gmail.com>
>> Date: Wed, 20 Sep 2023 17:15:04 -0700
>> Cc: jonas@bernoul.li, 62751@debbugs.gnu.org, monnier@iro.umontreal.ca
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> >> > You mean, move bind-key.el out of lisp/use-package, right?
>> >>
>> >> Yes.
>> >
>> > Fine by me, and I think this is preferable, and even clearly TRT for a
>> > package that is not limited to its parent package.
>>
>> Do you see any reason why that change would be dangerous, or could we do
>> it on the release branch?
>
> I honestly don't know.  Maybe we should ask the users of use-package?
>
> John, do you see any potential problems with that?

We can probably get away with the more minimal change I installed on
emacs-29 yesterday.  The only downside of not moving the file there, as
far as I can tell, is that it will be a hassle if we need to merge any
changes in bind-key.el to master.  It's a very slow moving target
though, so those instances should hopefully be rare.

Should bind-key.el be in lisp/?  lisp/emacs-lisp/?

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

[John Wiegley]

>>>>> Stefan Kangas <stefankangas@gmail.com> writes:

> We can probably get away with the more minimal change I installed on
> emacs-29 yesterday. The only downside of not moving the file there, as far
> as I can tell, is that it will be a hassle if we need to merge any changes
> in bind-key.el to master. It's a very slow moving target though, so those
> instances should hopefully be rare.

There are zero planned changes to bind-key.el, other than bug fixes that may
come up.

> Should bind-key.el be in lisp/?  lisp/emacs-lisp/?

I would put it in lisp/, since it relates to Emacs functionality rather than
the Emacs Lisp programming language in particular.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

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

[Stefan Kangas]

Version: 30.1

John Wiegley <johnw@gnu.org> writes:

>> Should bind-key.el be in lisp/?  lisp/emacs-lisp/?
>
> I would put it in lisp/, since it relates to Emacs functionality rather than
> the Emacs Lisp programming language in particular.

Now done on master (commit 947409d408e).  I think that's the last of the
outstanding issues in this bug, so I'm closing it with this message.

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

[John Wiegley]

>>>>> Stefan Kangas <stefankangas@gmail.com> writes:

> Now done on master (commit 947409d408e). I think that's the last of the
> outstanding issues in this bug, so I'm closing it with this message.

Thank you!

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

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

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

Stefan Kangas <stefankangas@gmail.com> writes:

> Version: 30.1
>
> John Wiegley <johnw@gnu.org> writes:
>
>>> Should bind-key.el be in lisp/?  lisp/emacs-lisp/?
>>
>> I would put it in lisp/, since it relates to Emacs functionality rather than
>> the Emacs Lisp programming language in particular.
>
> Now done on master (commit 947409d408e).  I think that's the last of the
> outstanding issues in this bug, so I'm closing it with this message.

Thanks!

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

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

> Right, so we either need to remove the "use-package" from
> package--builtins, or move it out of the lisp/use-package directory.
> Otherwise, it will show up in `M-x package-list-packages' as "available"
> rather than "built-in" (as it's now considered part of 'use-package').

I'm sorry, I must have missed a part of the discussion:
what does moving `bind-key.el` have to do with the above?
IIRC the code that fills `package--builtins` doesn't pay much attention
to directories.


        Stefan

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

[Stefan Kangas]

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

>> Right, so we either need to remove the "use-package" from
>> package--builtins, or move it out of the lisp/use-package directory.
>> Otherwise, it will show up in `M-x package-list-packages' as "available"
>> rather than "built-in" (as it's now considered part of 'use-package').
>
> I'm sorry, I must have missed a part of the discussion:
> what does moving `bind-key.el` have to do with the above?
> IIRC the code that fills `package--builtins` doesn't pay much attention
> to directories.

It's about `finder--builtins-alist', which is used by `describe-package'.

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

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

Stefan Kangas <stefankangas@gmail.com> writes:

> Jonas Bernoulli <jonas@bernoul.li> writes:

>> Maybe lisp/use-package/bind-key.el should be a separate package (and
>> maybe it should be moved out of that directory).
>
> Right, so we either need to remove the "use-package" from
> package--builtins, or move it out of the lisp/use-package directory.
> Otherwise, it will show up in `M-x package-list-packages' as "available"
> rather than "built-in" (as it's now considered part of 'use-package').
>
> Given that it is its own package on GNU ELPA, I can see some logic in
> moving it out of the use-package directory.  It's never ideal to move
> files with git, but OTOH it's not been with us for that long yet.
>
> Eli, Stefan, any opinions/preferences?

>> In addition to adding an entry for "lisp/obsolete", the "Package" header
>> should be removed from all files in that directory.
>
> Is that needed given the entry in finder--builtins-alist?

Currently finder-compile-keywords considers finder--builtins-alist
before the Package header, so no.  However, if you changed the order,
then you would not have to move bind-key.el out of lisp/use-package.
(Of course you would have to double-check to make sure this doesn't
have any unintended consequences.)

My alternative finder-compile-keywords current checks the Package header
before finder--builtins-alist.  I'll have to test whether reversing the
order changes anything (in addition to the mentioned cases).

> Do we have some way to list new additions to package--builtins?

Run "make finder-data" and then look at the diff?

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

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

Jonas Bernoulli <jonas@bernoul.li> writes:

> Stefan Kangas <stefankangas@gmail.com> writes:
>
>> Jonas Bernoulli <jonas@bernoul.li> writes:
>
>>> Maybe lisp/use-package/bind-key.el should be a separate package (and
>>> maybe it should be moved out of that directory).
>>
>> Right, so we either need to remove the "use-package" from
>> package--builtins, or move it out of the lisp/use-package directory.
>> Otherwise, it will show up in `M-x package-list-packages' as "available"
>> rather than "built-in" (as it's now considered part of 'use-package').
>>
>> Given that it is its own package on GNU ELPA, I can see some logic in
>> moving it out of the use-package directory.  It's never ideal to move
>> files with git, but OTOH it's not been with us for that long yet.
>>
>> Eli, Stefan, any opinions/preferences?
>
>>> In addition to adding an entry for "lisp/obsolete", the "Package" header
>>> should be removed from all files in that directory.
>>
>> Is that needed given the entry in finder--builtins-alist?
>
> Currently finder-compile-keywords considers finder--builtins-alist
> before the Package header, so no.  However, if you changed the order,
> then you would not have to move bind-key.el out of lisp/use-package.
> (Of course you would have to double-check to make sure this doesn't
> have any unintended consequences.)
>
> My alternative finder-compile-keywords current checks the Package header
> before finder--builtins-alist.  I'll have to test whether reversing the
> order changes anything (in addition to the mentioned cases).

I can now confirm that after changing the order in my own code, the
result is the same as before / as expected; except for bind-keys.el
because that hasn't been moved out of lisp/use-package yet.

All the other changes made in response to this request also work as
expected; I could remove the respective kludges.  (This does not
include the additional libraries, which I yesterday suggest might
be good candidates for removal.)

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

[Stefan Kangas]

Jonas Bernoulli <jonas@bernoul.li> writes:

> All the other changes made in response to this request also work as
> expected; I could remove the respective kludges.  (This does not
> include the additional libraries, which I yesterday suggest might
> be good candidates for removal.)

Thanks for testing.

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

[Stefan Kangas]

Jonas Bernoulli <jonas@bernoul.li> writes:

>> Do we have some way to list new additions to package--builtins?
>
> Run "make finder-data" and then look at the diff?

I installed the below patch on emacs-29 to take care of this part.

diff --git a/admin/make-tarball.txt b/admin/make-tarball.txt
index 505d3469d3c..5704e8e8922 100644
--- a/admin/make-tarball.txt
+++ b/admin/make-tarball.txt
@@ -22,6 +22,11 @@ Steps to take before starting on the first pretest
in any release sequence:
     You can use 'gnupload --delete' (see below for more gnupload details).
     (We currently don't bother with this.)

+4.  Check that all new Lisp libraries belong to sensible packages.
+    Run "make -C lisp finder-data" and check the diff of the generated
+    file against the previously released Emacs version to see what has
+    changed.
+
 General steps (for each step, check for possible errors):

 1.    git pull     # fetch from the repository

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

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Sun, 1 Oct 2023 06:11:28 -0700
> Cc: Eli Zaretskii <eliz@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca>
> 
> Jonas Bernoulli <jonas@bernoul.li> writes:
> 
> >> Do we have some way to list new additions to package--builtins?
> >
> > Run "make finder-data" and then look at the diff?
> 
> I installed the below patch on emacs-29 to take care of this part.
> 
> diff --git a/admin/make-tarball.txt b/admin/make-tarball.txt
> index 505d3469d3c..5704e8e8922 100644
> --- a/admin/make-tarball.txt
> +++ b/admin/make-tarball.txt
> @@ -22,6 +22,11 @@ Steps to take before starting on the first pretest
> in any release sequence:
>      You can use 'gnupload --delete' (see below for more gnupload details).
>      (We currently don't bother with this.)
> 
> +4.  Check that all new Lisp libraries belong to sensible packages.
> +    Run "make -C lisp finder-data" and check the diff of the generated
> +    file against the previously released Emacs version to see what has
> +    changed.
> +

This could benefit from some criteria for what is and isn't reasonable
in these diffs, or what to do with the differences.  Because otherwise
"check the diff" doesn't tell how to check it.

Thanks.

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

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> I installed the below patch on emacs-29 to take care of this part.
>>
>> diff --git a/admin/make-tarball.txt b/admin/make-tarball.txt
>> index 505d3469d3c..5704e8e8922 100644
>> --- a/admin/make-tarball.txt
>> +++ b/admin/make-tarball.txt
>> @@ -22,6 +22,11 @@ Steps to take before starting on the first pretest
>> in any release sequence:
>>      You can use 'gnupload --delete' (see below for more gnupload details).
>>      (We currently don't bother with this.)
>>
>> +4.  Check that all new Lisp libraries belong to sensible packages.
>> +    Run "make -C lisp finder-data" and check the diff of the generated
>> +    file against the previously released Emacs version to see what has
>> +    changed.
>> +
>
> This could benefit from some criteria for what is and isn't reasonable
> in these diffs, or what to do with the differences.  Because otherwise
> "check the diff" doesn't tell how to check it.

I didn't put anything, because I don't know how to summarize that in a
few short words.  Ideas for how to do that are welcome.

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

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Sun, 1 Oct 2023 08:46:46 -0700
> Cc: jonas@bernoul.li, 62751@debbugs.gnu.org, monnier@iro.umontreal.ca
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> +4.  Check that all new Lisp libraries belong to sensible packages.
> >> +    Run "make -C lisp finder-data" and check the diff of the generated
> >> +    file against the previously released Emacs version to see what has
> >> +    changed.
> >> +
> >
> > This could benefit from some criteria for what is and isn't reasonable
> > in these diffs, or what to do with the differences.  Because otherwise
> > "check the diff" doesn't tell how to check it.
> 
> I didn't put anything, because I don't know how to summarize that in a
> few short words.  Ideas for how to do that are welcome.

Well, if you tell it in as many words as you need (or point me to
where it was already described up-thread), I could try suggesting a
concise version.

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

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stefan Kangas <stefankangas@gmail.com>
>> Date: Sun, 1 Oct 2023 08:46:46 -0700
>> Cc: jonas@bernoul.li, 62751@debbugs.gnu.org, monnier@iro.umontreal.ca
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> >> +4.  Check that all new Lisp libraries belong to sensible packages.
>> >> +    Run "make -C lisp finder-data" and check the diff of the generated
>> >> +    file against the previously released Emacs version to see what has
>> >> +    changed.
>> >> +
>> >
>> > This could benefit from some criteria for what is and isn't reasonable
>> > in these diffs, or what to do with the differences.  Because otherwise
>> > "check the diff" doesn't tell how to check it.
>>
>> I didn't put anything, because I don't know how to summarize that in a
>> few short words.  Ideas for how to do that are welcome.
>
> Well, if you tell it in as many words as you need (or point me to
> where it was already described up-thread), I could try suggesting a
> concise version.

Here's a typical excerpt of the difference between emacs-29 and master:

--- emacs-release/lisp/finder-inf.el	2023-09-29 11:44:34.000000000 +0200
+++ emacs/lisp/finder-inf.el	2023-10-01 19:36:12.000000000 +0200
@@ -120,17 +120,18 @@
   (ediff . [(2 81 6) nil "a comprehensive visual interface to diff & patch"])
   (edmacro . [nil nil "keyboard macro editor"])
   (edt . [nil nil "enhanced EDT keypad mode emulation for GNU Emacs"])
-  (eglot . [(1 12 29) nil "The Emacs Client for LSP servers"])
+  (eglot . [(1 15) nil "The Emacs Client for LSP servers"])
   (ehelp . [nil nil "bindings for electric-help mode"])
   (eieio . [(1 4) nil "Enhanced Implementation of Emacs Interpreted Objects"])
   (eieio-core . [(1 4) nil "Core implementation for eieio"])
-  (eldoc . [(1 13 0) nil "Show function arglist or variable docstring
in echo area"])
+  (eldoc . [(1 14 0) nil "Show function arglist or variable docstring
in echo area"])
   (elec-pair . [nil nil "Automatic parenthesis pairing"])
   (electric . [nil nil "window maker and Command loop for `electric' modes"])
   (elide-head . [nil nil "hide headers in files"])
   (elint . [nil nil "Lint Emacs Lisp"])
+  (elixir-ts-mode . [nil nil "Major mode for Elixir with tree-sitter support"])
   (elp . [nil nil "Emacs Lisp Profiler"])
-  (emacs . [(29 1 50) nil "the extensible text editor"])
+  (emacs . [(30 0 50) nil "the extensible text editor"])
   (emacs-authors-mode . [nil nil "font-locking for etc/AUTHORS"])
   (emacs-lock . [nil nil "protect buffers against killing or exiting"])
   (emacs-news-mode . [nil nil "major mode to edit and view the NEWS file"])

We have here two cases:

1. eglot, eldoc, and emacs just have new versions, and therefore need
   no action.

2. elixir-ts-mode is a new package, and we need to consider if that
   package makes sense.  In this case, I'd say it does, but I'm not sure
   how to summarize the reasons why in a precise way.  Perhaps one could
   say something along the lines of "it functions as a standalone
   feature".

In Emacs 29.1, we had several new packages named something like:

    use-package-bind-key
    use-package-core
    use-package-diminish
    [...]
    use-package

In this case, the new packages did _not_ make sense and had to be
consolidated into just one package: use-package.  Again, it is hard for
me to summarize the reasons why.  I suppose it has something to do with
them not working without each other, and thus should better be treated
as one functional whole.

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

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

There are three more libraries that deserve some attention:

- lisp/obsolete/otodo-mode.el

  formerly known as todo-mode.el, was obsoleted a decade ago.
  Has the time for its removal come now? ;)

- lisp/obsolete/crisp.el
- lisp/obsolete/landmark.el

  are available from GNU ELPA, so it seems unnecessary to keep
  them in emacs.git as well.

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

[Stefan Kangas]

Jonas Bernoulli <jonas@bernoul.li> writes:

> There are three more libraries that deserve some attention:
>
> - lisp/obsolete/otodo-mode.el
>
>   formerly known as todo-mode.el, was obsoleted a decade ago.
>   Has the time for its removal come now? ;)

otodo-mode.el was obsoleted in Emacs 24.4, which according to
etc/HISTORY was released on 2014-10-20.

We typically keep stuff on master for 10 years after it was marked
obsolete in a release.  Doing it that way gives the community plenty of
time to adapt, and keeping obsolete stuff around is usually more or less
harmless.

We delete stuff faster only if there's a clear reason for it, for
example that it's clearly broken and/or harmful.  See browse-url.el for
some examples of the former.

> - lisp/obsolete/crisp.el
> - lisp/obsolete/landmark.el
>
>   are available from GNU ELPA, so it seems unnecessary to keep
>   them in emacs.git as well.

You're not wrong, but they were obsoleted in 24.5 and 25.1.  So it's
like above, but the dates are in 2025 and 2026, or something like that.

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

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

Stefan Kangas <stefankangas@gmail.com> writes:

> Jonas Bernoulli <jonas@bernoul.li> writes:
>
>> There are three more libraries that deserve some attention:
>>
>> - lisp/obsolete/otodo-mode.el
>>
>>   formerly known as todo-mode.el, was obsoleted a decade ago.
>>   Has the time for its removal come now? ;)
>
> otodo-mode.el was obsoleted in Emacs 24.4, which according to
> etc/HISTORY was released on 2014-10-20.
>
> We typically keep stuff on master for 10 years after it was marked
> obsolete in a release.  Doing it that way gives the community plenty of
> time to adapt, and keeping obsolete stuff around is usually more or less
> harmless.
>
> We delete stuff faster only if there's a clear reason for it, for
> example that it's clearly broken and/or harmful.  See browse-url.el for
> some examples of the former.
>
>> - lisp/obsolete/crisp.el
>> - lisp/obsolete/landmark.el
>>
>>   are available from GNU ELPA, so it seems unnecessary to keep
>>   them in emacs.git as well.
>
> You're not wrong, but they were obsoleted in 24.5 and 25.1.  So it's
> like above, but the dates are in 2025 and 2026, or something like that.

Alright.  Thanks for the clarification.

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

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

[-- Attachment #1: Type: text/plain, Size: 241 bytes --]

>> You're not wrong, but they were obsoleted in 24.5 and 25.1.  So it's
>> like above, but the dates are in 2025 and 2026, or something like that.

BTW, what about `sit-for`s obsolete calling convention (obsoleted in 22.1)?


        Stefan

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: sit-for.patch --]
[-- Type: text/x-diff, Size: 2013 bytes --]

diff --git a/lisp/subr.el b/lisp/subr.el
index e88815fa58c..58274987d71 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -3408,7 +3408,7 @@ read-char-choice-with-read-key
     (message "%s%s" prompt (char-to-string char))
     char))
 
-(defun sit-for (seconds &optional nodisp obsolete)
+(defun sit-for (seconds &optional nodisp)
   "Redisplay, then wait for SECONDS seconds.  Stop when input is available.
 SECONDS may be a floating-point value.
 \(On operating systems that do not support waiting for fractions of a
@@ -3417,29 +3417,11 @@ sit-for
 If optional arg NODISP is t, don't redisplay, just wait for input.
 Redisplay does not happen if input is available before it starts.
 
-Value is t if waited the full time with no input arriving, and nil otherwise.
-
-An obsolete, but still supported form is
-\(sit-for SECONDS &optional MILLISECONDS NODISP)
-where the optional arg MILLISECONDS specifies an additional wait period,
-in milliseconds; this was useful when Emacs was built without
-floating point support."
-  (declare (advertised-calling-convention (seconds &optional nodisp) "22.1")
-           (compiler-macro
-            (lambda (form)
-              (if (not (or (numberp nodisp) obsolete)) form
-                (macroexp-warn-and-return
-                 (format-message "Obsolete calling convention for `sit-for'")
-                 `(,(car form) (+ ,seconds (/ (or ,nodisp 0) 1000.0)) ,obsolete)
-                 '(obsolete sit-for))))))
+Value is t if waited the full time with no input arriving, and nil otherwise."
   ;; This used to be implemented in C until the following discussion:
   ;; https://lists.gnu.org/r/emacs-devel/2006-07/msg00401.html
   ;; Then it was moved here using an implementation based on an idle timer,
   ;; which was then replaced by the use of read-event.
-  (if (numberp nodisp)
-      (setq seconds (+ seconds (* 1e-3 nodisp))
-            nodisp obsolete)
-    (if obsolete (setq nodisp obsolete)))
   (cond
    (noninteractive
     (sleep-for seconds)

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

[Stefan Kangas]

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

>>> You're not wrong, but they were obsoleted in 24.5 and 25.1.  So it's
>>> like above, but the dates are in 2025 and 2026, or something like that.
>
> BTW, what about `sit-for`s obsolete calling convention (obsoleted in 22.1)?

Yeah, it's probably time to remove it.

Don't forget to also remove this part in (info "(elisp) Waiting"):

     It is also possible to call ‘sit-for’ with three arguments, as
     ‘(sit-for SECONDS MILLISEC NODISP)’, but that is considered
     obsolete.

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

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

>> BTW, what about `sit-for`s obsolete calling convention (obsoleted in 22.1)?
> Yeah, it's probably time to remove it.

Done, thanks,
BTW, how 'bout we drop the `millisec` arg of `sleep-for` as well (and
the pretense that there are still systems that can only sleep for whole
seconds)?



        Stefan


diff --git a/doc/lispref/commands.texi b/doc/lispref/commands.texi
index fdf5ec1d7fe..7fee967d0ee 100644
--- a/doc/lispref/commands.texi
+++ b/doc/lispref/commands.texi
@@ -3969,20 +3969,17 @@ Waiting
 thus equivalent to @code{sleep-for}, which is described below.
 @end defun
 
-@defun sleep-for seconds &optional millisec
+@defun sleep-for seconds
 This function simply pauses for @var{seconds} seconds without updating
 the display.  It pays no attention to available input.  It returns
 @code{nil}.
 
 The argument @var{seconds} need not be an integer.  If it is floating
 point, @code{sleep-for} waits for a fractional number of seconds.
-Some systems support only a whole number of seconds; on these systems,
-@var{seconds} is rounded down.
 
-The optional argument @var{millisec} specifies an additional waiting
-period measured in milliseconds.  This adds to the period specified by
-@var{seconds}.  If the system doesn't support waiting fractions of a
-second, you get an error if you specify nonzero @var{millisec}.
+It is also possible to call @code{sleep-for} with two arguments,
+as @code{(sleep-for @var{seconds} @var{millisec})},
+but that is considered obsolete.
 
 Use @code{sleep-for} when you wish to guarantee a delay.
 @end defun
diff --git a/lisp/subr.el b/lisp/subr.el
index 58274987d71..a2315110a0d 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -1959,6 +1959,7 @@ log10
 (set-advertised-calling-convention 'redirect-frame-focus '(frame focus-frame) "24.3")
 (set-advertised-calling-convention 'libxml-parse-xml-region '(&optional start end base-url) "27.1")
 (set-advertised-calling-convention 'libxml-parse-html-region '(&optional start end base-url) "27.1")
+(set-advertised-calling-convention 'sleep-for '(seconds) "30.1")
 (set-advertised-calling-convention 'time-convert '(time form) "29.1")
 \f
 ;;;; Obsolescence declarations for variables, and aliases.
diff --git a/src/dispnew.c b/src/dispnew.c
index d6a27ac29ec..e4037494775 100644
--- a/src/dispnew.c
+++ b/src/dispnew.c
@@ -6206,9 +6206,9 @@ bitch_at_user (void)
 DEFUN ("sleep-for", Fsleep_for, Ssleep_for, 1, 2, 0,
        doc: /* Pause, without updating display, for SECONDS seconds.
 SECONDS may be a floating-point value, meaning that you can wait for a
-fraction of a second.  Optional second arg MILLISECONDS specifies an
-additional wait period, in milliseconds; this is for backwards compatibility.
-\(Not all operating systems support waiting for a fraction of a second.)  */)
+fraction of a second.
+An optional second arg MILLISECONDS can be provided but is deprecated:
+it specifies an additional wait period, in milliseconds.  */)
   (Lisp_Object seconds, Lisp_Object milliseconds)
 {
   double duration = extract_float (seconds);

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Jonas Bernoulli <jonas@bernoul.li>,  62751@debbugs.gnu.org,  Eli
>  Zaretskii <eliz@gnu.org>
> Date: Fri, 13 Oct 2023 19:33:35 -0400
> 
> BTW, how 'bout we drop the `millisec` arg of `sleep-for` as well (and
> the pretense that there are still systems that can only sleep for whole
> seconds)?

Do we know which systems are/were those?  If not, how can we be sure
they are no longer interesting?

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

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

>> BTW, how 'bout we drop the `millisec` arg of `sleep-for` as well (and
>> the pretense that there are still systems that can only sleep for whole
>> seconds)?
>
> Do we know which systems are/were those?

I don't.
And my intuition tells me that "waiting for a fraction of a second"
was only part of the problem, and Emacs support for floating points
was another.  :-)

> If not, how can we be sure they are no longer interesting?

Because the code doesn't accommodate them any more anyway.
Removing the arg (as opposed to just marking it obsolete) amounts to:

    -DEFUN ("sleep-for", Fsleep_for, Ssleep_for, 1, 2, 0,
    +DEFUN ("sleep-for", Fsleep_for, Ssleep_for, 1, 1, 0,
            doc: /* Pause, without updating display, for SECONDS seconds.
     SECONDS may be a floating-point value, meaning that you can wait for a
    -fraction of a second.  Optional second arg MILLISECONDS specifies an
    -additional wait period, in milliseconds; this is for backwards compatibility.
    -\(Not all operating systems support waiting for a fraction of a second.)  */)
    -  (Lisp_Object seconds, Lisp_Object milliseconds)
    +fraction of a second.  */)
    +  (Lisp_Object seconds)
     {
       double duration = extract_float (seconds);
     
    -  if (!NILP (milliseconds))
    -    {
    -      CHECK_FIXNUM (milliseconds);
    -      duration += XFIXNUM (milliseconds) / 1000.0;
    -    }
    -
       if (duration > 0)
         {
           struct timespec t = dtotimespec (duration);


-- Sefan

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

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> BTW, how 'bout we drop the `millisec` arg of `sleep-for` as well (and
>> the pretense that there are still systems that can only sleep for whole
>> seconds)?

Sounds good to me.

> Do we know which systems are/were those?  If not, how can we be sure
> they are no longer interesting?

AFAIK, this primarily concerns early UNIX systems.

For example, the HISTORY section in "man 3 usleep" says that the call
was introduced as late as in BSD 4.3, which was released in 1986.

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Is there an assumption now that all Elisp files in Emacs need to be
assigned to some package?    When did that get decided?

Surely many files fit well into a package, but why be rigid about it?
There must be some that don't.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Stefan Kangas]

Richard Stallman <rms@gnu.org> writes:

> Is there an assumption now that all Elisp files in Emacs need to be
> assigned to some package?    When did that get decided?
>
> Surely many files fit well into a package, but why be rigid about it?
> There must be some that don't.

AFAIU, files with this comment header are not considered assigned to any
"real" package:

    ;; Package: emacs

More precisely, they are considered part of the "emacs" package, but
that package is treated specially in various situations.  For example,
it is not listed in `M-x package-list', and so on.