points by 0cf8612b2e1e 3 days ago | 0 comments
It kept with UTF-16. New protocol is a chance to correct that poor decision.
[–] ivanjermakov 3 days ago
What's wrong with UTF-16 for transport?
[–] hmry 3 days ago
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.
[–] ivanjermakov 3 days ago
No? In LSP source locations are line+character: https://microsoft.github.io/language-server-protocol/specifi...
https://microsoft.github.io/language-server-protocol/specifi...
[–] hmry 3 days ago
The column is measured in UTF-16 code units
[–] ivanjermakov 3 days ago
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...
[–] marshray 3 days ago