-
Notifications
You must be signed in to change notification settings - Fork 17.6k
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/cmd/gopls: completions don't expand correctly in Emacs #32078
Comments
My guess is VSCode only ever cares about the start. Thanks for catching this. The earlier change actually broke vim-go because it wasn't using the positions coming from the completion items, so it also might be worth checking if Emacs does that. I'm just wary of adding an end position at the original start because its technically not the end of the completion item. But then, to get the real end we would have to get the length of the insertText, which will include special characters that shouldn't be counted... |
The end of the range needs to to be the end of the text you are overwriting, not the end of the text you are inserting. Setting the end to the cursor position is correct except for the postfix completion case. To handle postfix, you need to basically set the start to the start of the *ast.Ident, and the end to the end of the *ast.Ident. |
Emacs definitely uses the positions properly (and so does VSCode). I've been running with a patch that does what I describe above for a while since it is required for fuzzy matching (the typed prefix is not actually a prefix of the insertion text so you have to overwrite it). The TextEdit range is the area of text you want to replace with the insertText. That's why you set start==end to insert text without replacing anything. As for why VSCode works, I would guess it sees start==end and the text after the cursor is a prefix of the completion item, so it automatically overwrites it.
|
Change https://golang.org/cl/177657 mentions this issue: |
Tested with newest company-lsp + this version of gopls, spaces after the completion point and some symbol is eaten. |
Change https://golang.org/cl/177757 mentions this issue: |
The insertion range for completion items was not right. The range's end was 1 before the start. Fix by taking into account the length of the prefix when generating the range start and end. Now instead of a "prefix", we track the completion's "surrounding". This is basically the start and end of the abutting identifier along with the cursor position. When we insert the completion text, we overwrite the entire identifier, not just the prefix. This fixes postfix completion like completing "foo.<>Bar" to "foo.BarBaz". Fixes golang/go#32078 Fixes golang/go#32057 Change-Id: I9d065a413ff9a6e20ae662ff93ad0092c2007c1d GitHub-Last-Rev: af5ab4d GitHub-Pull-Request: #103 Reviewed-on: https://go-review.googlesource.com/c/tools/+/177757 Run-TryBot: Ian Cottrell <iancottrell@google.com> Reviewed-by: Ian Cottrell <iancottrell@google.com>
I installed recently gopls I'm experiencing this bug for some reason |
Which version of |
@stamblerre |
My guess is that this is likely a bug with the Emacs integration, rather than |
@shackra can you open a separate issue with details about what you are seeing including reproduction steps and gopls debug log if possible? |
@muirrn yes I can, will do that during the week |
In Emacs when accepting a completion candidate, the already typed prefix is not replaced properly:
When we set the newText's range we properly move the range's start back to the start of the prefix, but we also move the range's end to the start of the prefix, so we end up just inserting the completion without overwriting anything. I think we need to leave the range's end at the cursor position so the prefix is overwritten. I'm not sure why VSCode doesn't show the same problem.
/cc @stamblerre
The text was updated successfully, but these errors were encountered: