hydra
hydra copied to clipboard
Feature request: use-package integration
It would be neat if hydra
provided a :hydra
keyword to use-package
(by extending use-package-keywords
), that would gensym the hydra name and allow the bindings to be declared as part of the use-package declaration, with autoloads generated for all the referenced function names as they are now for :bind
. Example:
(use-package yasnippet
:load-path "site-lisp/yasnippet"
:after hydra
:demand t
:diminish yas-minor-mode
:commands (yas-expand yas-minor-mode)
:functions (yas--guess-snippet-directories yas--table-name)
:defines (yas--guessed-modes)
:mode ("/\\.emacs\\.d/snippets/" . snippet-mode)
:hydra ((:color blue :hint nil)
"
^YASnippets^
--------------------------------------------
Modes: Load/Visit: Actions:
_g_lobal _d_irectory _i_nsert
_m_inor _f_ile _t_ryout
_e_xtra _l_ist _n_ew
_a_ll
"
("d" yas-load-directory)
("e" yas-activate-extra-mode)
("i" yas-insert-snippet)
("f" yas-visit-snippet-file :color blue)
("n" yas-new-snippet)
("t" yas-tryout-snippet)
("l" yas-describe-tables)
("g" yas/global-mode)
("m" yas/minor-mode)
("a" yas-reload-all)))
As a bonus, also accepting ("d" . yas-load-directory)
would make it appear more consistent with :bind
.
use-package-keywords
I'll look into this when I get some time.
I've thinking about this for some time too. I'll report back when I've figured (something) out.
I was working on this and I struggling with unnamed hydras.
@abo-abo Does it make sense to make the name
parameter provided to defhydra
optional (like in @jwiegley's example) and generate one from the name provided to use-package
?
@jwiegley If so, how do you suggest to make use-package-normalize/:hydra
distinguish the difference between a single hydra or a list of hydras? Because the docstring is optional too and both body
and heads
are lists.
You'll have to dig deeper, to find something within each Hydra list that lets you know what the nesting means.
OK master, I will follow this journal to the spiritual realms to fulfill the ancient prophecy.
(sorry, without context that sentence sounds like you're some kind of Jedi master)
@abo-abo Does it make sense to make the name parameter provided to defhydra optional (like in @jwiegley's example)
It's possible, with a major rewrite, to use no names at all, just unnamed lambdas. But I don't think it's the way to go, it would limit the transparency of what defhydra
does, make debugging harder.
@jwiegley, I don't see from your example where the new hydra will be bound. With no bindings, and no names, there's no way to call the generated commands. I think it's better to have names anyway. First reason, is that you can examine them with M-x. Here, I got completion for all heads in hydra-zoom
with M-x:
5 candidates:
hydra-zoom/text-scale-increase
hydra-zoom/body
hydra-zoom/lambda-r
hydra-zoom/lambda-0-and-exit
hydra-zoom/text-scale-decrease
Since I use counsel-M-x
, I also see the bindings of the entry points into this hydra during completion.
A second reason is that hydras can have dynamic properties settable by hydra-set-property
.
;; turn the hint off
(hydra-set-property 'hydra-zoom :verbosity 0)
;; use the default echo area for the hint
(hydra-set-property 'hydra-zoom :verbosity 1)
;; use the lv echo are for the hint
(hydra-set-property 'hydra-zoom :verbosity 2)
Third reason, there's a way for a new hydra to inherit the heads of an existing one via the :inherit
keyword. I don't use it myself, maybe it's useful for others.
I modified your example to this:
(progn
(defhydra hydra-yas (:color blue :hint nil)
"
^YASnippets^
--------------------------------------------
Modes: Load/Visit: Actions:
_g_lobal _d_irectory _i_nsert
_m_inor _f_ile _t_ryout
_e_xtra _l_ist _n_ew
_a_ll
"
("d" yas-load-directory)
("e" yas-activate-extra-mode)
("i" yas-insert-snippet)
("f" yas-visit-snippet-file :color blue)
("n" yas-new-snippet)
("t" yas-tryout-snippet)
("l" yas-describe-tables)
("g" yas/global-mode)
("m" yas/minor-mode)
("a" yas-reload-all))
hydra-yas/keymap)
The return result is a keymap, which could be readily used by use-package
. You could have a nice macro that generates the above code for you, to remove the repetitiveness between hydra-yas
and hydra-yas/keymap
.
It's possible, with a major rewrite, to use no names at all, just unnamed lambdas. But I don't think it's the way to go, it would limit the transparency of what defhydra does, make debugging harder.
I think the idea was to generate the hydra name from the package name. The example in the issue description would for example generate hydra-package-yasnippet/body
. But this wouldn't work well if there are multiple hydras specified for one package.
I agree with keeping it simple and require a hydra name, at least for the first iteration, we always can add unnamed hydras later.
Thanks for your input!
I've been working on this at https://gitlab.com/to1ne/use-package-hydra.
It can use some more improvements. But the basics work.
@To1ne The package works very nicely to me. Thanks!
Have you considered to merge it into hydra?
Best
@duzaichuan I didn't. I asked @jwiegley
to add it to use-package, but he wasn't interested in maintaining it: https://github.com/jwiegley/use-package/pull/628
I'm not sure if @abo-abo is interested. I think they wanted it to be more featured than it is right now.
I agree with @jwiegley. You should publish it as a separate package on MELPA. I think the users wouldn't mind to do this:
(use-package use-package-hydra :ensure t)
(use-package yasnippet :hydra ...)
As this now exists as an extension, and there is consensus that it should remain that way, presumably this issue can be closed?
this feature request is also satisfied by another package: major-mode-hydra