feat: new command to goto hover (like goto definition)

[nik-rev]

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 #12206
Closes #8134
Closes #9455

[Axlefublr]

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

[nik-rev]

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

[Axlefublr]

fair enough. let's get this merged first
good luck!

[TornaxO7]

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

[Axlefublr]

@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

[nik-rev]

I just fixed it with merge conflicts since #10122 added support for hover with multiple language servers.

This is how it looks like with multiple language servers:

[cotneit]

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

@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 :)

That is definitely better!

feels more natural, especially since it is very similar to other commands like "goto reference", but its "goto hover"

[rockboynton]

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

[Axlefublr]

more convenient formatting

[nik-rev]

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

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

[jerabaul29]

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-o to open the content of the popup in a new buffer
• ctrl-h to open the content of the popup in a new (horizontal) split
• ctrl-v to 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 #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)

[babucarr32]

I can't wait to have this merged.

[nik-rev]

Closing! Reason: State of my Helix PRs

[jerabaul29]

I love this PR, unfortunately I am not competent enough in rust and I will probably not have time to become so. Anybody willing to pick this up and / or just open a copy of this PR so that it gets "re-opened" and kept in the "book-keeping of PRs"?

[Axlefublr]

yes! I'm in the middle of picking this up. just wasn't ready yet to proclaim it; but I was able to make it work.

some more cleanup to do and I'll publish it; I'll link to it here so that people subscribed to this pr will know about it

[Axlefublr]

I might take on some other unmaintained prs under my wing now that I'm more helix codebase capable. Wanna carry the torch of the sunshine nik brought to the helix community; such a legend!

People reading this, feel free to ping me under particularly useful / significant but unmaintained prs. I might go "omg yeah I want that actually!" and take it on perhaps. The author needs to be very obviously away, though; I don't wanna just be stealing work.

[Axlefublr]

I took on maintaining this pr in #15187