Feature request: use-package integration

[jwiegley]

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.

[abo-abo]

use-package-keywords

I'll look into this when I get some time.

[To1ne]

I've thinking about this for some time too. I'll report back when I've figured (something) out.

[To1ne]

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.

[jwiegley]

You'll have to dig deeper, to find something within each Hydra list that lets you know what the nesting means.

[To1ne]

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]

@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.

[To1ne]

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!

[To1ne]

I've been working on this at https://gitlab.com/to1ne/use-package-hydra.

It can use some more improvements. But the basics work.

[duzaichuan]

@To1ne The package works very nicely to me. Thanks!

Have you considered to merge it into hydra?

Best

[To1ne]

@duzaichuan I didn't. I asked @jwiegley to add it to use-package, but he wasn't interested in maintaining it: jwiegley/use-package#628

I'm not sure if @abo-abo is interested. I think they wanted it to be more featured than it is right now.

[abo-abo]

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 ...)

[aspiers]

As this now exists as an extension, and there is consensus that it should remain that way, presumably this issue can be closed?

[CastixGitHub]

this feature request is also satisfied by another package: major-mode-hydra