[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: |
Eli Zaretskii |
Subject: |
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@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, 2023/09/05
- bug#62751: 29.0.90; New libraries that still need to be assigned to packages, Stefan Kangas, 2023/09/16
- bug#62751: 29.0.90; New libraries that still need to be assigned to packages, Jonas Bernoulli, 2023/09/17
- bug#62751: 29.0.90; New libraries that still need to be assigned to packages, Stefan Kangas, 2023/09/18
- bug#62751: 29.0.90; New libraries that still need to be assigned to packages, Eli Zaretskii, 2023/09/18
- bug#62751: 29.0.90; New libraries that still need to be assigned to packages, Stefan Kangas, 2023/09/18
- bug#62751: 29.0.90; New libraries that still need to be assigned to packages,
Eli Zaretskii <=
- bug#62751: 29.0.90; New libraries that still need to be assigned to packages, Stefan Kangas, 2023/09/20
- bug#62751: 29.0.90; New libraries that still need to be assigned to packages, Stefan Monnier, 2023/09/20
- bug#62751: 29.0.90; New libraries that still need to be assigned to packages, Stefan Kangas, 2023/09/21
- bug#62751: 29.0.90; New libraries that still need to be assigned to packages, Stefan Monnier, 2023/09/21
- bug#62751: 29.0.90; New libraries that still need to be assigned to packages, Stefan Kangas, 2023/09/22
- bug#62751: 29.0.90; New libraries that still need to be assigned to packages, Eli Zaretskii, 2023/09/21
- 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, John Wiegley, 2023/09/24
- bug#62751: 29.0.90; New libraries that still need to be assigned to packages, Stefan Kangas, 2023/09/24