On Wed, Jul 30, 2025 at 3:03 AM Karthik Chikmagalur <
karthikchikmagalur@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