You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First of all, thank you for this fantastic package.
As you know, when you call an hydra, its own window is called by the function lv-window (Assuming that the variable hydra-hint-display-type is set to lv, and leaving aside other options). This function splits the frame root window of the selected window below, and displays the hydra in this newly created window :
(split-window
(frame-root-window) -1'below)
Which forces the user to have a very large hydra window at the bottom, even when one of its "halves" are free.
It would be nice to have the hydra window below the window it was called from, and not the frame root window, thus leaving the space below other windows free.
Doing so merely requires to change the snippet above to the following:
(split-window
(selected-window) -1'below)
Now, I am aware that the former behaviour was probably explicitly chosen, and for very good reasons :
With the changes I put, there is funny behaviour when windows are already stacked on top of another. If you call an hydra from one of them that is not the bottommost, the hydra window "eats" at the one below it. Leaving the hydra does not revert this. (FYI, not specific to hydra, transient has the same problem)
Because the hydra window is put below the calling window, and its modeline format is reduced to nil, there is no substantial separation between the text of the hydra and the text of the buffer in the window below. (This can be somewhat alleviated by setting up a separator with (setq lv-use-separator t), like I did on the image, but it is still insufficient)
Whereas it is perfectly understandable to have the former behaviour as a default, it would be nice to have the option to have the latter, like transient and magit-pop-buffer have.
If you're fine with the presence of this option, I could work on a PR right away. Just adding the option and leaving the funny behaviours as is would be almost as trivial as the snippet change I made. It would also be below the 15 lines mark.
However, getting rid of these two quirks would take me more time, and I would probably need to fill the form you mentioned in PR #136. Tell me what you prefer, and I'll set myself to it.
Thanks in advance for your time !
The text was updated successfully, but these errors were encountered:
If you're fine with the presence of this option, I could work on a PR right away. Just adding the option and leaving the funny behaviours as is would be almost as trivial as the snippet change I made. It would also be below the 15 lines mark.
First of all, thank you for this fantastic package.
As you know, when you call an hydra, its own window is called by the function
lv-window
(Assuming that the variablehydra-hint-display-type
is set tolv
, and leaving aside other options). This function splits the frame root window of the selected window below, and displays the hydra in this newly created window :Which forces the user to have a very large hydra window at the bottom, even when one of its "halves" are free.
It would be nice to have the hydra window below the window it was called from, and not the frame root window, thus leaving the space below other windows free.
Doing so merely requires to change the snippet above to the following:
Now, I am aware that the former behaviour was probably explicitly chosen, and for very good reasons :
(setq lv-use-separator t)
, like I did on the image, but it is still insufficient)Whereas it is perfectly understandable to have the former behaviour as a default, it would be nice to have the option to have the latter, like transient and magit-pop-buffer have.
If you're fine with the presence of this option, I could work on a PR right away. Just adding the option and leaving the funny behaviours as is would be almost as trivial as the snippet change I made. It would also be below the 15 lines mark.
However, getting rid of these two quirks would take me more time, and I would probably need to fill the form you mentioned in PR #136. Tell me what you prefer, and I'll set myself to it.
Thanks in advance for your time !
The text was updated successfully, but these errors were encountered: