helix
helix copied to clipboard
feat: new command to goto hover (like goto definition)
So, you can use Space + k to hover documentation which opens a popup.
However, sometimes it's really useful to be able to search inside this popup. Or go into it, move around, copy some text, etc. Some hover-docs can be quite long.
This PR adds a new command called goto_hover, which dumps the "documentation on hover" into a new scratch buffer (replacing the current buffer, similar to goto_definition), where you can use your usual Helix motions. this is how it looks like (after I created a new split):
I bound goto_hover to Space + K, whereas hover was Space + k.
Closes https://github.com/helix-editor/helix/issues/12206 Closes https://github.com/helix-editor/helix/discussions/8134 Closes https://github.com/helix-editor/helix/discussions/9455
trying this feature out in my fork and loving it!
except, I'd rather it be a horizontal split. I could also see an argument for ::Replace, too
is it too unreasonable to ask for this to be configurable via a settable option?
I don't think helix decides on a split type anywhere else; maybe having a global "split-direction" option that other things may potentially use in the future is a good idea
trying this feature out in my fork and loving it!
except, I'd rather it be a horizontal split. I could also see an argument for
::Replace, too is it too unreasonable to ask for this to be configurable via a settable option? I don't think helix decides on a split type anywhere else; maybe having a global "split-direction" option that other things may potentially use in the future is a good idea
Adding configuration for this small thing is easily going to be rejected by the maintainers. Other adjustments would also be increasing complexity and could delay this PR from being merged
fair enough. let's get this merged first
good luck!
trying this feature out in my fork and loving it!
except, I'd rather it be a horizontal split. I could also see an argument for
::Replace, too is it too unreasonable to ask for this to be configurable via a settable option? I don't think helix decides on a split type anywhere else; maybe having a global "split-direction" option that other things may potentially use in the future is a good idea
What you can also do, at least, if you are working with one pane, is transposing your layout with <C-w><C-t>.
@TornaxO7 yep thank you! I am aware
for now I changed it to horizontal in source in my fork; it's just a defaults preference
I just fixed it with merge conflicts since https://github.com/helix-editor/helix/pull/10122 added support for hover with multiple language servers.
This is how it looks like with multiple language servers:
@nik-rev What do you think about making this work in-place instead of opening a new split? Similar to goto_definition when it has to jump to a different file. This way if user has a preference between in-place/vsplit/hsplit they can just do a custom keybind:
[keys.normal.g]
H = ["vsplit", "goto_definition"]
Inspired by https://matklad.github.io/2024/10/08/two-tips.html, immediately thought of this PR while reading it :)
@nik-rev What do you think about making this work in-place instead of opening a new split? Similar to
goto_definitionwhen it has to jump to a different file. This way if user has a preference between in-place/vsplit/hsplit they can just do a custom keybind:[keys.normal.g] H = ["vsplit", "goto_definition"]Inspired by https://matklad.github.io/2024/10/08/two-tips.html, immediately thought of this PR while reading it :)
That is definitely better!
feels more natural, especially since it is very similar to other commands like "goto reference", but its "goto hover"
This feature seems cool! When is this more useful than simply gd which is where the docs come from and has the docs right there? At least for rust code
more convenient formatting
This feature seems cool! When is this more useful than simply
gdwhich is where the docs come from and has the docs right there? At least for rust code
Not all languages have the docs right there. Rust is pretty special in that regard
And in Rust this is also useful, e.g. copy the inferred type of a local variable
This would be quite useful, thanks for the PR! :)
A bit of brainstorming - hope this is not out of place, if it is, apologies.
I wonder if this could be made even more general though - this is a specific case of wanting to jump to the text viewed from the popup when the popup is just a peak into a given location of source code, but what if the popup does not correspond to a source text (guess this can happen with some LSPs if for example interacting with a binary and not source code, or some other kind of documentation / other popup that is not just obtained from reading a given file?), and / or if a similar use case happens in other contexts where a popup shows up?
So I wonder if it could be useful to make this even more general by making a few additions to the popup functionalities. I.e. for now, when a popup shows up, we can just navigate it with ctrl-u/d as visible in the doc at https://docs.helix-editor.com/master/keymap.html#popup .
What about adding, when a popup is opened:
ctrl-oto open the content of the popup in a new bufferctrl-hto open the content of the popup in a new (horizontal) splitctrl-vto open the content of the popup in a new (vertical) split.
From there, the popup content just becomes usual text, and we have all the tools of usual helix available.
I had started playing a tiny bit with these ideas in https://github.com/helix-editor/helix/pull/9311 . But i) I am a rust n00b, ii) I am a helix user but not well known with the codebase, iii) I have not had the time to follow up. But still wonder if a functionality along these lines could be good.
A few questions to solve would be:
- if / how to name the new split / buffer
- what language to define the new split / buffer as (it will be markdown for a lot of doc, but maybe language for other completions)
I can't wait to have this merged.