Package: emacs;
Reported by: Elijah Gabe Pérez <eg642616 <at> gmail.com>
Date: Sun, 27 Jul 2025 20:20:01 UTC
Severity: normal
Tags: patch
View this message in rfc822 format
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: 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
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.