[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#62751: 29.0.90; New libraries that still need to be assigned to pack
From: |
Jonas Bernoulli |
Subject: |
bug#62751: 29.0.90; New libraries that still need to be assigned to packages |
Date: |
Wed, 20 Sep 2023 17:59:50 +0200 |
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, (continued)
- bug#62751: 29.0.90; New libraries that still need to be assigned to packages, Eli Zaretskii, 2023/09/21
- bug#62751: 29.0.90; New libraries that still need to be assigned to packages, Stefan Kangas, 2023/09/21
- bug#62751: 29.0.90; New libraries that still need to be assigned to packages, Stefan Kangas, 2023/09/23
- bug#62751: 29.0.90; New libraries that still need to be assigned to packages, Stefan Monnier, 2023/09/18
- bug#62751: 29.0.90; New libraries that still need to be assigned to packages, Stefan Kangas, 2023/09/20
- bug#62751: 29.0.90; New libraries that still need to be assigned to packages, Jonas Bernoulli, 2023/09/18
- bug#62751: 29.0.90; New libraries that still need to be assigned to packages,
Jonas Bernoulli <=
- bug#62751: 29.0.90; New libraries that still need to be assigned to packages, Stefan Kangas, 2023/09/24
- bug#62751: 29.0.90; New libraries that still need to be assigned to packages, Jonas Bernoulli, 2023/09/18
- bug#62751: 29.0.90; New libraries that still need to be assigned to packages, Stefan Kangas, 2023/09/20
- bug#62751: 29.0.90; New libraries that still need to be assigned to packages, Jonas Bernoulli, 2023/09/21
- bug#62751: 29.0.90; New libraries that still need to be assigned to packages, Stefan Monnier, 2023/09/22
- bug#62751: 29.0.90; New libraries that still need to be assigned to packages, Stefan Kangas, 2023/09/23
- bug#62751: 29.0.90; New libraries that still need to be assigned to packages, Richard Stallman, 2023/09/19
- bug#62751: 29.0.90; New libraries that still need to be assigned to packages, Stefan Kangas, 2023/09/20