-
Notifications
You must be signed in to change notification settings - Fork 18k
x/tools/gopls: superfluous {} added to first completion result for named struct type #36655
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
Comments
Do you have snippets turned on? It should be leaving the cursor in the curlies unless the struct has no visible fields. |
No. |
Oops, that sent too early.
I'm not sure I see how that's possible given the results sent back because there's just a single text edit. |
Snippets are required to place the cursor in different spots. With snippets on, you will get insert text something like Perhaps literal completions that use snippets should be disabled if the client doesn't have snippet support enabled. It is certainly counter productive to leave the cursor in an annoying position. Out of curiosity, do you have snippets disabled intentionally, or does your client not support them? |
Agreed.
Both :) We still need to add this support in |
There are two easy options:
Personally I find literal candidates very useful and would still want to use them even if my editor didn't support snippets, so I vote for 1). |
Agreed. We need to get snippet support in soon so we can also take advantage of this. But agree that in the meantime disabling "literal" completions feels like the best solution if the client doesn't support snippets. |
@stamblerre I'd like to suggest that this be moved to the |
@muirdm: Did you mean 2) in that comment? Because I tend to agree that I would rather have the literal candidates than not. We have a flag to disable literal candidates, but we don't expose it to the user right now. @myitcv: If we added the ability for the user to disable literal completions, would that be sufficient? |
Yes, that would work. But per @muirdm's comment, I don't think it makes sense to return literal candidates if the client doesn't support snippets, because the cursor ends up in the wrong place. However I'll defer to you both on this - I don't really have that much experience of the various options in this space. |
While I would prefer to leave them in because I do find them very useful, I think it's probably easiest to disable them for now (if the client doesn't support snippets). It also allows us to delete the |
Change https://golang.org/cl/216299 mentions this issue: |
What version of Go are you using (
go version
)?Note that per govim/govim@c7a6cc3,
github.com/myitcvforks/tools/gopls@v0.0.0-20200119092928-0fd5434cd1ba
is 0cba7a3 with a partial revert of CL214586 on top (the result of which can be seen in https://go-review.googlesource.com/c/tools/+/215239)Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
Attempted to complete the following type:
https://github.com/govim/govim/blob/0876ba34ac78adec927e745f119759215fac3406/cmd/govim/internal/golang_org_x_tools/lsp/protocol/tsprotocol.go#L2655
i.e. had the following text:
with the cursor at the position indicated by
_
and then requestedCompletion
.Got the following results back:
Selected the first entry, labelled
SignatureHelpParams{}
, to complete completion.What did you expect to see?
What did you see instead?
Note the additional
{}
. I was expecting to have to type a{
to then fill out some fields.Perhaps this is intentional, so that the completed value is then valid for the context? If so, I wonder whether we can do better here by specifying two edits to leave the cursor in between the
{
and}
?cc @stamblerre @muirdm
FYI @leitzler
The text was updated successfully, but these errors were encountered: