Thus, the item being invoked doesn't have a textEdit and Vscode just defaults to inserting the label text at the cursor instead.

The text edit, better the range and insertText, is needed early on before filtering and scoring happens because they play a role in how that works. Otherwise sorting would change when going up and down in the list of suggestions. Because of that it is unlikely that we simple allow to change these things after the fact (that we do is maybe the actual bug)

It is not at all clear from the language-server specification that the text edits aren't supposed to be lazy resolved. By my reading of it, I was assuming that lazy resolution of both the edits and the doc strings would be something one might do 'lazyly'.

Now, I went back to the spec and I have to admit this is more based on my own intuition and the fact that both computing complex set of edits and doc strings could be something 'expensive'. It is not really somthing spec says literally. In fact, the spec doesn't seem to say what qualifies as 'additional information' that is computed by lazy resolution.
Per my reading I interpreted it to include 'edits' as well as 'doc string' because, intuitively one would expect that the edits are not needed / used until a particular completion is selected and applied by the user.

Yes, I understand your comment about sorting, but that is really not that intuitive at all, especially given the fact that language server spec also includes a sort string in the item (which now, as I understand, is, for the most part, being ignored by vscode, in most cases).

I think there's a bit of a dilemma here that

• I think its reasonable to expect/support lazy resolition of complex edits
• the particular way in which vscode uses the edit in determining sorting makes this somewhat impossible or pointless (i.e. if you have to resolve every item before sorting, then its pointless to make them lazy).

I do think this 'dilemma' is probably more of an idiosyncracy in vsode's implementation/interpretation of the spec. I would guess that other language server client implementation, probably don't use the edit text in this way. Call it an educated guess, I have not confirmed this, but simply relying on the sortText for sorting is the more straighforward way to interpret the spec.

Assigining to @dbaeumer for the LSP discussion. We have no plan on changing how items are sorted and since that depends on the text edit that cannot be lazy in VS Code.

@jrieken can you enlighten me why the sorting depends on text edits. I can easily argue that we need the label, sort text, ...

... and shouldn't we document that in the vscode.d.ts as well. It is not just LSP being underspecified :-)

can you enlighten me why the sorting depends on text edits

@jrieken can correct me if I'm wrong, but I think this is because vscode is trying to sort based on 'relevance' (and mostly ignores the sortText). The relevance is determined by a matching algorithm that takes as input the characters that make up the 'query' versus the completion item. Basically, it wants to put the things that are a better match to what you typed at the front of the list. But, to do that, it uses the replacement region of its text edit to determine the 'query' you typed.

We had lengthy discussion about this in the past: #26096

I clarified this in the spec and made only documentation and detail lazy resolvable. If we think that other clients can handle more lazy attributes or want to change this I propose we introduce a capability that describes which properties can be lazy. However I first would wait for someone asking for this.

Closing. Changes happened in vscode-languageserver-node and language-server-protocol.