goto_hover action

[Axlefublr]

This is the reawakening of #12208 by @nik-rev.

I'd love to just cherry pick nik's commits, but because he was using a merge focused workflow, extracting his changes is a bit of a massive pain.

So I collected his code as best as I could, and made him the author of the commit. Because I needed to collect things around, I add myself as a co-author.

Commits that go after are my changes specifically. I'm the only author in those.

---

New goto_hover action, that opens hover in a new scratch buffer, for you to view.

I excluded adding bindings for the new goto_hover command like the initial pr I think does, because it makes this pr a harder sell to merge, for little benefit.

[jerabaul29]

This is a super useful PR - thank you so much for picking it up! :)

[jerabaul29]

A note (that I had written in the original PR, but I guess it is fine to duplicate here? :) ): could this be made in such a way that this can be opened in a new buffer, either "after" the current buffer in the list of tabs, but also as a vertical or horizontal new split? Often I find that I would like to keep seeing my code on the left, just use the right half of my screen to see the doc in a copy pastable / helix navigable (buffer) split :) .

[Axlefublr]

A new buffer is always opened as the absolute last one — it's an internal thingy that would likely be complicated to change. And of course out of scope of the pr.

But I assume you're asking for it for the purposes of gp — being able to go back to the buffer you opened the hover from, easily. You can achieve a similar niceness if you just close the buffer (with :buffer-close for example). You will be automatically jumped to the most recent other place where you have been in, which is the buffer that you opened goto_hover from.
Also, switching away from the hover buffer in most ways, will automatically close it, kind of like empty scratch buffers act.
Wondering if it's a side effect of my own fork at play here, but I think not?

As for splits, this is the nice thing about this pr's design (not my idea though!) — you can create the split first, and then open goto_hover from there. :vsplit or :hsplit, then goto_hover. And boom, you got your thingie in a split as you want.
If you use splits (I don't), you probably already have hotkeys to make closing the split nicer, so that shouldn't be a workflow issue either.

[iniw]

could this be made in such a way that this can be opened in a new buffer

For reference, here's a keymap that achieves that:

[keys.normal.g]
h = "goto_hover"
C-h = ["vsplit", "jump_view_up", "goto_hover"]

I use this extensively for "open-in-split" versions of the existing goto_* commands:

[keys.normal.g]
C-S-d = ["vsplit", "jump_view_up", "goto_declaration"]
C-d = ["vsplit", "jump_view_up", "goto_definition"]
C-i = ["vsplit", "jump_view_up", "goto_implementation"]
C-y = ["vsplit", "jump_view_up", "goto_type_definition"]

[jerabaul29]

As a note: this should take over #9311 , I will close this old ugly draft of mine. Not sure if some of the comments from @the-mikedavis there should be considered here :) .

[jerabaul29]

I dont know if this is appropriate to ask, if not apologies, but @the-mikedavis @archseer do you think there is a possibility this could be part of the next release and / or put on the roadmap if not? This makes it so much easier to read documentation effectively, copy paste examples from it, etc.

[Axlefublr]

Unfortunately I imagine the plugin system makes this being in core undesirable to the maintainers. I would love to be wrong though.

[jerabaul29]

I would think / hope this could be seen as something for the core, rather than deferred to a plugin? What do you think @the-mikedavis ? I would love to have this kind of core user experience that does not require too much extra code core to be built in, rather than starting to need to enter "plugin hell" for these functionalities if possible :) .