Skip to content
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

Jump to bottom

x/tools/internal/lsp: consider rethinking the details field of completion candidates #31945

Closed
bhcleek opened this issue May 9, 2019 · 4 comments
Closed

x/tools/internal/lsp: consider rethinking the details field of completion candidates #31945

bhcleek opened this issue May 9, 2019 · 4 comments
Labels
FrozenDueToAge gopls Issues related to the Go language server, gopls.
Milestone
Unreleased

Comments

@bhcleek
Copy link
Contributor

bhcleek commented May 9, 2019

Currently, the details field of completion candidates is of limited value in editors (e.g the preview window in Vim -- not the candidates list).

I'd like to propose that the details field should contain as much information as the label field of completion candidates plus more. Probably, it should be the full type definition for types and the declaration for variables and constants. For functions and methods, the full declaration would be useful: name (along with receive for methods), parameters, and return values.

Contrast that with the current details. Here are two examples: the details field only contains the type name for constants and only has return values for functions and methods.

Here's a screenshot of completing constants in vim-go. The details field of the completion candidates is shown in the top window:
https://user-images.githubusercontent.com/1958864/57467163-e6f30f00-7236-11e9-8ce3-fe6a685b763d.png

Here's a similar screenshot of completing a method in vim-go. Again, the details field of the completion candidates is shown in the top window:
https://user-images.githubusercontent.com/1958864/57467081-b90dca80-7236-11e9-964c-e1f1e3f5cbdb.png

Relates to #31923
@gopherbot gopherbot added this to the Unreleased milestone May 9, 2019
@gopherbot gopherbot added the gopls Issues related to the Go language server, gopls. label May 9, 2019
@stamblerre
Copy link
Contributor

According to the LSP spec, detail is meant to contain "additional information about this item, like type or symbol information", which is why the detail is done this way.

An example in VSCode:
Screen Shot 2019-05-10 at 5 08 42 PM

It seems to me that maybe Vim should behave differently in this case? Detail is meant to augment the information provided in the label, not entirely replace it.

@bhcleek
Copy link
Contributor Author

bhcleek commented May 10, 2019

That's understandable.

Changing vim itself isn't likely to happen, but I can certainly use the details in vim-go more like you suggest. The one complication is methods and functions with more than one return value: parsing the details string correctly to decide when it should be wrapped with parentheses is tricky. Could we have gopls wrap the details with a set of parentheses when the function or method has multiple return values since gopls actually knows how many return values exist?

@stamblerre
Copy link
Contributor

Yep, gopls does that.

Screen Shot 2019-05-10 at 6 39 50 PM

(Depending on the length of the label and detail, VSCode displays things differently.)

@bhcleek
Copy link
Contributor Author

bhcleek commented May 10, 2019

Sounds good to me. Perhaps that changed recently? I've not seen the parentheses wrapping multiple return values in the details field...

@bhcleek bhcleek closed this as completed May 10, 2019
@golang golang locked and limited conversation to collaborators May 9, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge gopls Issues related to the Go language server, gopls.
Projects
None yet
Milestone
Unreleased
Development

No branches or pull requests
3 participants
@bhcleek @stamblerre @gopherbot