-
Notifications
You must be signed in to change notification settings - Fork 773
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
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Based on fcb32f9, it seems like the claim that the changes are for the initial version of the document is incorrect?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added sorting in my language server but perhaps clients are supposed to ensure that the changes are sent in the right order?
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/didChange
contains 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 multipleTextEdit
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 theyTextEdit
s orTextDocumentContentChangeEvent
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