In LSP, UTF-16 is not just for transport. Source locations are also referred to by their UTF-16 offset. That means applications are required to store a persistent mapping from UTF-16 offsets to whatever they use internally, keep that mapping updated as the document is edited, and map back and forth constantly.
Oh well. It was primarily designed to be a good protocol for VSCode, not for any other users. That's just the price you pay when using a corporate standard.
Oh you're right, except since LSP 3.17 position encoding can be negotiated with clients/servers that support it. I initially got confused because my work with LSP started with 3.17 and I always used UTF-8 encoding.
In LSP, UTF-16 is not just for transport. Source locations are also referred to by their UTF-16 offset. That means applications are required to store a persistent mapping from UTF-16 offsets to whatever they use internally, keep that mapping updated as the document is edited, and map back and forth constantly.
Oh well. It was primarily designed to be a good protocol for VSCode, not for any other users. That's just the price you pay when using a corporate standard.
No? In LSP source locations are line+character: https://microsoft.github.io/language-server-protocol/specifi...
https://microsoft.github.io/language-server-protocol/specifi...
The column is measured in UTF-16 code units
Oh you're right, except since LSP 3.17 position encoding can be negotiated with clients/servers that support it. I initially got confused because my work with LSP started with 3.17 and I always used UTF-8 encoding.
https://microsoft.github.io/language-server-protocol/specifi...