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...

I'm just wary of adding an end position at the original start because its technically not the end of the completion item

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.

it wasn't using the positions coming from the completion items, so it also might be worth checking if Emacs does that.

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.

interface TextEdit {
	/**
	 * The range of the text document to be manipulated. To insert
	 * text into a document create a range where start === end.
	 */
	range: Range;

Change https://golang.org/cl/177657 mentions this issue: internal/lsp: use ranges instead of positions in completion items

Tested with newest company-lsp + this version of gopls, spaces after the completion point and some symbol is eaten.

Before completion:

After:

@stamblerre

Change https://golang.org/cl/177757 mentions this issue: internal/lsp: fix completion insertion

I installed recently gopls I'm experiencing this bug for some reason

Which version of gopls are you using (gopls version)?

@stamblerre version v0.1.1, built in $GOPATH mode

My guess is that this is likely a bug with the Emacs integration, rather than gopls. This issue was fixed in gopls quite some time ago, but it's possible that some Emacs clients aren't looking at the correct insertion ranges provided by the TextEdit field of a completion item.

@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