Feature Request: Enhanced Type Navigation in ui.documentation.hoverKind

[tfspire]

Is your feature request related to a problem? Please describe.
I'm currently limited by the lack of a navigation feature within ui.documentation.hoverKind when inspecting Go types in VSCode. It can be frustrating to identify and understand sub-types, embedded types, and related structures directly within the hover documentation. This restriction slows down development by requiring separate steps to look up definitions for each individual type, instead of having them navigable in one place.

Describe the solution you'd like
I would like to see an additional option in ui.documentation.hoverKind that enables interactive type navigation. This feature would allow users to click on types within the hover documentation to expand definitions and explore any sub-types, embedded structures, or other related types directly within the hover window. This functionality would streamline code comprehension and reduce the need to navigate away from the current hover documentation.

Describe alternatives you've considered
I've considered using the "Go to Definition" feature or manually searching for type definitions when needing to dive deeper into sub-types. However, these alternatives require navigating away from the hover view, which interrupts the workflow. A more interactive hover experience would provide a smoother and faster exploration of complex types.

Additional context
An interactive type navigation within the hover documentation would be especially useful when working with complex structs, interfaces, or nested types in Go, making it easier for developers to grasp code structures without additional lookup steps.

[h9jiang]

Hi tfspire, thanks for raising this,

Just to better understand your intention here, I create the screenshot below. Please let me know if this is what you want or not. (This is not the current behavior of vscode-go, this is just a screenshot to describe the feature you want)

When hovering over the type ImportSepc, the hover panel shows the type information including field, type and comments.
And if you move the cursor to type CommentGroup, another panel get created and show the information for this sub type including field, type and comments.

If my interpretation is not accurate, please correct me. If there is something that is already implemented (most likely provided by other IDE e.g. vim, goland or language server, e.g. TS, C++...), please share any available screenshots so we can better understand your intention.

To share more details, the current capabilities provided by vscode-go and gopls is limited to available functionality provided by LSP. The LSP defines the protocol that gopls and vscode-go communicate with each other and it is the vscode who is actually doing the rendering of the frontend. There is very limited control we have over this protocol.

One example would be, in order to render the hover over content for a given type, we need to know which file you are looking at, which line of code your cursor is hovering and which column. This is defined by LSP. I do not know whether LSP provide this feature where it shares the file path, line number or column number when the cursor is inside of an hover over panel (not in source code file).

Another feature we provided is browse documentation for current Go package, you can find the feature doc. This will open a browser so you can look at the struct definitions and function definitions. Maybe it can be helpful to navigate through complicated code base.

[tfspire]

Hi h9jiang,

Thanks for the response!

I really like how GoLand handles this feature—clickable types directly in the hover window. For example, in the image, all the elements highlighted in pink are clickable:

When you click one (for example msg), it expands within the same hover window to display that type:

For example, clicking on string would bring up its documentation in the same window:

Here’s a comparison when hovering over variables: this is what VSCode currently shows:

And this is what GoLand displays:

[h9jiang]

Hi tfspire, I had some discussion with @hyangah here are some summaries

Personally speaking I like the idea where the language server can provide more information to the client so you can jump to different location inside of the hover over panel.

Today, when you are hovering over some code snippet, gopls send back a response following the LSP. Examples like below.

[Trace - 4:29:42 PM] Received response 'textDocument/hover - (2085)' in 2ms.
Result: {
    "contents": {
        "kind": "markdown",
        "value": "```go\ntype Foo struct {\n\tA string\n\tB string\n}\n```\n\n---\n\n```go\nfunc (*Foo) Method(ctx context.Context, _ string, _ string, _ error) (out string, out1 string, out2 string, e error)\n```\n\n---\n\n[`one.Foo` on pkg.go.dev](https://pkg.go.dev/golang.org/x/tools/txtar/one#Foo)"
    },
    "range": {
        "start": {
            "line": 55,
            "character": 35
        },
        "end": {
            "line": 55,
            "character": 38
        }
    }
}

And it will be rendered like

The returned result from gopls is a markup content and it have two kind plaintext or markdown. Gopls returns the struct definition in markdown three backticks(as you can see from the example above).

The problem here is, in markdown code snippet, we can not insert any link. If we choose to return markdown not covered by the three backticks (not inside of code snippet), then we loose the syntax highlighting.

Why GoLand does support this and we can not support this?

Based on my knowledge, GoLand is close source and they do not fully following LSP. So they could have more flexibility to render things in the way they preferred.

Right now, vscode-go and gopls communicate with each other mostly through LSP. The limitation of LSP applies to us.

However, I heard some other programming language is exploring other implementation where the client and the server can talk to each other through LSP but not the pre-defined protocol. (Image you have a general protocol and a hover protocol, the hover protocol is limited but the general protocol is widely extensive, obviously, the cost of using general protocol is, the client will have to implement more logic like panel rendering ....)

The go team are exploring this route and learning from other languages. But I don't know when will be able to design a general uses protocol and when will we be able to use the new protocol to implement this feature.