GNU bug report logs - #79106
[PATCH] Add new optional keywords to use-package

Previous Next

To reply to this bug, email your comments to 79106 AT debbugs.gnu.org.

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

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

From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] Add new optional keywords to use-package
Date: Sun, 27 Jul 2025 14:18:57 -0600

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

Tags: patch

As discussed in
https://lists.gnu.org/archive/html/emacs-devel/2025-07/msg00354.html

This patch add new optional keywords to use-package, most of them are
inspired by suggestions from use-package bug-tracker on github

This includes following keywords:

* :advice Add or remove function advices.

* :custom-face* Like :custom-face but override the face specs.
  This closes bug#77928 dilemma.

* :defvar-keymap Define a new keymap or override an existent one.

* :doc Document the use-package declaration instead using comments.

* :tag Like :doc, but for categorizing.
  (This and :doc does nothing)

* :emacs<, :emacs<=, :emacs=, :emacs>, :emacs>=, shorthand for
  `:if (version...)`

* :hook-suffix Changes `use-package-hook-name-suffix' value only in the
  current use-package declaration.

* :hook+ Like default :hook, but allows to set the hook depth and set
  multiple functions in the hook (or for each hook).

  Although I tried to make it compatible with :hook, there may be some
  things I missed, so I decided to put it separately instead of merging
  it with :hook.  In addition, its syntax is more complex compared to
  :hook.

* :local-set Bind variables locally when entering to a mode or to a hook(s).
  An alternative to  `:hook (hook . (lambda () (setq-local ...)))`

* :setopt Like :custom, but can also bind plain variables.
  This uses the `setopt` function for bind the variables.

* :which-key-replacement A simple way to set which-key replacements.

[0001-Add-new-optional-keywords-to-use-package.patch (text/patch, attachment)]

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

-- 
- E.G via Gnus and Org.

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

From: Philip Kaludercic <philipk <at> posteo.net>
To: Elijah Gabe Pérez <eg642616 <at> gmail.com>
Cc: John Wiegley <johnw <at> newartisans.com>, Eli Zaretskii <eliz <at> gnu.org>,
 79106 <at> debbugs.gnu.org
Subject: Re: bug#79106: [PATCH] Add new optional keywords to use-package
Date: Mon, 28 Jul 2025 19:22:50 +0000

Elijah Gabe Pérez <eg642616 <at> gmail.com> writes:

I guess it would be good to discuss the content of the patch now that we
are considering to merge it.

> Tags: patch
>
> As discussed in
> https://lists.gnu.org/archive/html/emacs-devel/2025-07/msg00354.html
>
> This patch add new optional keywords to use-package, most of them are
> inspired by suggestions from use-package bug-tracker on github
>
> This includes following keywords:
>
> * :advice Add or remove function advices.

I did not understand how this uses :advice to create something
use-package specific that has an advantage over `define-advice'.

> * :custom-face* Like :custom-face but override the face specs.
>   This closes bug#77928 dilemma.
>
> * :defvar-keymap Define a new keymap or override an existent one.

Why is this something that a user would be interested in when
configuring a package?

> * :doc Document the use-package declaration instead using comments.
>
> * :tag Like :doc, but for categorizing.
>   (This and :doc does nothing)

Can you explain what these tags are good for?

> * :emacs<, :emacs<=, :emacs=, :emacs>, :emacs>=, shorthand for
>   `:if (version...)`
>
> * :hook-suffix Changes `use-package-hook-name-suffix' value only in the
>   current use-package declaration.
>
> * :hook+ Like default :hook, but allows to set the hook depth and set
>   multiple functions in the hook (or for each hook).
>
>   Although I tried to make it compatible with :hook, there may be some
>   things I missed, so I decided to put it separately instead of merging
>   it with :hook.  In addition, its syntax is more complex compared to
>   :hook.

I can imagine that the name is confusing to beginners, and also question
if it might be cleaner to just advise users to use `add-hook' if they
want to do something specific and more technical.

> * :local-set Bind variables locally when entering to a mode or to a hook(s).
>   An alternative to  `:hook (hook . (lambda () (setq-local ...)))`
>
> * :setopt Like :custom, but can also bind plain variables.
>   This uses the `setopt` function for bind the variables.

Would it make sense to re-use :custom but modify the behaviour with a
user-option?

> * :which-key-replacement A simple way to set which-key replacements.

Wrt. the patch, I would still merge the files into one, instead of
having each keyword in a separate file.

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

From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: John Wiegley <johnw <at> newartisans.com>, Eli Zaretskii <eliz <at> gnu.org>,
 79106 <at> debbugs.gnu.org
Subject: Re: bug#79106: [PATCH] Add new optional keywords to use-package
Date: Tue, 29 Jul 2025 00:33:36 -0600

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

Philip Kaludercic <philipk <at> posteo.net> writes:

> Elijah Gabe Pérez <eg642616 <at> gmail.com> writes:
>
> I guess it would be good to discuss the content of the patch now that we
> are considering to merge it.

Sure.

>> Tags: patch
>>
>> As discussed in
>> https://lists.gnu.org/archive/html/emacs-devel/2025-07/msg00354.html
>>
>> This patch add new optional keywords to use-package, most of them are
>> inspired by suggestions from use-package bug-tracker on github
>>
>> This includes following keywords:
>>
>> * :advice Add or remove function advices.
>
> I did not understand how this uses :advice to create something
> use-package specific that has an advantage over `define-advice'.

This acts more to `advice-add` than `define-advice`.  It is intended to
add advices from some packages, such as consult, which has the
`consult-register-window` function, that is intended to override
`register-preview`.

This is also inspired by leaf.el which have `:advice` and `:advice-remove`.

>> * :defvar-keymap Define a new keymap or override an existent one.
>
> Why is this something that a user would be interested in when
> configuring a package?

:defvar-keymap is meant for people that wants to use their own
keybindings in a mode (such as cua-mode) instead mode keybindings.

In my case it's useful when i want to use a few keybindings from a mode,
not all.

>> * :doc Document the use-package declaration instead using comments.
>>
>> * :tag Like :doc, but for categorizing.
>>   (This and :doc does nothing)
>
> Can you explain what these tags are good for?

At this moment, both :tag (and :doc) are useless, the only use I can see
for it would be as an identifier for when someone wants to export their
configuration as a web page.  I decided include them because I've seen
some configurations that use them (either from leaf.el or a personal
extension).

Perhaps in the future they can be modified to give a better use, but at
this moment I can't think of any.

>> * :hook+ Like default :hook, but allows to set the hook depth and set
>>   multiple functions in the hook (or for each hook).
>>
>>   Although I tried to make it compatible with :hook, there may be some
>>   things I missed, so I decided to put it separately instead of merging
>>   it with :hook.  In addition, its syntax is more complex compared to
>>   :hook.
>
> I can imagine that the name is confusing to beginners, and also question
> if it might be cleaner to just advise users to use `add-hook' if they
> want to do something specific and more technical.

Yeah, but :hook+ already covers most of the basics for add-hook.

It can put the same depth for all the hooks in a region:

  (:depth -10
    (prog-mode . whitespace-mode) ; <- -10
    (xml-mode . electric-pair-mode)) ; <- -10

>> * :setopt Like :custom, but can also bind plain variables.
>>   This uses the `setopt` function for bind the variables.
>
> Would it make sense to re-use :custom but modify the behaviour with a
> user-option?

I didn't quite understand this, did you mean to modify :custom for
handle this instead? In that case, it would better to ask to John.

> Wrt. the patch, I would still merge the files into one, instead of
> having each keyword in a separate file.

This is inconvenient, since if someone wants to use only one of these
keywords, they would have to load the entire file.

Keeping them separate prevents this and is also easier to maintain and
move them to ELPA (if it is decided in the future).


Also I'm sending a fixed patch, I'm not sure if the additional keywords
should be documented in the manual.

[0001-Add-new-optional-keywords-to-use-package.patch (text/x-patch, attachment)]

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

-- 
- E.G via Gnus and Org.

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

From: Karthik Chikmagalur <karthikchikmagalur <at> gmail.com>
To: Elijah Gabe Pérez <eg642616 <at> gmail.com>
Cc: John Wiegley <johnw <at> newartisans.com>,
 Philip Kaludercic <philipk <at> posteo.net>, 79106 <at> debbugs.gnu.org,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#79106: [PATCH] Add new optional keywords to use-package
Date: Tue, 29 Jul 2025 23:58:07 -0700

My general feedback is that most of these keywords are adding complexity
without providing much benefit over the more explicit form of placing
code in :init, :preface or :config.

>>> This includes following keywords:
>>>
>>> * :advice Add or remove function advices.
>>
>> I did not understand how this uses :advice to create something
>> use-package specific that has an advantage over `define-advice'.
>
> This acts more to `advice-add` than `define-advice`.  It is intended to
> add advices from some packages, such as consult, which has the
> `consult-register-window` function, that is intended to override
> `register-preview`.
>
> This is also inspired by leaf.el which have `:advice` and `:advice-remove`.

It seems better to me to use :init followed by advice-add.  Version in
the patch:

(use-package test
  :advice
  (:add my-function :override other-function)
  (:add my-other-function :around (lambda (...) ...)))

Current approach:

(use-package test
  :init
  (advice-add 'other-function :override 'my-function)
  (advice-add 'my-other-function :around (lambda (...) ...)))

The current approach seems superior to introducing a new keyword -- it
does not require learning new syntax, and the advice statements under
:init can be independently evaluated (with eval-last-sexp) if required.
It's also not saving the user any typing, as far as I can tell?

>>> * :defvar-keymap Define a new keymap or override an existent one.

I have the same thought here -- it's not any more work to write a
defvar-keymap statement in :init, and it can specify all aspects of the
keymap (such as repeat states, keymap sparsity etc), which this cannot
do.

>>> * :hook+ Like default :hook, but allows to set the hook depth and set
>>>   multiple functions in the hook (or for each hook).
>>>
>>>   Although I tried to make it compatible with :hook, there may be some
>>>   things I missed, so I decided to put it separately instead of merging
>>>   it with :hook.  In addition, its syntax is more complex compared to
>>>   :hook.

I think :hook can be generalized a bit, and that might be better than
introducing :hook+.

In the following example:

(use-package test
  :hook+
  ((text-mode prog-mode)
   . (:multi auto-fill-mode
             show-paren-mode))
  (org-mode
   . (:multi (lambda () something)
             org-indent-mode))
  (:depth -4
          (outline-mode
           . (:multi (lambda () (print "-4 depth!"))
                     outline-hide-body))))
                     
The price of "magic" syntax like :multi and :depth here is paid by the
user who might use them infrequently (compared to add-hook) and have to
relearn it every time.

But once there is public code out there that uses :hook+, the price will
also be paid by all parties when sharing code.  New Emacs users often
copy code blocks and tweak them without understanding it.  It is much
easier for them to try to understand a series of add-hook statements in
:init than something like the above.  There is nothing they can run
describe-symbol on, for example.

>> I can imagine that the name is confusing to beginners, and also question
>> if it might be cleaner to just advise users to use `add-hook' if they
>> want to do something specific and more technical.

I agree with Philip here.

>> Wrt. the patch, I would still merge the files into one, instead of
>> having each keyword in a separate file.
>
> This is inconvenient, since if someone wants to use only one of these
> keywords, they would have to load the entire file.
>
> Keeping them separate prevents this and is also easier to maintain and
> move them to ELPA (if it is decided in the future).

Here I agree with Elijah, although the Emacs maintainers know best.

Karthik

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

From: Philip Kaludercic <philipk <at> posteo.net>
To: Karthik Chikmagalur <karthikchikmagalur <at> gmail.com>
Cc: John Wiegley <johnw <at> newartisans.com>,
 Elijah Gabe Pérez <eg642616 <at> gmail.com>, 79106 <at> debbugs.gnu.org,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#79106: [PATCH] Add new optional keywords to use-package
Date: Wed, 30 Jul 2025 10:21:44 +0000

Karthik Chikmagalur <karthikchikmagalur <at> gmail.com> writes:

> My general feedback is that most of these keywords are adding complexity
> without providing much benefit over the more explicit form of placing
> code in :init, :preface or :config.

I should clarify, that I don't use `use-package', so I don't know what
users are looking for.  I can just say, that in my configuration macro
`setup' the guiding principle for adding a local macro (which roughly
corresponds to a keyword in use-package) is that there is some local
context that can be exploited to avoid duplication.  For instance,

  (setup texinfo
    (:hook reftex-mode)
    (:unbind "RET"))

expands to

  (progn
    (add-hook 'texinfo-mode-hook (function reftex-mode))
    (eval-after-load 'texinfo
      (function (lambda nil (define-key texinfo-mode-map "." nil)))))

where the fact that texinfo is being configured is used to determine
what hook to add the function to, what feature to wait for until it has
been loaded and what map to modify thereafter.  I have macros like
:option (that correspond to use-package's `:custom', but I don't advise
using them and never wanted to add more like these, because they do not
do anything more than just `setopt' (though to be fair, setopt is newer
than :option)).

Perhaps this is also an interesting heuristic to decide what new
keywords are interesting for use-package as well -- unless we want to
say that the ideal should be to be able to express everything in
non-evaluated code -- i.e. that :init and :config are in some sense bad
style that distract from the declarative nature of use-package, and just
exist to plug the holes of configuration patterns that don't yet have
keywords.

>>>> This includes following keywords:
>>>>
>>>> * :advice Add or remove function advices.
>>>
>>> I did not understand how this uses :advice to create something
>>> use-package specific that has an advantage over `define-advice'.
>>
>> This acts more to `advice-add` than `define-advice`.  It is intended to
>> add advices from some packages, such as consult, which has the
>> `consult-register-window` function, that is intended to override
>> `register-preview`.
>>
>> This is also inspired by leaf.el which have `:advice` and `:advice-remove`.
>
> It seems better to me to use :init followed by advice-add.  Version in
> the patch:
a>
> (use-package test
>   :advice
>   (:add my-function :override other-function)
>   (:add my-other-function :around (lambda (...) ...)))
>
> Current approach:
>
> (use-package test
>   :init
>   (advice-add 'other-function :override 'my-function)
>   (advice-add 'my-other-function :around (lambda (...) ...)))
>
> The current approach seems superior to introducing a new keyword -- it
> does not require learning new syntax, and the advice statements under
> :init can be independently evaluated (with eval-last-sexp) if required.
> It's also not saving the user any typing, as far as I can tell?

Right, this was what I was getting at.  Functionally, the new keyword
doesn't exploit the fact that we are configuring the package `test'.
But as I said, if the goal is to have a consistent syntax for
everything, then this might be desirable. 

>>>> * :defvar-keymap Define a new keymap or override an existent one.
>
> I have the same thought here -- it's not any more work to write a
> defvar-keymap statement in :init, and it can specify all aspects of the
> keymap (such as repeat states, keymap sparsity etc), which this cannot
> do.
>
>>>> * :hook+ Like default :hook, but allows to set the hook depth and set
>>>>   multiple functions in the hook (or for each hook).
>>>>
>>>>   Although I tried to make it compatible with :hook, there may be some
>>>>   things I missed, so I decided to put it separately instead of merging
>>>>   it with :hook.  In addition, its syntax is more complex compared to
>>>>   :hook.
>
> I think :hook can be generalized a bit, and that might be better than
> introducing :hook+.
>
> In the following example:
>
> (use-package test
>   :hook+
>   ((text-mode prog-mode)
>    . (:multi auto-fill-mode
>              show-paren-mode))
>   (org-mode
>    . (:multi (lambda () something)
>              org-indent-mode))
>   (:depth -4
>           (outline-mode
>            . (:multi (lambda () (print "-4 depth!"))
>                      outline-hide-body))))
>                      
> The price of "magic" syntax like :multi and :depth here is paid by the
> user who might use them infrequently (compared to add-hook) and have to
> relearn it every time.
>
> But once there is public code out there that uses :hook+, the price will
> also be paid by all parties when sharing code.  New Emacs users often
> copy code blocks and tweak them without understanding it.  It is much
> easier for them to try to understand a series of add-hook statements in
> :init than something like the above.  There is nothing they can run
> describe-symbol on, for example.
>
>>> I can imagine that the name is confusing to beginners, and also question
>>> if it might be cleaner to just advise users to use `add-hook' if they
>>> want to do something specific and more technical.
>
> I agree with Philip here.
>
>>> Wrt. the patch, I would still merge the files into one, instead of
>>> having each keyword in a separate file.
>>
>> This is inconvenient, since if someone wants to use only one of these
>> keywords, they would have to load the entire file.

IIRC correctly, the overhead of loading just a few files would probably
exceed the time saved from having to only parse the necessary ones.  We
can benchmark this in more details if we want to be sure, but there is a
reason that we have options like `package-quickstart'.

>> Keeping them separate prevents this and is also easier to maintain and
>> move them to ELPA (if it is decided in the future).

That shouldn't be our concern here, as if we add the features to the
core, the danger of moving it out to ELPA are very slim -- and even if,
it would take a long time of deprecation where we would be free to
change and split up the files again.  And for my suggestions, having a
use-package-x.el file, it wouldn't be make much of a difference in
effort to move that or a larger number of files out to ELPA.

> Here I agree with Elijah, although the Emacs maintainers know best.
>
> Karthik

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

From: Stéphane Marks <shipmints <at> gmail.com>
To: Karthik Chikmagalur <karthikchikmagalur <at> gmail.com>
Cc: John Wiegley <johnw <at> newartisans.com>,
 Elijah Gabe Pérez <eg642616 <at> gmail.com>, 79106 <at> debbugs.gnu.org,
 Philip Kaludercic <philipk <at> posteo.net>, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#79106: [PATCH] Add new optional keywords to use-package
Date: Wed, 30 Jul 2025 11:25:15 -0400

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

On Wed, Jul 30, 2025 at 3:03 AM Karthik Chikmagalur <
karthikchikmagalur <at> gmail.com> wrote:

> My general feedback is that most of these keywords are adding complexity
> without providing much benefit over the more explicit form of placing
> code in :init, :preface or :config.
>
> >>> This includes following keywords:
> >>>
> >>> * :advice Add or remove function advices.
> >>
> >> I did not understand how this uses :advice to create something
> >> use-package specific that has an advantage over `define-advice'.
> >
> > This acts more to `advice-add` than `define-advice`.  It is intended to
> > add advices from some packages, such as consult, which has the
> > `consult-register-window` function, that is intended to override
> > `register-preview`.
> >
> > This is also inspired by leaf.el which have `:advice` and
> `:advice-remove`.
>
> It seems better to me to use :init followed by advice-add.  Version in
> the patch:
>
> (use-package test
>   :advice
>   (:add my-function :override other-function)
>   (:add my-other-function :around (lambda (...) ...)))
>
> Current approach:
>
> (use-package test
>   :init
>   (advice-add 'other-function :override 'my-function)
>   (advice-add 'my-other-function :around (lambda (...) ...)))
>
> The current approach seems superior to introducing a new keyword -- it
> does not require learning new syntax, and the advice statements under
> :init can be independently evaluated (with eval-last-sexp) if required.
> It's also not saving the user any typing, as far as I can tell?
>
> >>> * :defvar-keymap Define a new keymap or override an existent one.
>
> I have the same thought here -- it's not any more work to write a
> defvar-keymap statement in :init, and it can specify all aspects of the
> keymap (such as repeat states, keymap sparsity etc), which this cannot
> do.
>
> >>> * :hook+ Like default :hook, but allows to set the hook depth and set
> >>>   multiple functions in the hook (or for each hook).
> >>>
> >>>   Although I tried to make it compatible with :hook, there may be some
> >>>   things I missed, so I decided to put it separately instead of merging
> >>>   it with :hook.  In addition, its syntax is more complex compared to
> >>>   :hook.
>
> I think :hook can be generalized a bit, and that might be better than
> introducing :hook+.
>
> In the following example:
>
> (use-package test
>   :hook+
>   ((text-mode prog-mode)
>    . (:multi auto-fill-mode
>              show-paren-mode))
>   (org-mode
>    . (:multi (lambda () something)
>              org-indent-mode))
>   (:depth -4
>           (outline-mode
>            . (:multi (lambda () (print "-4 depth!"))
>                      outline-hide-body))))
>
> The price of "magic" syntax like :multi and :depth here is paid by the
> user who might use them infrequently (compared to add-hook) and have to
> relearn it every time.
>
> But once there is public code out there that uses :hook+, the price will
> also be paid by all parties when sharing code.  New Emacs users often
> copy code blocks and tweak them without understanding it.  It is much
> easier for them to try to understand a series of add-hook statements in
> :init than something like the above.  There is nothing they can run
> describe-symbol on, for example.
>
> >> I can imagine that the name is confusing to beginners, and also question
> >> if it might be cleaner to just advise users to use `add-hook' if they
> >> want to do something specific and more technical.
>
> I agree with Philip here.
>
> >> Wrt. the patch, I would still merge the files into one, instead of
> >> having each keyword in a separate file.
> >
> > This is inconvenient, since if someone wants to use only one of these
> > keywords, they would have to load the entire file.
> >
> > Keeping them separate prevents this and is also easier to maintain and
> > move them to ELPA (if it is decided in the future).
>
> Here I agree with Elijah, although the Emacs maintainers know best.
>

I tend to agree with Karthik, and would not use any of the new keywords in
my configuration.  I suspect it will encourage lack of understanding, and
increase support burden.  e.g., for sufficiently sophisticated users that
need to specify hook depth, they're likely also providing their own
functions and those have to be defined somewhere (and lambdas are
discouraged in hooks, right?).  In my configuration, I tend to pair
`remove-hook` and `advice-remove` calls, which I comment out, to facilitate
testing and comparison of results from unadvised functions, and to make it
easy to remove a named hook also for the same reasons.  These keywords will
discourage learning Elisp programming, which even the most minor of
function advices requires to foster a mental model.

Are these syntactic sugar keywords truly necessary if the evidence of
requests on the core Emacs mailing lists has been very limited?  I'm not
sure using Github issues is as valuable as core discussions tend to be.

-Stéphane

[Message part 2 (text/html, inline)]

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

From: John Wiegley <johnw <at> newartisans.com>
To: Stéphane Marks <shipmints <at> gmail.com>
Cc: Karthik Chikmagalur <karthikchikmagalur <at> gmail.com>,
 Elijah Gabe Pérez <eg642616 <at> gmail.com>, 79106 <at> debbugs.gnu.org,
 Philip Kaludercic <philipk <at> posteo.net>, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#79106: [PATCH] Add new optional keywords to use-package
Date: Wed, 30 Jul 2025 11:07:44 -0700

>>>>> Stéphane Marks <shipmints <at> gmail.com> writes:

> I tend to agree with Karthik, and would not use any of the new
> keywords in my configuration.  I suspect it will encourage lack of
> understanding, and increase support burden.  e.g., for sufficiently
> sophisticated users that need to specify hook depth, they're likely
> also providing their own functions and those have to be defined
> somewhere (and lambdas are discouraged in hooks, right?).  In my
> configuration, I tend to pair `remove-hook` and `advice-remove`
> calls, which I comment out, to facilitate testing and comparison of
> results from unadvised functions, and to make it easy to remove a
> named hook also for the same reasons.  These keywords will discourage
> learning Elisp programming, which even the most minor of function
> advices requires to foster a mental model.

I must say that I respectfully disagree with Karthik’s reasoning here. I don’t
think it’s a good design principle to remove functionality from the hands of
everyone, only for the sake of those who would not fully understand it — and
thus, who probably wouldn’t have used it in the first place.

If we take this logic to the extreme, there would be no reason for use-package
at all, because in the end it’s just Elisp that you can write yourself. The
main reason I created it is to codify best practices that I didn’t want to
have to repeat.

Take :hook for example. It codifies this pattern:

  If :demand is being used (or is implied), it’s just add-hook with the tiny
  syntactic convenience of not needed to put `-hook` at the end of the symbol
  name, or the ability to just say `SYM` and have the hook name inferred.

  If :demand is not being used (or is not implied), then it additionally
  declares an autoload for the function being added to the hook. This autoload
  is probably already being defined by the package, so doubtful it’s needed.

Is it really better to say:

  (use-package foo :hook bar)

Than just:

  (add-hook 'bar-hook #'foo-mode)

Probably not really. The former hides a bit of logic — and thus, opens the
door to confusion — while the second always works as intended and can be
separately evaluated, etc. But the point is: *the first form is what I want to
write, as an Emacs user who does understand what’s going on*.

Adding :hook+ would allow me to additionally specify depth, which at the
moment I cannot do, requiring me to undo the declarative form and use the
procedural form in order to pass a depth argument.

Lastly, use-package-x (and family?) is *opt-in*. If people want to post their
use of it online, and others want to copy&paste it, that’s on them. I wouldn’t
try to prevent them from having easy access to those features simply because
some third party might try to join in the fun and not fully understand what’s
going on.

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

Sponsor my open source on github.com/sponsors/jwiegley or patreon.com/jwiegley

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

From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
To: Philip Kaludercic <philipk <at> posteo.net>, Eli Zaretskii <eliz <at> gnu.org>
Cc: Karthik Chikmagalur <karthikchikmagalur <at> gmail.com>, 79106 <at> debbugs.gnu.org,
 Stéphane Marks <shipmints <at> gmail.com>,
 John Wiegley <johnw <at> newartisans.com>
Subject: Re: bug#79106: [PATCH] Add new optional keywords to use-package
Date: Wed, 30 Jul 2025 17:08:32 -0600

Since this discussion (and the emacs-devel discussion) doesn't seem to
be leading to any solution (besides the divided opinions), my solution i
can think of would be to make the keywords that may be considered useful
(I'm not sure which ones) part of use-package, and leave the rest in
ELPA (or in NonGNU) in a single package.

Of course, this package was not intended to be part of use-package, just
an **optional** thing that i wanted to have.

-- 
- E.G via Gnus and Org.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Elijah Gabe Pérez <eg642616 <at> gmail.com>
Cc: karthikchikmagalur <at> gmail.com, philipk <at> posteo.net, 79106 <at> debbugs.gnu.org,
 shipmints <at> gmail.com, johnw <at> newartisans.com
Subject: Re: bug#79106: [PATCH] Add new optional keywords to use-package
Date: Sat, 02 Aug 2025 17:38:42 +0300

> From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
> Cc: Stéphane Marks <shipmints <at> gmail.com>,  Karthik
>  Chikmagalur
>  <karthikchikmagalur <at> gmail.com>,  79106 <at> debbugs.gnu.org, John Wiegley
>  <johnw <at> newartisans.com>
> Date: Wed, 30 Jul 2025 17:08:32 -0600
> 
> Since this discussion (and the emacs-devel discussion) doesn't seem to
> be leading to any solution (besides the divided opinions), my solution i
> can think of would be to make the keywords that may be considered useful
> (I'm not sure which ones) part of use-package, and leave the rest in
> ELPA (or in NonGNU) in a single package.
> 
> Of course, this package was not intended to be part of use-package, just
> an **optional** thing that i wanted to have.

From my POV, we can install these changes in core, assuming that you
can post a patch that incorporates the relevant parts of the
discussions.

Please also rename the new files such that they don't include the
"-x-" part.  That is, instead of, e.g., use-package-x-advice.el add a
file use-package-advice.el.  Also, please put them inside
lisp/use-package/, not in its subdirectory.

Thanks.

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

From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: karthikchikmagalur <at> gmail.com, philipk <at> posteo.net, 79106 <at> debbugs.gnu.org,
 shipmints <at> gmail.com, johnw <at> newartisans.com
Subject: Re: bug#79106: [PATCH] Add new optional keywords to use-package
Date: Sat, 02 Aug 2025 14:39:09 -0600

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

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

>> From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
>> Cc: Stéphane Marks <shipmints <at> gmail.com>,  Karthik
>>  Chikmagalur
>>  <karthikchikmagalur <at> gmail.com>,  79106 <at> debbugs.gnu.org, John Wiegley
>>  <johnw <at> newartisans.com>
>> Date: Wed, 30 Jul 2025 17:08:32 -0600
>> 
>> Since this discussion (and the emacs-devel discussion) doesn't seem to
>> be leading to any solution (besides the divided opinions), my solution i
>> can think of would be to make the keywords that may be considered useful
>> (I'm not sure which ones) part of use-package, and leave the rest in
>> ELPA (or in NonGNU) in a single package.
>> 
>> Of course, this package was not intended to be part of use-package, just
>> an **optional** thing that i wanted to have.
>
> From my POV, we can install these changes in core, assuming that you
> can post a patch that incorporates the relevant parts of the
> discussions.

Sounds good to me, I've updated the patch for include *only* the
keywords that people may find useful.

The rest can be kept in my use-package-x repository.

> Please also rename the new files such that they don't include the
> "-x-" part.  That is, instead of, e.g., use-package-x-advice.el add a
> file use-package-advice.el.  Also, please put them inside
> lisp/use-package/, not in its subdirectory.

Done:

[0001-Add-new-optional-keywords-to-use-package.-Bug-79106.patch (text/x-patch, attachment)]

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

NOTE: The patch does not yet include the corresponding change in the
use-package manual, I am waiting for feedback first.
-- 
- E.G via Gnus and Org.

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

From: Karthik Chikmagalur <karthikchikmagalur <at> gmail.com>
To: Elijah Gabe Pérez <eg642616 <at> gmail.com>, Eli Zaretskii
 <eliz <at> gnu.org>
Cc: johnw <at> newartisans.com, philipk <at> posteo.net, 79106 <at> debbugs.gnu.org,
 shipmints <at> gmail.com
Subject: Re: bug#79106: [PATCH] Add new optional keywords to use-package
Date: Sat, 02 Aug 2025 16:03:54 -0700

>> From my POV, we can install these changes in core, assuming that you
>> can post a patch that incorporates the relevant parts of the
>> discussions.
>
> Sounds good to me, I've updated the patch for include *only* the
> keywords that people may find useful.
>
> The rest can be kept in my use-package-x repository.

Since support for :hook+ is being added, I have a suggestion to make its
syntax more in-line with add-hook, so the user does not have to learn
new syntax.  This might not be possible (or lead to ambiguous parsing),
so feel free to ignore it if this is the case.

add-hook takes the arguments (HOOK FUNCTION DEPTH LOCAL), so perhaps
:hook+ can do the same?

-------------------------------------

Suggestion 1: allow many hooks to be specified in a list

:hook+ (foo-mode . (bar baz quux))

adds functions bar, baz and quux to foo-mode-hook.  (To disambiguate
between a list of hook functions and a lambda, you can look at the car
of the list maybe?)

Suggestion 2: allow many hooks to be added to.  (:hook already does this)

:hook+ ((foo-mode cor-mode) . (bar baz quux))

Adds the three functions to both foo-mode-hook and cor-mode-hook.

Suggestion 3: Allow DEPTH and LOCAL to be optionally specified with the functions,
in the same order as add-hook.

:hook+ (foo-mode . ((bar 90 t)
                    baz
                    (quux -30)
                    (cor nil t))

will install 
- bar at depth 90, to be run buffer-locally when foo-mode-hook runs
- baz without special accommodations, and
- quux at depth -30.
- cor buffer-locally with default depth

To distinguish between (bar 90 t) and (lambda () ...), you could again
examine the car of the list.

-------------------------------------

Again, there might be ambiguities in parsing that I'm not aware of, but
if this is possible I think this is an improvement over both :hook and
the currently proposed :hook+ syntax.

Karthik

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

From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
To: Karthik Chikmagalur <karthikchikmagalur <at> gmail.com>
Cc: johnw <at> newartisans.com, Eli Zaretskii <eliz <at> gnu.org>, 79106 <at> debbugs.gnu.org,
 philipk <at> posteo.net, shipmints <at> gmail.com
Subject: Re: bug#79106: [PATCH] Add new optional keywords to use-package
Date: Sat, 02 Aug 2025 19:42:24 -0600

Karthik Chikmagalur <karthikchikmagalur <at> gmail.com> writes:

>>> From my POV, we can install these changes in core, assuming that
>>> you
>>> can post a patch that incorporates the relevant parts of the
>>> discussions.
>>
>> Sounds good to me, I've updated the patch for include *only* the
>> keywords that people may find useful.
>>
>> The rest can be kept in my use-package-x repository.
>
> Since support for :hook+ is being added, I have a suggestion to make
> its
> syntax more in-line with add-hook, so the user does not have to learn
> new syntax.  This might not be possible (or lead to ambiguous
> parsing),
> so feel free to ignore it if this is the case.
>
> add-hook takes the arguments (HOOK FUNCTION DEPTH LOCAL), so perhaps
> :hook+ can do the same?
>
> -------------------------------------
>
> Suggestion 1: allow many hooks to be specified in a list
>
> :hook+ (foo-mode . (bar baz quux))
>
> adds functions bar, baz and quux to foo-mode-hook.  (To disambiguate
> between a list of hook functions and a lambda, you can look at the car
> of the list maybe?)

It is not possible because (foo-mode . (bar baz quux)) is expanded as
(foo-mode bar baz quux), and this can be misinterpreted by :hook+ as a
list of hooks.

The only workaround i found is making a kind of separator (:multi),
which tells :hook+ the cdr is a list of functions, not part of a list of
hooks.

I know that :multi can look weird (even i was thinking in rename it [1]
or use a better separator), but it was the only solution i found and
worked.

> Suggestion 2: allow many hooks to be added to.  (:hook already does
> this)
>
> :hook+ ((foo-mode cor-mode) . (bar baz quux))
>
> Adds the three functions to both foo-mode-hook and cor-mode-hook.

Similar problem as previous.

> Suggestion 3: Allow DEPTH and LOCAL to be optionally specified with
> the functions,
> in the same order as add-hook.
>
> :hook+ (foo-mode . ((bar 90 t)
>                     baz
>                     (quux -30)
>                     (cor nil t))
>
> will install 
> - bar at depth 90, to be run buffer-locally when foo-mode-hook runs
> - baz without special accommodations, and
> - quux at depth -30.
> - cor buffer-locally with default depth

I like this, i think i can implement only the "local" part.
But of course, only part of :multi.

If i can get rid of `:multi` i can implement this, but it will look
somewhat ugly:

  :hook+ (foo-mode . '((bar 90 t)))

[1] Some of my alternatives were using `quote` or `list` instead of
`:multi`, and another was using `'(fn fn2 fn3)`, or even use a list
instead of a cons-cell, these actually work, but I didn't know which of
them to use.

-- 
- E.G via Gnus and Org.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Elijah Gabe Pérez <eg642616 <at> gmail.com>
Cc: karthikchikmagalur <at> gmail.com, philipk <at> posteo.net, 79106 <at> debbugs.gnu.org,
 shipmints <at> gmail.com, johnw <at> newartisans.com
Subject: Re: bug#79106: [PATCH] Add new optional keywords to use-package
Date: Thu, 07 Aug 2025 16:56:23 +0300

> From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  johnw <at> newartisans.com,
>   philipk <at> posteo.net,  79106 <at> debbugs.gnu.org,  shipmints <at> gmail.com
> Date: Sat, 02 Aug 2025 19:42:24 -0600
> 
> Karthik Chikmagalur <karthikchikmagalur <at> gmail.com> writes:
> 
> >>> From my POV, we can install these changes in core, assuming that
> >>> you
> >>> can post a patch that incorporates the relevant parts of the
> >>> discussions.
> >>
> >> Sounds good to me, I've updated the patch for include *only* the
> >> keywords that people may find useful.
> >>
> >> The rest can be kept in my use-package-x repository.
> >
> > Since support for :hook+ is being added, I have a suggestion to make
> > its
> > syntax more in-line with add-hook, so the user does not have to learn
> > new syntax.  This might not be possible (or lead to ambiguous
> > parsing),
> > so feel free to ignore it if this is the case.
> >
> > add-hook takes the arguments (HOOK FUNCTION DEPTH LOCAL), so perhaps
> > :hook+ can do the same?
> >
> > -------------------------------------
> >
> > Suggestion 1: allow many hooks to be specified in a list
> >
> > :hook+ (foo-mode . (bar baz quux))
> >
> > adds functions bar, baz and quux to foo-mode-hook.  (To disambiguate
> > between a list of hook functions and a lambda, you can look at the car
> > of the list maybe?)
> 
> It is not possible because (foo-mode . (bar baz quux)) is expanded as
> (foo-mode bar baz quux), and this can be misinterpreted by :hook+ as a
> list of hooks.
> 
> The only workaround i found is making a kind of separator (:multi),
> which tells :hook+ the cdr is a list of functions, not part of a list of
> hooks.
> 
> I know that :multi can look weird (even i was thinking in rename it [1]
> or use a better separator), but it was the only solution i found and
> worked.
> 
> > Suggestion 2: allow many hooks to be added to.  (:hook already does
> > this)
> >
> > :hook+ ((foo-mode cor-mode) . (bar baz quux))
> >
> > Adds the three functions to both foo-mode-hook and cor-mode-hook.
> 
> Similar problem as previous.
> 
> > Suggestion 3: Allow DEPTH and LOCAL to be optionally specified with
> > the functions,
> > in the same order as add-hook.
> >
> > :hook+ (foo-mode . ((bar 90 t)
> >                     baz
> >                     (quux -30)
> >                     (cor nil t))
> >
> > will install 
> > - bar at depth 90, to be run buffer-locally when foo-mode-hook runs
> > - baz without special accommodations, and
> > - quux at depth -30.
> > - cor buffer-locally with default depth
> 
> I like this, i think i can implement only the "local" part.
> But of course, only part of :multi.
> 
> If i can get rid of `:multi` i can implement this, but it will look
> somewhat ugly:
> 
>   :hook+ (foo-mode . '((bar 90 t)))

So what is the outcome of this discussion?  Are you working on an
updated patch, or should I install the last one you posted?

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

From: Philip Kaludercic <philipk <at> posteo.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: karthikchikmagalur <at> gmail.com,
 Elijah Gabe Pérez <eg642616 <at> gmail.com>, 79106 <at> debbugs.gnu.org,
 shipmints <at> gmail.com, johnw <at> newartisans.com
Subject: Re: bug#79106: [PATCH] Add new optional keywords to use-package
Date: Thu, 07 Aug 2025 14:26:53 +0000

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

>> From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>,  johnw <at> newartisans.com,
>>   philipk <at> posteo.net,  79106 <at> debbugs.gnu.org,  shipmints <at> gmail.com
>> Date: Sat, 02 Aug 2025 19:42:24 -0600
>> 
>> Karthik Chikmagalur <karthikchikmagalur <at> gmail.com> writes:
>> 
>> >>> From my POV, we can install these changes in core, assuming that
>> >>> you
>> >>> can post a patch that incorporates the relevant parts of the
>> >>> discussions.
>> >>
>> >> Sounds good to me, I've updated the patch for include *only* the
>> >> keywords that people may find useful.
>> >>
>> >> The rest can be kept in my use-package-x repository.
>> >
>> > Since support for :hook+ is being added, I have a suggestion to make
>> > its
>> > syntax more in-line with add-hook, so the user does not have to learn
>> > new syntax.  This might not be possible (or lead to ambiguous
>> > parsing),
>> > so feel free to ignore it if this is the case.
>> >
>> > add-hook takes the arguments (HOOK FUNCTION DEPTH LOCAL), so perhaps
>> > :hook+ can do the same?
>> >
>> > -------------------------------------
>> >
>> > Suggestion 1: allow many hooks to be specified in a list
>> >
>> > :hook+ (foo-mode . (bar baz quux))
>> >
>> > adds functions bar, baz and quux to foo-mode-hook.  (To disambiguate
>> > between a list of hook functions and a lambda, you can look at the car
>> > of the list maybe?)
>> 
>> It is not possible because (foo-mode . (bar baz quux)) is expanded as
>> (foo-mode bar baz quux), and this can be misinterpreted by :hook+ as a
>> list of hooks.
>> 
>> The only workaround i found is making a kind of separator (:multi),
>> which tells :hook+ the cdr is a list of functions, not part of a list of
>> hooks.
>> 
>> I know that :multi can look weird (even i was thinking in rename it [1]
>> or use a better separator), but it was the only solution i found and
>> worked.
>> 
>> > Suggestion 2: allow many hooks to be added to.  (:hook already does
>> > this)
>> >
>> > :hook+ ((foo-mode cor-mode) . (bar baz quux))
>> >
>> > Adds the three functions to both foo-mode-hook and cor-mode-hook.
>> 
>> Similar problem as previous.
>> 
>> > Suggestion 3: Allow DEPTH and LOCAL to be optionally specified with
>> > the functions,
>> > in the same order as add-hook.
>> >
>> > :hook+ (foo-mode . ((bar 90 t)
>> >                     baz
>> >                     (quux -30)
>> >                     (cor nil t))
>> >
>> > will install 
>> > - bar at depth 90, to be run buffer-locally when foo-mode-hook runs
>> > - baz without special accommodations, and
>> > - quux at depth -30.
>> > - cor buffer-locally with default depth
>> 
>> I like this, i think i can implement only the "local" part.
>> But of course, only part of :multi.
>> 
>> If i can get rid of `:multi` i can implement this, but it will look
>> somewhat ugly:
>> 
>>   :hook+ (foo-mode . '((bar 90 t)))
>
> So what is the outcome of this discussion?  Are you working on an
> updated patch, or should I install the last one you posted?

I believe there was a reasonable doubt whether we need some of the
keywords at all from the initial patch.  So my vote would be to hold
back from that option for now, and figure out what would make sense to
add to the core.

-- 
Philip Kaludercic

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: karthikchikmagalur <at> gmail.com, eg642616 <at> gmail.com, 79106 <at> debbugs.gnu.org,
 shipmints <at> gmail.com, johnw <at> newartisans.com
Subject: Re: bug#79106: [PATCH] Add new optional keywords to use-package
Date: Thu, 07 Aug 2025 17:52:12 +0300

> From: Philip Kaludercic <philipk <at> posteo.net>
> Cc: Elijah Gabe Pérez <eg642616 <at> gmail.com>,
>   karthikchikmagalur <at> gmail.com,
>   johnw <at> newartisans.com,  79106 <at> debbugs.gnu.org,  shipmints <at> gmail.com
> Date: Thu, 07 Aug 2025 14:26:53 +0000
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> > Suggestion 1: allow many hooks to be specified in a list
> >> >
> >> > :hook+ (foo-mode . (bar baz quux))
> >> >
> >> > adds functions bar, baz and quux to foo-mode-hook.  (To disambiguate
> >> > between a list of hook functions and a lambda, you can look at the car
> >> > of the list maybe?)
> >> 
> >> It is not possible because (foo-mode . (bar baz quux)) is expanded as
> >> (foo-mode bar baz quux), and this can be misinterpreted by :hook+ as a
> >> list of hooks.
> >> 
> >> The only workaround i found is making a kind of separator (:multi),
> >> which tells :hook+ the cdr is a list of functions, not part of a list of
> >> hooks.
> >> 
> >> I know that :multi can look weird (even i was thinking in rename it [1]
> >> or use a better separator), but it was the only solution i found and
> >> worked.
> >> 
> >> > Suggestion 2: allow many hooks to be added to.  (:hook already does
> >> > this)
> >> >
> >> > :hook+ ((foo-mode cor-mode) . (bar baz quux))
> >> >
> >> > Adds the three functions to both foo-mode-hook and cor-mode-hook.
> >> 
> >> Similar problem as previous.
> >> 
> >> > Suggestion 3: Allow DEPTH and LOCAL to be optionally specified with
> >> > the functions,
> >> > in the same order as add-hook.
> >> >
> >> > :hook+ (foo-mode . ((bar 90 t)
> >> >                     baz
> >> >                     (quux -30)
> >> >                     (cor nil t))
> >> >
> >> > will install 
> >> > - bar at depth 90, to be run buffer-locally when foo-mode-hook runs
> >> > - baz without special accommodations, and
> >> > - quux at depth -30.
> >> > - cor buffer-locally with default depth
> >> 
> >> I like this, i think i can implement only the "local" part.
> >> But of course, only part of :multi.
> >> 
> >> If i can get rid of `:multi` i can implement this, but it will look
> >> somewhat ugly:
> >> 
> >>   :hook+ (foo-mode . '((bar 90 t)))
> >
> > So what is the outcome of this discussion?  Are you working on an
> > updated patch, or should I install the last one you posted?
> 
> I believe there was a reasonable doubt whether we need some of the
> keywords at all from the initial patch.  So my vote would be to hold
> back from that option for now, and figure out what would make sense to
> add to the core.

Figure out how?

AFAIU, the latest round of comments just brought up an issue with
:hook+, and the rest didn't cause any objections?  Why not install
them?

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

From: "Elijah G." <eg642616 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Philip Kaludercic <philipk <at> posteo.net>
Cc: karthikchikmagalur <at> gmail.com, 79106 <at> debbugs.gnu.org, shipmints <at> gmail.com,
 johnw <at> newartisans.com
Subject: Re: bug#79106: [PATCH] Add new optional keywords to use-package
Date: Thu, 07 Aug 2025 09:44:46 -0600

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

>> From: Philip Kaludercic <philipk <at> posteo.net>
>> Cc: Elijah Gabe Pérez <eg642616 <at> gmail.com>,
>>   karthikchikmagalur <at> gmail.com,
>>   johnw <at> newartisans.com, 79106 <at> debbugs.gnu.org, shipmints <at> gmail.com
>> Date: Thu, 07 Aug 2025 14:26:53 +0000
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> >> > Suggestion 1: allow many hooks to be specified in a list
>> >> >
>> >> > :hook+ (foo-mode . (bar baz quux))
>> >> >
>> >> > adds functions bar, baz and quux to foo-mode-hook.  (To
>> >> > disambiguate
>> >> > between a list of hook functions and a lambda, you can look at
>> >> > the car
>> >> > of the list maybe?)
>> >> 
>> >> It is not possible because (foo-mode . (bar baz quux)) is
>> >> expanded as
>> >> (foo-mode bar baz quux), and this can be misinterpreted by :hook+
>> >> as a
>> >> list of hooks.
>> >> 
>> >> The only workaround i found is making a kind of separator
>> >> (:multi),
>> >> which tells :hook+ the cdr is a list of functions, not part of a
>> >> list of
>> >> hooks.
>> >> 
>> >> I know that :multi can look weird (even i was thinking in rename
>> >> it [1]
>> >> or use a better separator), but it was the only solution i found
>> >> and
>> >> worked.
>> >> 
>> >> > Suggestion 2: allow many hooks to be added to.  (:hook already
>> >> > does
>> >> > this)
>> >> >
>> >> > :hook+ ((foo-mode cor-mode) . (bar baz quux))
>> >> >
>> >> > Adds the three functions to both foo-mode-hook and
>> >> > cor-mode-hook.
>> >> 
>> >> Similar problem as previous.
>> >> 
>> >> > Suggestion 3: Allow DEPTH and LOCAL to be optionally specified
>> >> > with
>> >> > the functions,
>> >> > in the same order as add-hook.
>> >> >
>> >> > :hook+ (foo-mode . ((bar 90 t)
>> >> >                     baz
>> >> >                     (quux -30)
>> >> >                     (cor nil t))
>> >> >
>> >> > will install 
>> >> > - bar at depth 90, to be run buffer-locally when foo-mode-hook
>> >> > runs
>> >> > - baz without special accommodations, and
>> >> > - quux at depth -30.
>> >> > - cor buffer-locally with default depth
>> >> 
>> >> I like this, i think i can implement only the "local" part.
>> >> But of course, only part of :multi.
>> >> 
>> >> If i can get rid of `:multi` i can implement this, but it will
>> >> look
>> >> somewhat ugly:
>> >> 
>> >>   :hook+ (foo-mode . '((bar 90 t)))
>> >
>> > So what is the outcome of this discussion?  Are you working on an
>> > updated patch, or should I install the last one you posted?
>> 
>> I believe there was a reasonable doubt whether we need some of the
>> keywords at all from the initial patch.  So my vote would be to hold
>> back from that option for now, and figure out what would make sense
>> to
>> add to the core.
>
> Figure out how?
>
> AFAIU, the latest round of comments just brought up an issue with
> :hook+, and the rest didn't cause any objections?  Why not install
> them?

AFAIU, the keywords are considered useless and perhaps unnecessary, and
actually, they are, most of them can be useless and redundant or
confusing, but to remember, most of these keywords are ideas and
concepts that people asked for in use-package and could not be
implemented due to lack of time or had to be eliminated.

Based on the comments here and in emacs-devel, the only keyword i think
should be in core would be :hook+.

And this is based on a recent comment in use-package bug tracker on github:

---
  I myself have a wrapper around use-package for various reasons and
  I'll be adding support for this as I don't like having things like:

    :config
    ;; TODO: neo/use-package could support dept in :hook
    (add-hook 'after-init-hook 'neo/desktop-restore 99) ; :hook doesn't support depth

  but if it were supported by use-package it could benefit more people.
---

Currently, I'm trying to rewrite :hook+ to make it more familar to
add-hook (and see if it's possible to merge it with :hook).

So, I'll be sending a better patch when I have something.

-- 
- E.G via GNU Emacs Android port.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Elijah G." <eg642616 <at> gmail.com>, John Wiegley <johnw <at> gnu.org>
Cc: karthikchikmagalur <at> gmail.com, philipk <at> posteo.net, 79106 <at> debbugs.gnu.org,
 shipmints <at> gmail.com, johnw <at> newartisans.com
Subject: Re: bug#79106: [PATCH] Add new optional keywords to use-package
Date: Thu, 07 Aug 2025 19:19:15 +0300

> From: "Elijah G." <eg642616 <at> gmail.com>
> Cc: karthikchikmagalur <at> gmail.com,  79106 <at> debbugs.gnu.org,
>   shipmints <at> gmail.com,  johnw <at> newartisans.com
> Date: Thu, 07 Aug 2025 09:44:46 -0600
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> From: Philip Kaludercic <philipk <at> posteo.net>
> >> Cc: Elijah Gabe Pérez <eg642616 <at> gmail.com>,
> >>   karthikchikmagalur <at> gmail.com,
> >>   johnw <at> newartisans.com, 79106 <at> debbugs.gnu.org, shipmints <at> gmail.com
> >> Date: Thu, 07 Aug 2025 14:26:53 +0000
> >> 
> >> Eli Zaretskii <eliz <at> gnu.org> writes:
> >> 
> >> >> > Suggestion 1: allow many hooks to be specified in a list
> >> >> >
> >> >> > :hook+ (foo-mode . (bar baz quux))
> >> >> >
> >> >> > adds functions bar, baz and quux to foo-mode-hook.  (To
> >> >> > disambiguate
> >> >> > between a list of hook functions and a lambda, you can look at
> >> >> > the car
> >> >> > of the list maybe?)
> >> >> 
> >> >> It is not possible because (foo-mode . (bar baz quux)) is
> >> >> expanded as
> >> >> (foo-mode bar baz quux), and this can be misinterpreted by :hook+
> >> >> as a
> >> >> list of hooks.
> >> >> 
> >> >> The only workaround i found is making a kind of separator
> >> >> (:multi),
> >> >> which tells :hook+ the cdr is a list of functions, not part of a
> >> >> list of
> >> >> hooks.
> >> >> 
> >> >> I know that :multi can look weird (even i was thinking in rename
> >> >> it [1]
> >> >> or use a better separator), but it was the only solution i found
> >> >> and
> >> >> worked.
> >> >> 
> >> >> > Suggestion 2: allow many hooks to be added to.  (:hook already
> >> >> > does
> >> >> > this)
> >> >> >
> >> >> > :hook+ ((foo-mode cor-mode) . (bar baz quux))
> >> >> >
> >> >> > Adds the three functions to both foo-mode-hook and
> >> >> > cor-mode-hook.
> >> >> 
> >> >> Similar problem as previous.
> >> >> 
> >> >> > Suggestion 3: Allow DEPTH and LOCAL to be optionally specified
> >> >> > with
> >> >> > the functions,
> >> >> > in the same order as add-hook.
> >> >> >
> >> >> > :hook+ (foo-mode . ((bar 90 t)
> >> >> >                     baz
> >> >> >                     (quux -30)
> >> >> >                     (cor nil t))
> >> >> >
> >> >> > will install 
> >> >> > - bar at depth 90, to be run buffer-locally when foo-mode-hook
> >> >> > runs
> >> >> > - baz without special accommodations, and
> >> >> > - quux at depth -30.
> >> >> > - cor buffer-locally with default depth
> >> >> 
> >> >> I like this, i think i can implement only the "local" part.
> >> >> But of course, only part of :multi.
> >> >> 
> >> >> If i can get rid of `:multi` i can implement this, but it will
> >> >> look
> >> >> somewhat ugly:
> >> >> 
> >> >>   :hook+ (foo-mode . '((bar 90 t)))
> >> >
> >> > So what is the outcome of this discussion?  Are you working on an
> >> > updated patch, or should I install the last one you posted?
> >> 
> >> I believe there was a reasonable doubt whether we need some of the
> >> keywords at all from the initial patch.  So my vote would be to hold
> >> back from that option for now, and figure out what would make sense
> >> to
> >> add to the core.
> >
> > Figure out how?
> >
> > AFAIU, the latest round of comments just brought up an issue with
> > :hook+, and the rest didn't cause any objections?  Why not install
> > them?
> 
> AFAIU, the keywords are considered useless and perhaps unnecessary, and
> actually, they are, most of them can be useless and redundant or
> confusing, but to remember, most of these keywords are ideas and
> concepts that people asked for in use-package and could not be
> implemented due to lack of time or had to be eliminated.
> 
> Based on the comments here and in emacs-devel, the only keyword i think
> should be in core would be :hook+.
> 
> And this is based on a recent comment in use-package bug tracker on github:
> 
> ---
>   I myself have a wrapper around use-package for various reasons and
>   I'll be adding support for this as I don't like having things like:
> 
>     :config
>     ;; TODO: neo/use-package could support dept in :hook
>     (add-hook 'after-init-hook 'neo/desktop-restore 99) ; :hook doesn't support depth
> 
>   but if it were supported by use-package it could benefit more people.
> ---

John, would you please chime in and tel what you think about this?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: johnw <at> gnu.org
Cc: johnw <at> newartisans.com, philipk <at> posteo.net, eg642616 <at> gmail.com,
 shipmints <at> gmail.com, karthikchikmagalur <at> gmail.com, 79106 <at> debbugs.gnu.org
Subject: Re: bug#79106: [PATCH] Add new optional keywords to use-package
Date: Sat, 23 Aug 2025 14:32:42 +0300

Ping!  John, please respond.

> Cc: karthikchikmagalur <at> gmail.com, philipk <at> posteo.net, 79106 <at> debbugs.gnu.org,
>  shipmints <at> gmail.com, johnw <at> newartisans.com
> Date: Thu, 07 Aug 2025 19:19:15 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> > From: "Elijah G." <eg642616 <at> gmail.com>
> > Cc: karthikchikmagalur <at> gmail.com,  79106 <at> debbugs.gnu.org,
> >   shipmints <at> gmail.com,  johnw <at> newartisans.com
> > Date: Thu, 07 Aug 2025 09:44:46 -0600
> > 
> > Eli Zaretskii <eliz <at> gnu.org> writes:
> > 
> > >> From: Philip Kaludercic <philipk <at> posteo.net>
> > >> Cc: Elijah Gabe Pérez <eg642616 <at> gmail.com>,
> > >>   karthikchikmagalur <at> gmail.com,
> > >>   johnw <at> newartisans.com, 79106 <at> debbugs.gnu.org, shipmints <at> gmail.com
> > >> Date: Thu, 07 Aug 2025 14:26:53 +0000
> > >> 
> > >> Eli Zaretskii <eliz <at> gnu.org> writes:
> > >> 
> > >> >> > Suggestion 1: allow many hooks to be specified in a list
> > >> >> >
> > >> >> > :hook+ (foo-mode . (bar baz quux))
> > >> >> >
> > >> >> > adds functions bar, baz and quux to foo-mode-hook.  (To
> > >> >> > disambiguate
> > >> >> > between a list of hook functions and a lambda, you can look at
> > >> >> > the car
> > >> >> > of the list maybe?)
> > >> >> 
> > >> >> It is not possible because (foo-mode . (bar baz quux)) is
> > >> >> expanded as
> > >> >> (foo-mode bar baz quux), and this can be misinterpreted by :hook+
> > >> >> as a
> > >> >> list of hooks.
> > >> >> 
> > >> >> The only workaround i found is making a kind of separator
> > >> >> (:multi),
> > >> >> which tells :hook+ the cdr is a list of functions, not part of a
> > >> >> list of
> > >> >> hooks.
> > >> >> 
> > >> >> I know that :multi can look weird (even i was thinking in rename
> > >> >> it [1]
> > >> >> or use a better separator), but it was the only solution i found
> > >> >> and
> > >> >> worked.
> > >> >> 
> > >> >> > Suggestion 2: allow many hooks to be added to.  (:hook already
> > >> >> > does
> > >> >> > this)
> > >> >> >
> > >> >> > :hook+ ((foo-mode cor-mode) . (bar baz quux))
> > >> >> >
> > >> >> > Adds the three functions to both foo-mode-hook and
> > >> >> > cor-mode-hook.
> > >> >> 
> > >> >> Similar problem as previous.
> > >> >> 
> > >> >> > Suggestion 3: Allow DEPTH and LOCAL to be optionally specified
> > >> >> > with
> > >> >> > the functions,
> > >> >> > in the same order as add-hook.
> > >> >> >
> > >> >> > :hook+ (foo-mode . ((bar 90 t)
> > >> >> >                     baz
> > >> >> >                     (quux -30)
> > >> >> >                     (cor nil t))
> > >> >> >
> > >> >> > will install 
> > >> >> > - bar at depth 90, to be run buffer-locally when foo-mode-hook
> > >> >> > runs
> > >> >> > - baz without special accommodations, and
> > >> >> > - quux at depth -30.
> > >> >> > - cor buffer-locally with default depth
> > >> >> 
> > >> >> I like this, i think i can implement only the "local" part.
> > >> >> But of course, only part of :multi.
> > >> >> 
> > >> >> If i can get rid of `:multi` i can implement this, but it will
> > >> >> look
> > >> >> somewhat ugly:
> > >> >> 
> > >> >>   :hook+ (foo-mode . '((bar 90 t)))
> > >> >
> > >> > So what is the outcome of this discussion?  Are you working on an
> > >> > updated patch, or should I install the last one you posted?
> > >> 
> > >> I believe there was a reasonable doubt whether we need some of the
> > >> keywords at all from the initial patch.  So my vote would be to hold
> > >> back from that option for now, and figure out what would make sense
> > >> to
> > >> add to the core.
> > >
> > > Figure out how?
> > >
> > > AFAIU, the latest round of comments just brought up an issue with
> > > :hook+, and the rest didn't cause any objections?  Why not install
> > > them?
> > 
> > AFAIU, the keywords are considered useless and perhaps unnecessary, and
> > actually, they are, most of them can be useless and redundant or
> > confusing, but to remember, most of these keywords are ideas and
> > concepts that people asked for in use-package and could not be
> > implemented due to lack of time or had to be eliminated.
> > 
> > Based on the comments here and in emacs-devel, the only keyword i think
> > should be in core would be :hook+.
> > 
> > And this is based on a recent comment in use-package bug tracker on github:
> > 
> > ---
> >   I myself have a wrapper around use-package for various reasons and
> >   I'll be adding support for this as I don't like having things like:
> > 
> >     :config
> >     ;; TODO: neo/use-package could support dept in :hook
> >     (add-hook 'after-init-hook 'neo/desktop-restore 99) ; :hook doesn't support depth
> > 
> >   but if it were supported by use-package it could benefit more people.
> > ---
> 
> John, would you please chime in and tel what you think about this?
> 
> 
> 
> 

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

From: John Wiegley <johnw <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: karthikchikmagalur <at> gmail.com, eg642616 <at> gmail.com, 79106 <at> debbugs.gnu.org,
 philipk <at> posteo.net, shipmints <at> gmail.com
Subject: Re: bug#79106: [PATCH] Add new optional keywords to use-package
Date: Sat, 23 Aug 2025 14:53:24 -0700

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

> Ping!  John, please respond.

My apologies, I didn’t see this message asking for my input. Thank you for the
prompt!

>> AFAIU, the keywords are considered useless and perhaps unnecessary, and
>> actually, they are, most of them can be useless and redundant or confusing,
>> but to remember, most of these keywords are ideas and concepts that people
>> asked for in use-package and could not be implemented due to lack of time
>> or had to be eliminated.
>> 
>> Based on the comments here and in emacs-devel, the only keyword i think
>> should be in core would be :hook+.
>> 
>> And this is based on a recent comment in use-package bug tracker on github:
>> 
>> ---
>>   I myself have a wrapper around use-package for various reasons and I'll
>>   be adding support for this as I don't like having things like:
>> 
>>     :config
>>     ;; TODO: neo/use-package could support dept in :hook
>>     (add-hook 'after-init-hook 'neo/desktop-restore 99) ; :hook doesn't support depth
>> 
>>   but if it were supported by use-package it could benefit more people.
>> ---
> 
> John, would you please chime in and tel what you think about this?

Personally, I think that “extra” features shouldn’t be in Core, but rather in
ELPA. What’s in core should either be what is vital, or what is likely to be
used by the majority of users. Many of the keywords in this submission do not
satisfy either criteria.

The desire to specify hook depth is a motivating reason to extend the behavior
of `:hook`. I’m not sure we should add a new keyword, `:hook+`. I think we
should extend the parsing of `:hook` so that the following are supported:

  (SYM)
  (SYM . FUNC)
  (SYMS . FUNC)
  (SYMS FUNC KEYS)

Where KEYS would initially include `:depth N`, and leaves the door open to
further keywords if necessary.

Note that another feature requested in the past is the ability to specify
FUNCS as a list instead of just FUNC, but that would become impossible if we
went with the above scheme. I’m not sure how much I like the MANY<->MANY
possibility of both SYMS and FUNCS anyway.

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

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

From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
To: John Wiegley <johnw <at> gnu.org>
Cc: karthikchikmagalur <at> gmail.com, Eli Zaretskii <eliz <at> gnu.org>,
 79106 <at> debbugs.gnu.org, philipk <at> posteo.net, shipmints <at> gmail.com
Subject: Re: bug#79106: [PATCH] Add new optional keywords to use-package
Date: Thu, 28 Aug 2025 17:08:08 -0600

John Wiegley <johnw <at> gnu.org> writes:

[...]

>> John, would you please chime in and tel what you think about this?
>
> Personally, I think that “extra” features shouldn’t be in Core, but rather in
> ELPA. What’s in core should either be what is vital, or what is likely to be
> used by the majority of users. Many of the keywords in this submission do not
> satisfy either criteria.

I agree.

Then I think it would be better to move use-package-x to ELPA.

> The desire to specify hook depth is a motivating reason to extend the behavior
> of `:hook`. I’m not sure we should add a new keyword, `:hook+`. I think we
> should extend the parsing of `:hook` so that the following are supported:
>
>   (SYM)
>   (SYM . FUNC)
>   (SYMS . FUNC)
>   (SYMS FUNC KEYS)
>
> Where KEYS would initially include `:depth N`, and leaves the door open to
> further keywords if necessary.
>
> Note that another feature requested in the past is the ability to specify
> FUNCS as a list instead of just FUNC, but that would become impossible if we
> went with the above scheme.

I think the FUNCS logic can be only added to plain lists instead
cons-cells.

The cons-cell form seems to be designed only for single functions

   (SYM . FUNC)
   (SYMS . FUNC)

On the other hand, with a list this could be easily implemented:

   (SYM FUNCS)
   (SYMS FUNCS)

I honestly don't think I have the time (and energy) to add these
features to :hook (the changes may be buggy).

At the moment I think that having them in my package is a better way to
avoid breaking use-package.

> I’m not sure how much I like the MANY<->MANY possibility of both SYMS and FUNCS anyway.

Honestly, the FUNCS feature may not be necessary.

There have been other alternatives, such as using a function or a lambda
to group the functions:

  :preface (defun my/functions () (f1) (f2) (f3))
  :hook (my-hook . my/functions)

However, in my personal opinion, this is not usually convenient because
if someone wants to remove one of the functions from that hook, they
would have to remove the defun or lambda which includes the others
functions.

-- 
- E.G via Gnus and Org.

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

From: Philip Kaludercic <philipk <at> posteo.net>
To: Elijah Gabe Pérez <eg642616 <at> gmail.com>
Cc: karthikchikmagalur <at> gmail.com, Eli Zaretskii <eliz <at> gnu.org>,
 John Wiegley <johnw <at> gnu.org>, 79106 <at> debbugs.gnu.org, shipmints <at> gmail.com
Subject: Re: bug#79106: [PATCH] Add new optional keywords to use-package
Date: Tue, 02 Sep 2025 14:26:57 +0000

Elijah Gabe Pérez <eg642616 <at> gmail.com> writes:

> John Wiegley <johnw <at> gnu.org> writes:
>
> [...]
>
>>> John, would you please chime in and tel what you think about this?
>>
>> Personally, I think that “extra” features shouldn’t be in Core, but rather in
>> ELPA. What’s in core should either be what is vital, or what is likely to be
>> used by the majority of users. Many of the keywords in this submission do not
>> satisfy either criteria.
>
> I agree.
>
> Then I think it would be better to move use-package-x to ELPA.

Right, this was the initial judgement as well, but Eli recommended
adding the new functionality to the core.  To be clear, this is my
preference as well, but I don't want to override Eli's wishes, so I'd
like to ask Eli: Do you still maintain that we should add (whatever
subseteq of features we decide on) to the core, or is it OK to add them
as a package to ELPA?

[...]

-- 
Philip Kaludercic

Previous Next

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