The LSP client may send document content with non-LF line endings, normalize before comparing with NB document content. #6690
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…rmalize before comparing with NB document content.
sdedic
approved these changes
Nov 15, 2023
|
Thanks for the review! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When a file is opened, the
didOpencalled in the LSP server is called. The LSP client (tested with Visual Studio Code) sends the file text/content with their real line endings, which may be\r\n. Internally, the NB server only uses\n. In thedidOpencallback, when the server compares the text from the client and the internal document, the contents will be different, and the server will re-set the Document's content to the received file content.Such Document is internally marked as modified, which may cause problems or accentuate other problems (see for example oracle/javavscode#51 or oracle/javavscode#26).
In this patch, I've tried to fix this, by normalizing the line endings before the comparison. I've tried to make this in a way that files with '\n' don't pay additional cost for line endings normalization in the common cases (i.e. when the file content as sent from the client, and the content of the document match).