-
Notifications
You must be signed in to change notification settings - Fork 17.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
x/tools/gopls: render package documentation when hovering over imported package name identifiers #71248
Comments
I might be able to help out on this too Here's the Godoc github. I figure their logic is in here somewhere. Maybe we could use that |
@GSmithApps There's already logic in gopls for rendering package documentation. If you set |
Hey @firelizzard18 thanks so much for looking at this! Yeah I'm having luck when I hover over the import statement, but not when I hover over the variable name that it imports to. In your example, it would be if you hover over And that includes if I add that note you posted to both my project and user-level settings.json |
Yeah, that matches what I saw. While I'm confident that implementing your feature would involve tweaking the Hover function, it's not clear to me what the code path is for hovering on a package identifier (e.g. testeval) vs a package import, which is why I said I'm not certain what needs to change. |
This is quite old logic, and it looks like https://go.dev/cl/230417 just added special handling for import specs. The case of a PkgName object in the code falls back to default behavior for object references. We could certainly do this, if people would find it helpful. I will move this to the gopls issue tracker as a feature request. |
@findleyr Are you thinking to use the same verbosity level for the import hover and the package identifier hover? If that's the case it seems like it wouldn't be too hard for an external contributor to implement. |
@firelizzard18 yes, I should have been clearer: I think it would be reasonable to serve the same hover content for the package name in a qualified identifier as we do for an import spec. If anything, the lack of consistency is surprising. Given a bit of historical digging, I don't think this was intentional. |
Yeah same here — I also was surprised and couldn’t determine if I had misconfigured something. I can take a stab at implementing it, but someone else would probably be much faster. I see firelizzard's link and can poke around in here, but if anyone has a recommendation on where to start, I’m all ears. Thanks again @firelizzard18 and @findleyr ! |
@GSmithApps It will probably be fastest for you to implement it. I'm interested myself but I have multiple in-progress CLs and I don't plan on opening any more until those are merged, which may take some time. Personally I'd start with using tests and the debugger to step through the code to understand how it flows and how it might be changed.
|
Oh wow MVP status @firelizzard18 thank you so much! I went ahead and forked the repo (here) and added your test and added you two as contributors in case you get some inspiration. Thanks again -- hopefully we/I can get this up and running! |
Okay I think we've found the first point at which the existing test (for hovering over the import statement) and the second test (to test the identifier) differ. It's in hover.go. The left side of the image is the old test, and it gets caught in this if statement, but the new test doesn't get caught in there. This is because this if statement is for imports. So I think what we need to do is figure out where in the remainder of that function we want it to hit for the identifier test 👍 |
You'll probably need to refactor if _, ok := obj.(*types.PkgName); ok {
rng, hoverRes, err := hoverPackageIdent(ctx, snapshot, pkg, pgf, ident)
if err != nil {
return protocol.Range{}, nil, err
}
if hoverRange == nil {
hoverRange = &rng
}
return *hoverRange, hoverRes, nil // (hoverRes may be nil)
} I pretty much just copied that from the hoverImport case so you may have to change it. |
golang/go#71248 (comment) I basically just copy-pasted and didn't think much. I'm hoping to take a closer look tomorrow or something
Okay awesome -- thank so much again @firelizzard18 ! I went ahead and copy-pasted in what you suggested and did a little bit of tweaking, but it's not quite there yet. I think I/we'll have to look at it again one more time tomorrow or something (Here's the repo) again and some screenshots |
@GSmithApps please send me the CL when it is ready for review, thanks! |
Hey @findleyr here's the pull request and CL Ethan's test is passing (screenshot below), and the implementation is pretty close to what he suggested |
Is your feature request related to a problem? Please describe.
Package-level description isn't rendering
Describe the solution you'd like
I'd like the package-level description to render when hovering over an imported package, as shown in the screenshots below. ChatGPT suggests that if a package is spread across multiple files, Go uses first (alphabetically) nonempty comment, but I'm not totally sure. I don't know if VSCode is just getting confused.
Describe alternatives you've considered
One option is to ignore it. Another is to use GoLand. Another is to just always have the docs up
Additional context
GoLand
I know the docs are there. They're in doc.go, and they're rendering in Godoc, and they're showing in GoLand
https://pkg.go.dev/go.temporal.io/sdk@v1.31.0/workflow#Go
VSCode
The text was updated successfully, but these errors were encountered: