GNU bug report logs - #62751
29.0.90; New libraries that still need to be assigned to packages

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 62751 in the body.
You can then email your comments to 62751 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jonas Bernoulli <jonas <at> bernoul.li>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.90; New libraries that still need to be assigned to packages
Date: Mon, 10 Apr 2023 15:04:53 +0200

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

Message #8 received at 62751 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jonas Bernoulli <jonas <at> bernoul.li>
Cc: 62751 <at> debbugs.gnu.org
Subject: Re: bug#62751: 29.0.90;
 New libraries that still need to be assigned to packages
Date: Mon, 10 Apr 2023 16:30:11 +0300

> From: Jonas Bernoulli <jonas <at> 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).

Message #11 received at 62751 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Jonas Bernoulli <jonas <at> bernoul.li>
Cc: 62751 <at> debbugs.gnu.org
Subject: Re: bug#62751: 29.0.90; New libraries that still need to be
 assigned to packages
Date: Tue, 11 Apr 2023 18:03:28 +0200

Jonas Bernoulli <jonas <at> 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.

Message #14 received at 62751 <at> debbugs.gnu.org (full text, mbox):

From: Jonas Bernoulli <jonas <at> bernoul.li>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 62751 <at> debbugs.gnu.org
Subject: Re: bug#62751: 29.0.90; New libraries that still need to be
 assigned to packages
Date: Tue, 11 Apr 2023 19:16:57 +0200

Michael Albinus <michael.albinus <at> 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

Message #19 received at 62751-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Jonas Bernoulli <jonas <at> bernoul.li>
Cc: Michael Albinus <michael.albinus <at> gmx.de>, 62751-done <at> debbugs.gnu.org
Subject: Re: bug#62751: 29.0.90; New libraries that still need to be assigned
 to packages
Date: Tue, 5 Sep 2023 16:49:08 -0700

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

> Michael Albinus <michael.albinus <at> 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.

Message #24 received at 62751 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Jonas Bernoulli <jonas <at> bernoul.li>
Cc: Michael Albinus <michael.albinus <at> gmx.de>, 62751 <at> debbugs.gnu.org
Subject: Re: bug#62751: 29.0.90; New libraries that still need to be assigned
 to packages
Date: Sat, 16 Sep 2023 02:21:26 -0700

reopen 62751
thanks

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

> I'm therefore closing this bug report.

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

Message #27 received at 62751 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Jonas Bernoulli <jonas <at> bernoul.li>, 62751 <at> debbugs.gnu.org
Subject: Re: bug#62751: 29.0.90; New libraries that still need to be assigned
 to packages
Date: Sat, 16 Sep 2023 07:23:23 -0700

fixed 62751 30.1
thanks

Jonas Bernoulli <jonas <at> 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.

Message #32 received at 62751 <at> debbugs.gnu.org (full text, mbox):

From: Jonas Bernoulli <jonas <at> bernoul.li>
To: Stefan Kangas <stefankangas <at> gmail.com>, 62751 <at> debbugs.gnu.org
Subject: Re: 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 <at> gmail.com> writes:
> Jonas Bernoulli <jonas <at> 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.

Message #35 received at 62751 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Jonas Bernoulli <jonas <at> bernoul.li>, 62751 <at> debbugs.gnu.org
Cc: Eli Zaretskii <eliz <at> gnu.org>, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#62751: 29.0.90; New libraries that still need to be assigned
 to packages
Date: Mon, 18 Sep 2023 00:34:42 -0700

Jonas Bernoulli <jonas <at> 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?

Message #38 received at 62751 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: jonas <at> bernoul.li, monnier <at> iro.umontreal.ca, 62751 <at> debbugs.gnu.org
Subject: Re: bug#62751: 29.0.90; New libraries that still need to be assigned
 to packages
Date: Mon, 18 Sep 2023 14:02:33 +0300

> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Mon, 18 Sep 2023 00:34:42 -0700
> Cc: Eli Zaretskii <eliz <at> gnu.org>, Stefan Monnier <monnier <at> iro.umontreal.ca>
> 
> Jonas Bernoulli <jonas <at> 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?

Message #41 received at 62751 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: jonas <at> bernoul.li, monnier <at> iro.umontreal.ca, 62751 <at> debbugs.gnu.org
Subject: Re: bug#62751: 29.0.90; New libraries that still need to be assigned
 to packages
Date: Mon, 18 Sep 2023 04:10:32 -0700

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Stefan Kangas <stefankangas <at> gmail.com>
>> Date: Mon, 18 Sep 2023 00:34:42 -0700
>> Cc: Eli Zaretskii <eliz <at> gnu.org>, Stefan Monnier <monnier <at> iro.umontreal.ca>
>>
>> Jonas Bernoulli <jonas <at> 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.

Message #44 received at 62751 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: jonas <at> bernoul.li, monnier <at> iro.umontreal.ca, 62751 <at> debbugs.gnu.org
Subject: Re: bug#62751: 29.0.90; New libraries that still need to be assigned
 to packages
Date: Mon, 18 Sep 2023 14:49:33 +0300

> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Mon, 18 Sep 2023 04:10:32 -0700
> Cc: jonas <at> bernoul.li, 62751 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> From: Stefan Kangas <stefankangas <at> gmail.com>
> >> Date: Mon, 18 Sep 2023 00:34:42 -0700
> >> Cc: Eli Zaretskii <eliz <at> gnu.org>, Stefan Monnier <monnier <at> iro.umontreal.ca>
> >>
> >> Jonas Bernoulli <jonas <at> 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.

Message #47 received at 62751 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Jonas Bernoulli <jonas <at> bernoul.li>,
 62751 <at> debbugs.gnu.org
Subject: Re: bug#62751: 29.0.90; New libraries that still need to be
 assigned to packages
Date: Mon, 18 Sep 2023 07:58:57 -0400

> 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

Message #50 received at 62751 <at> debbugs.gnu.org (full text, mbox):

From: Jonas Bernoulli <jonas <at> bernoul.li>
To: Stefan Kangas <stefankangas <at> gmail.com>, 62751 <at> debbugs.gnu.org
Cc: Eli Zaretskii <eliz <at> gnu.org>, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#62751: 29.0.90; New libraries that still need to be
 assigned to packages
Date: Mon, 18 Sep 2023 17:19:25 +0200

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

> Jonas Bernoulli <jonas <at> 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?

Message #53 received at 62751 <at> debbugs.gnu.org (full text, mbox):

From: Jonas Bernoulli <jonas <at> bernoul.li>
To: Stefan Kangas <stefankangas <at> gmail.com>, 62751 <at> debbugs.gnu.org
Cc: Eli Zaretskii <eliz <at> gnu.org>, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#62751: 29.0.90; New libraries that still need to be
 assigned to packages
Date: Mon, 18 Sep 2023 17:33:34 +0200

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.

Message #56 received at 62751 <at> debbugs.gnu.org (full text, mbox):

From: Richard Stallman <rms <at> gnu.org>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: eliz <at> gnu.org, jonas <at> bernoul.li, monnier <at> iro.umontreal.ca,
 62751 <at> debbugs.gnu.org
Subject: Re: bug#62751: 29.0.90;
 New libraries that still need to be assigned to packages
Date: Tue, 19 Sep 2023 19:12:18 -0400

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

Message #59 received at 62751 <at> debbugs.gnu.org (full text, mbox):

From: Jonas Bernoulli <jonas <at> bernoul.li>
To: Stefan Kangas <stefankangas <at> gmail.com>, 62751 <at> debbugs.gnu.org
Cc: Eli Zaretskii <eliz <at> gnu.org>, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#62751: 29.0.90; New libraries that still need to be
 assigned to packages
Date: Wed, 20 Sep 2023 17:59:50 +0200

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

> Stefan Kangas <stefankangas <at> gmail.com> writes:
>
>> Jonas Bernoulli <jonas <at> 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.)

Message #62 received at 62751 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: rms <at> gnu.org
Cc: eliz <at> gnu.org, jonas <at> bernoul.li, monnier <at> iro.umontreal.ca,
 62751 <at> debbugs.gnu.org
Subject: Re: bug#62751: 29.0.90; New libraries that still need to be assigned
 to packages
Date: Wed, 20 Sep 2023 16:45:28 -0700

Richard Stallman <rms <at> 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.

Message #65 received at 62751 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Jonas Bernoulli <jonas <at> bernoul.li>, 62751 <at> debbugs.gnu.org
Cc: Eli Zaretskii <eliz <at> gnu.org>, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#62751: 29.0.90; New libraries that still need to be assigned
 to packages
Date: Wed, 20 Sep 2023 17:04:05 -0700

Jonas Bernoulli <jonas <at> 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.

Message #68 received at 62751 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Jonas Bernoulli <jonas <at> bernoul.li>,
 62751 <at> debbugs.gnu.org
Subject: Re: bug#62751: 29.0.90; New libraries that still need to be assigned
 to packages
Date: Wed, 20 Sep 2023 17:06:40 -0700

Stefan Monnier <monnier <at> 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'.

Message #71 received at 62751 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: jonas <at> bernoul.li, monnier <at> iro.umontreal.ca, 62751 <at> debbugs.gnu.org
Subject: Re: bug#62751: 29.0.90; New libraries that still need to be assigned
 to packages
Date: Wed, 20 Sep 2023 17:15:04 -0700

Eli Zaretskii <eliz <at> 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.

Message #74 received at 62751 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, jonas <at> bernoul.li, 62751 <at> debbugs.gnu.org
Subject: Re: bug#62751: 29.0.90; New libraries that still need to be
 assigned to packages
Date: Wed, 20 Sep 2023 22:29:56 -0400

> 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

Message #77 received at 62751 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefankangas <at> gmail.com>,
 John Wiegley <johnw <at> gnu.org>
Cc: jonas <at> bernoul.li, monnier <at> iro.umontreal.ca, 62751 <at> debbugs.gnu.org
Subject: Re: bug#62751: 29.0.90; New libraries that still need to be assigned
 to packages
Date: Thu, 21 Sep 2023 10:15:07 +0300

> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Wed, 20 Sep 2023 17:15:04 -0700
> Cc: jonas <at> bernoul.li, 62751 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
> 
> Eli Zaretskii <eliz <at> 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??

Message #80 received at 62751 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, jonas <at> bernoul.li, 62751 <at> debbugs.gnu.org
Subject: Re: bug#62751: 29.0.90; New libraries that still need to be assigned
 to packages
Date: Thu, 21 Sep 2023 00:26:43 -0700

Stefan Monnier <monnier <at> 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.

Message #83 received at 62751 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>, John Wiegley <johnw <at> gnu.org>
Cc: jonas <at> bernoul.li, monnier <at> iro.umontreal.ca, 62751 <at> debbugs.gnu.org
Subject: Re: bug#62751: 29.0.90; New libraries that still need to be assigned
 to packages
Date: Thu, 21 Sep 2023 00:29:36 -0700

Eli Zaretskii <eliz <at> 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.

Message #86 received at 62751 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, jonas <at> bernoul.li, 62751 <at> debbugs.gnu.org
Subject: Re: bug#62751: 29.0.90; New libraries that still need to be
 assigned to packages
Date: Thu, 21 Sep 2023 10:01:34 -0400

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

Message #89 received at 62751 <at> debbugs.gnu.org (full text, mbox):

From: Jonas Bernoulli <jonas <at> bernoul.li>
To: Stefan Kangas <stefankangas <at> gmail.com>, 62751 <at> debbugs.gnu.org
Cc: Eli Zaretskii <eliz <at> gnu.org>, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#62751: 29.0.90; New libraries that still need to be
 assigned to packages
Date: Thu, 21 Sep 2023 23:12:21 +0200

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

> Jonas Bernoulli <jonas <at> 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.

Message #92 received at 62751 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, jonas <at> bernoul.li, 62751 <at> debbugs.gnu.org
Subject: Re: bug#62751: 29.0.90; New libraries that still need to be assigned
 to packages
Date: Fri, 22 Sep 2023 05:36:12 -0700

Stefan Monnier <monnier <at> 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.

Message #95 received at 62751 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Jonas Bernoulli <jonas <at> bernoul.li>,
 62751 <at> debbugs.gnu.org
Subject: Re: bug#62751: 29.0.90; New libraries that still need to be
 assigned to packages
Date: Fri, 22 Sep 2023 11:30:19 -0400

[Message part 1 (text/plain, inline)]

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

[sit-for.patch (text/x-diff, inline)]

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)

Message #98 received at 62751 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Jonas Bernoulli <jonas <at> bernoul.li>,
 62751 <at> debbugs.gnu.org
Subject: Re: bug#62751: 29.0.90; New libraries that still need to be assigned
 to packages
Date: Sat, 23 Sep 2023 04:35:21 -0700

Stefan Monnier <monnier <at> 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.

Message #101 received at 62751 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>, John Wiegley <johnw <at> gnu.org>
Cc: jonas <at> bernoul.li, monnier <at> iro.umontreal.ca, 62751 <at> debbugs.gnu.org
Subject: Re: bug#62751: 29.0.90; New libraries that still need to be assigned
 to packages
Date: Sat, 23 Sep 2023 07:42:46 -0700

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Stefan Kangas <stefankangas <at> gmail.com>
>> Date: Wed, 20 Sep 2023 17:15:04 -0700
>> Cc: jonas <at> bernoul.li, 62751 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
>>
>> Eli Zaretskii <eliz <at> 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/?

Message #104 received at 62751 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Jonas Bernoulli <jonas <at> bernoul.li>, 62751 <at> debbugs.gnu.org
Cc: Eli Zaretskii <eliz <at> gnu.org>, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#62751: 29.0.90; New libraries that still need to be assigned
 to packages
Date: Sun, 24 Sep 2023 05:29:10 -0700

Jonas Bernoulli <jonas <at> 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.

Message #107 received at 62751 <at> debbugs.gnu.org (full text, mbox):

From: John Wiegley <johnw <at> gnu.org>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, jonas <at> bernoul.li, monnier <at> iro.umontreal.ca,
 62751 <at> debbugs.gnu.org
Subject: Re: bug#62751: 29.0.90; New libraries that still need to be
 assigned to packages
Date: Sun, 24 Sep 2023 11:07:52 -0700

>>>>> Stefan Kangas <stefankangas <at> 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

Message #112 received at 62751-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: John Wiegley <johnw <at> gnu.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, jonas <at> bernoul.li, monnier <at> iro.umontreal.ca,
 62751-done <at> debbugs.gnu.org
Subject: Re: bug#62751: 29.0.90; New libraries that still need to be assigned
 to packages
Date: Sun, 24 Sep 2023 13:22:57 -0700

Version: 30.1

John Wiegley <johnw <at> 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.

Message #115 received at 62751-done <at> debbugs.gnu.org (full text, mbox):

From: John Wiegley <johnw <at> gnu.org>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, jonas <at> bernoul.li, monnier <at> iro.umontreal.ca,
 62751-done <at> debbugs.gnu.org
Subject: Re: bug#62751: 29.0.90; New libraries that still need to be
 assigned to packages
Date: Sun, 24 Sep 2023 14:05:03 -0700

>>>>> Stefan Kangas <stefankangas <at> 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

Message #118 received at 62751-done <at> debbugs.gnu.org (full text, mbox):

From: Jonas Bernoulli <jonas <at> bernoul.li>
To: Stefan Kangas <stefankangas <at> gmail.com>, John Wiegley <johnw <at> gnu.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, monnier <at> iro.umontreal.ca,
 62751-done <at> debbugs.gnu.org
Subject: Re: bug#62751: 29.0.90; New libraries that still need to be
 assigned to packages
Date: Wed, 27 Sep 2023 00:37:31 +0200

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

> Version: 30.1
>
> John Wiegley <johnw <at> 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!

Message #121 received at 62751 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Jonas Bernoulli <jonas <at> bernoul.li>, 62751 <at> debbugs.gnu.org
Cc: Eli Zaretskii <eliz <at> gnu.org>, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#62751: 29.0.90; New libraries that still need to be assigned
 to packages
Date: Sun, 1 Oct 2023 06:11:28 -0700

Jonas Bernoulli <jonas <at> 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

Message #124 received at 62751 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: jonas <at> bernoul.li, monnier <at> iro.umontreal.ca, 62751 <at> debbugs.gnu.org
Subject: Re: bug#62751: 29.0.90; New libraries that still need to be assigned
 to packages
Date: Sun, 01 Oct 2023 16:56:23 +0300

> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Sun, 1 Oct 2023 06:11:28 -0700
> Cc: Eli Zaretskii <eliz <at> gnu.org>, Stefan Monnier <monnier <at> iro.umontreal.ca>
> 
> Jonas Bernoulli <jonas <at> 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.

Message #127 received at 62751 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: jonas <at> bernoul.li, monnier <at> iro.umontreal.ca, 62751 <at> debbugs.gnu.org
Subject: Re: bug#62751: 29.0.90; New libraries that still need to be assigned
 to packages
Date: Sun, 1 Oct 2023 08:46:46 -0700

Eli Zaretskii <eliz <at> 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.

Message #130 received at 62751 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: jonas <at> bernoul.li, monnier <at> iro.umontreal.ca, 62751 <at> debbugs.gnu.org
Subject: Re: bug#62751: 29.0.90; New libraries that still need to be assigned
 to packages
Date: Sun, 01 Oct 2023 19:52:03 +0300

> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Sun, 1 Oct 2023 08:46:46 -0700
> Cc: jonas <at> bernoul.li, 62751 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
> 
> Eli Zaretskii <eliz <at> 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.

Message #133 received at 62751 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: jonas <at> bernoul.li, monnier <at> iro.umontreal.ca, 62751 <at> debbugs.gnu.org
Subject: Re: bug#62751: 29.0.90; New libraries that still need to be assigned
 to packages
Date: Sun, 1 Oct 2023 10:46:13 -0700

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Stefan Kangas <stefankangas <at> gmail.com>
>> Date: Sun, 1 Oct 2023 08:46:46 -0700
>> Cc: jonas <at> bernoul.li, 62751 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
>>
>> Eli Zaretskii <eliz <at> 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.

Message #136 received at 62751 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Jonas Bernoulli <jonas <at> bernoul.li>,
 62751 <at> debbugs.gnu.org
Subject: Re: bug#62751: 29.0.90; New libraries that still need to be
 assigned to packages
Date: Fri, 13 Oct 2023 19:33:35 -0400

>> 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")
 
 ;;;; 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);

Message #139 received at 62751 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: jonas <at> bernoul.li, stefankangas <at> gmail.com, 62751 <at> debbugs.gnu.org
Subject: Re: bug#62751: 29.0.90; New libraries that still need to be
 assigned to packages
Date: Sat, 14 Oct 2023 09:45:18 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Jonas Bernoulli <jonas <at> bernoul.li>,  62751 <at> debbugs.gnu.org,  Eli
>  Zaretskii <eliz <at> 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?

Message #142 received at 62751 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: jonas <at> bernoul.li, stefankangas <at> gmail.com, 62751 <at> debbugs.gnu.org
Subject: Re: bug#62751: 29.0.90; New libraries that still need to be
 assigned to packages
Date: Sat, 14 Oct 2023 10:39:09 -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?

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

Message #145 received at 62751 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: jonas <at> bernoul.li, 62751 <at> debbugs.gnu.org
Subject: Re: bug#62751: 29.0.90; New libraries that still need to be assigned
 to packages
Date: Sat, 14 Oct 2023 09:21:54 -0700

Eli Zaretskii <eliz <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.