{{ message }}
Repository navigation
Conversation
…exing LSP `Position.character` is a UTF-16 code unit offset (the spec's own docstring gives the classic example, an astral character between two ASCII ones shifts every later offset). `SolidLanguageServer.insert_text_at_position` and `delete_text_between_positions` receive these straight from a language server (or echoed from one via LanguageServerSymbol's body positions) and indexed the in-memory buffer with them directly, which TextUtils treats as a plain Python string index (code points). Any character outside the Basic Multilingual Plane before the edit position, most emoji among them, made every following edit one code point too far. Convert at that boundary: TextUtils.utf16_offset_to_codepoint_offset before indexing, and its inverse before returning a cursor position that claims to be a Position again. Fixes oraios#2064
…ng fixture _make_server hardcoded repository_root_path as the POSIX literal "/repo" and passed it straight into _resolve_file_uri, which builds a pathlib.Path and calls as_uri(). On Windows, pathlib.Path treats a path with no drive letter as not absolute, so as_uri() raised "relative path can't be expressed as a file URI" for all three tests in this file on windows-latest CI. Build the fixture root from tempfile.gettempdir() instead, which returns a real absolute path in whichever platform's own convention the tests run under. Signed-off-by: Amir Fathi <amirfathi.me@gmail.com>
Member
This branch has not been deployed
This file contains hidden or 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
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.

Position.characterin the LSP spec is a UTF-16 code unit offset, not a Python code-point index.TextUtilsalready documents that it indexes by code point (see the docstring oninsert_text_at_position), but nothing converts at the boundary:SolidLanguageServer.insert_text_at_position/delete_text_between_positionstake the raw LSPcharacterand pass it straight through. Any character outside the Basic Multilingual Plane before the edit position, most emoji among them, puts every edit after it one column too far.This fixes it at the boundary: convert the incoming UTF-16 offset to a code-point offset before indexing, and convert back before returning a position that claims to be UTF-16 again.
test/solidlsp/test_position_encoding.pydrivesinsert_text_at_position/delete_text_between_positionsdirectly with a line containing an astral character. Both new tests fail on main with the exact predicted corruption (inserting one character late, deleting the wrong one) and pass on this branch.test/solidlsp/util/test_ls_utils.pycovers the new conversion helpers on their own.Not touched:
JetBrainsCodeEditorgets its positions from the JetBrains plugin, not the LSP, so it's outside this fix's scope. I haven't checked whether it has the same problem.Fixes #2064