GNU bug report logs -
#79106
[PATCH] Add new optional keywords to use-package
Previous Next
Full log
Message #14 received at 79106 <at> debbugs.gnu.org (full text, mbox):
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
This bug report was last modified 17 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.