8000 Feature request: share heads among different hydras · Issue #57 · abo-abo/hydra · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Feature request: share heads among different hydras #57

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
zhaojiangbin opened this issue Feb 26, 2015 · 3 comments
Closed

Feature request: share heads among different hydras #57

zhaojiangbin opened this issue Feb 26, 2015 · 3 comments

Comments

@zhaojiangbin
Copy link

I have different hydras using exactly same subset of heads. For example, for moving the point, both the vi-style navigation hydra and the rectangle operation hydra define h i j k heads to call same commands, respectively. Would it be possible to share these heads between the hydras?

An option is to define the common heads in a hydra and call it in bodies of vi-navigation and rect-ops. But that would require an extra pair of keys to enter and exit the sub-hydra.

I am thinking something like:

;; It could be implemented as a different function/macro if that would make more sense.
(defhydra common-heads ()
  ""
  ("h" backward-char)
  ...
  ("k" previous-line))

(defhydra vi-navigation ()
  ""
  (hydra-import common-heads :hint t) ;; shown in hint
  ("a" beginning-of-line)
  ;; other heads
  ...)

(defhydra rect-operations ()
  ""
  (hydra-import common-heads :hint nil) ;; hidden
  ;; other heads
  ...)

The function/macro hydra-import (I am making up the name here) would somehow make the heads h j k l available directly in the calling hydras. The property :hint tells whether these heads should show up in the calling hydras. Having the :exit and :foreign-keys properties would be useful, too.

I have to admit that this is only a nice-to-have minor feature. It might not even get much use. I am just tossing some ideas.

@abo-abo
Copy link
Owner
abo-abo commented Feb 26, 2015

It's a good idea, but it might be too soon to do it. Myself, I have around 10 hydras total, with
little repetition. And once something gets re-used, a need for introspection arises: common-hydras
will need a variable, a docstring and location info, and metadata. All of this it doesn't have since
it's just a macro expansion.

This might get implemented in the future, but not very soon.

@zhaojiangbin
Copy link
Author

Awesome. Thanks.

@occisn
Copy link
6618
occisn commented Mar 15, 2021

@zhaojiangbin , a work-around could be to use a macro which would create specific hydras on top of a common basis.

(defmacro create-hydra-on-top-of-common-hydra (hydra-name description-string &rest keybindings)
  "Creates hydra on top of common hydra"
  `(defhydra ,hydra-name (:exit t :hint nil)
     ,(concat description-string "
Common:
-------
_h_: backward char
")
     ,@keybindings
     ("h" #'backward-char)))

(create-hydra-on-top-of-common-hydra vi-navigation-hydra
				     "
^Vi navigation:
^--------------
_a_: beginning of line
"
				     ("a" #'beginning-of-line)
				     )

(global-set-key (kbd "C-c i") #'vi-navigation-hydra/body)

Stroking C-c i then leads to:
image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants
0