Open RLovelett opened 8 years ago
Sadly this is probably going to roll into the next (or a subsequent) release. It turns out this is going to be more in-depth than I hoped.
Basically it boils down to the fact that the TextDocument
's method, offsetAt
is not a byte aware offset, like SourceKit requires. This means we need to write a byte aware version of TextDocument
and/or offsetAt
.
I'm going to try and list all the up-stream bugs related to this in VS Code:
When auto-completing a line that contains an emoji (or any other multi-byte unicode character) the suggestions stop working.
For instance, typing
let 💯 = Foo(
does accurately bring up the suggestion box. However the suggestions are not relevant to the location of the current cursor position.Overview
The problem is that
FullTextDocument
does not handle Unicode characters.For example, say we have two Swift source documents:
ascii.swift
unicode.swift
Both source documents have the same number of code points, e.g., 46, but they have a different number of bytes, e.g., 46 for
ascii.swift
and 49 forunicode.swift
.Therefore, if you were to ask for the byte-offset of the closing parenthesis in
ascii.swift
it would be45
. Compare that withunicode.swift
which would have the value48
.Example
Using the same above documents,
ascii.swift
andunicode.swift
.Resolution?
One idea that I've been working towards is creating a new class
UnicodeTextDocument
that conforms to theTextDocument
interface.Which could serve as a drop-in replacement for
TextDocument
that transparently provides byte-offset.Such that you could do: