Language-server-protocol: Adopt new insert and replace behavior for completion item

[dbaeumer]

There is a proposal in VS Code to be able to support insert and replace behavior for completion items. We should investigate adoption in LSP.

[matklad]

Related (I think) issue: https://github.com/microsoft/language-server-protocol/issues/793

[puremourning]

Can I make a humble request that it be made very clear in the spec that this is -optional- and ensure that it is clear many (most?) clients won’t support it. And that the default behaviour should be to _replace_.

There is a big history of server vendors only implementing what vscode implements and breaking other clients.

[dbaeumer]

@puremourning fully agreeing that this needs to be guarded by a client capability and clearly document that the new behavior is only supported if the client capability is set.. However I can't enforce in the protocol that servers stick to the right interpretation of the capability.

[rcjsuen]

Want to clarify my understanding of this feature. Given the following snippet with the pipe character as the text caret...

 b a n|a n a
0 1 2 3 4 5 6

If I invoke code completion, I will get bandana. So to support both cases, I will want something like this, correct?

{
  "label": "bandana",
  "textEdit": {
    "newText": "bandana",
    "insert": {
      "start": { "line": 0, "character": 0 },
      "end": { "line": 0, "character": 3 }
    },
    "replace": {
      "start": { "line": 0, "character": 0 },
      "end": { "line": 0, "character": 6 }
    }
  }
}

The insert case will replace ban with bandana with a resulting text of: bandanaana
The replace case will replace banana with bandana with a resulting text of: bandana

Is the above correct? Thanks!

[dbaeumer]

Yes, that is the intend. However I would make the edit a little simplier with the text only being dana.

[puremourning]

how would the client choose between them ?

[rcjsuen]

how would the client choose between them ?

@puremourning According to #793, IntelliJ seems to distinguish this based on the character pressed.

[rcjsuen]

Yes, that is the intend. However I would make the edit a little simplier with the text only being dana.

@dbaeumer Is that just for space saving purposes on the JSON payload?

[dbaeumer]

@rcjsuen yes and know. I most of the time try to align the completion items to the cursor position since it makes computing them easier (e.g. to ensure filtering and highlighting works as expected).

@puremourning yes, the client has to use two different user gestures to decide which completion range to use. This will depend on the editor. If a editor doesn't has such a capability it can turn the feature of in the client capabilities.

[puremourning]

Thanks, Dirk. Makes sense.

[dbaeumer]

Closing. Got implemented and documented.

[DanTup]

@dbaeumer do you happen to have a rough ETA for v3.16 being finalised? There are a quite a few things in it I'd like to support, but I'd prefer not to land changes that aren't finalised yet (nor do I want branches hanging around for a long period). I thought it was close, but the milestone is only around 60% complete. Thanks!

[dbaeumer]

@DanTup plan is to ship 3.16 before end of year. The only bigger feature left is onTypeRename

[DanTup]

@dbaeumer great, thanks!