Order of multiple TextDocumentContentChangeEvent #279
Conversation
What should happen if `textDocument/didChange` contains multiple `contentChanges`? This will happen if (1) an editor client supports multiple cursors, and (2) a language server supports incremental edits. (Contrast with `TextEdit`, where in cases where the LSP server sends multiple `TextEdit`s to the client, the client is expected to sort them in reverse order). I think that for uniformity with `TextEdit`, we should say that whoever receives an array of edits (be they `TextEdit`s or `TextDocumentContentChangeEvent`s) is responsible for sorting them and applying them in reverse order. And whoever sends them is responsible for ensuring that they're non-overlapping. Of course, most LSP servers don't yet do this. Most of them at the moment seem to just apply the array of edits blindly in the order in which they were received. I think therefore, in our transitional period up until LSP servers start doing that, the clients should (for convenience and compatibility) do the sorting themselves. Atom editor already does, and VSCode editor should follow suite. atom/atom-languageclient#72
| @@ -1496,6 +1496,8 @@ _Registration Options_: `TextDocumentRegistrationOptions` | |||
|
|
|||
| The document change notification is sent from the client to the server to signal changes to a text document. In 2.0 the shape of the params has changed to include proper version numbers and language ids. | |||
|
|
|||
| Similarly to `TextEdit`, if multiple `contentChange`s are applied to a text document, all text edits describe changes made to the initial document version. Execution-wise text edits should be applied from the bottom to the top of the text document. Overlapping text edits are not supported. | |||
There was a problem hiding this comment.
Based on fcb32f9, it seems like the claim that the changes are for the initial version of the document is incorrect?
|
No this is not correct and I clarified this at least for document changes in the protocol. The behavior is as follows to make it as easy as possible to consume changes or create text edits. The burden of doing the right thing is basically pushed to the too (e.g. client). The behavior is as follows:
I clarified the documentation for this. |
What should happen if
textDocument/didChangecontains multiplecontentChanges? This will happen if (1) an editor client supports multiple cursors, and (2) a language server supports incremental edits.(Contrast with
TextEdit, where in cases where the LSP server sends multipleTextEdits to the client, the client is expected to sort them in reverse order).I think that for uniformity with
TextEdit, we should say that whoever receives an array of edits (be theyTextEdits orTextDocumentContentChangeEvents) is responsible for sorting them and applying them in reverse order. And whoever sends them is responsible for ensuring that they're non-overlapping.Of course, most LSP servers don't yet do this. Most of them at the moment seem to just apply the array of edits blindly in the order in which they were received.
I think therefore, in our transitional period up until LSP servers start doing that, the clients should (for convenience and compatibility) do the sorting themselves. Atom editor already does, and VSCode editor should follow suite.
atom/atom-languageclient#72