I vaguely recall that the sole thick client of the Hover JSON output is one of the Vims. (The feature was added in the CL attached to #33352. Paging @myitcv for awareness.)

Paging @myitcv for awareness.

Thanks, @adonovan - we're actually using what I believe the gopls default is in this space, "FullDocumentation":

https://github.com/govim/govim/blob/6280deb8b406332ed0c9f0eea59671d954b815ab/cmd/govim/gopls_client.go#L159

[govim is] actually using what I believe the gopls default is in this space, "FullDocumentation":

Great, let's remove kind=structured then.

Change https://go.dev/cl/635226 mentions this issue: gopls/internal/settings: drop experimental hoverKind=Structured

FWIW, vim-go was using Structured.

@bhcleek very sorry about the breakage :(.

This was, I think, perhaps the first time we've just removed a setting without a probationary release where it is a warning. We really thought the only user was govim -- I'm afraid the similar naming of the clients may have been part of the confusion. Lesson (re)learned.

What can we do to help? We can revert the deprecation temporarily, though that might be messy (I'll try). If instead you can fix forward, that may be cleanest.

Going forward If you need structured information from hover, we can can add a custom command. As described in the release notes, it was a mistake to shoehorn a JSON API into hover.

I can probably refactor vim-go to get what I need, but I won't be able to get to it immediately.

IIRC, I'd relied on Structured, because FullDocumentation was missing some things vim-go needed and the structure of the documentation result when FullDocumentation was used did not come with guarantees; parsing free form text is tricky, especially if the server doesn't guarantee its form across versions.

Reopening and moving to the v0.19.0 milestone, since this deletion is being reverted.

@findleyr

Would it be possible to change the plaintext hover content to use two newlines between the identifier and the beginning of its documentation?

I'm also wondering what determines where single newlines are placed within the actual documentation after the identifier.

edit: strike wondering after checking actual godoc source for fmt.Println and realizing I'd assumed something based on how the pkg.go.dev renders it.

@findleyr nevermind, I think I've found a way forward.

@findleyr I got most of what I needed done, but there's one aspect of the structured content that I've been unable to find a good answer for. The structured output includes linkPath and linkAnchor fields. Vim-go uses those fields to construct documentation links, notably for opening a browser.

Interestingly, the markdown format provides the links I'd need with FullDocumentation, but I can't mix plaintext and markdown, because the format has to be chosen in the initialize method, and markdown is otherwise not well suited for vim-go's needs.

I was hoping that textdocument/documentLink would provide a useful alternative, but it seems to only provide links for the imports.

Do you have any suggestions?

Would it suffice to include the links in plaintext mode, in the footer? That seems reasonable.

For users that don't want links, we could we could extend the "linksInHover" setting to plaintext:
https://github.com/golang/tools/blob/master/gopls/doc/settings.md#linksinhover-enum

I don't think we should use documentLink for this.

Yes, I think that could work for vim-go's purposes as long as:

1. only the link for the documentation being provided is provided
2. there is some guarantee about where in the plaintext the link will be found (e.g. last line?)