LSP

LSP copied to clipboard

Describe the bug

https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#serverCapabilities

this server capabilities is properly parsed by Sublime, it exists in the protocol, but it's never taken into account when providing various position, it only ever do it for utf16

Expected behavior If server capabilities only expect utf8, sublime should provide utf8 based positions

Environment (please complete the following information):

• OS: Windows 10 x64
• Sublime Text version: 4143
• LSP version: 1.22.0

It's not implemented yet, because it is relatively new.

Note that servers must support UTF-16, so

If server capabilities only expect utf8

is not possible.

Indeed. And we had a lot of struggle making UTF-16 work, so why bother with additional encodings?

Note that servers must support UTF-16

where do you see that?

Indeed. And we had a lot of struggle making UTF-16 work, so why bother with additional encodings?

because what you gonna do if the server says: "i only can understand utf-8"?

Note that servers must support UTF-16

where do you see that?

/**
	 * Character offsets count UTF-16 code units.
	 *
	 * This is the default and must always be supported
	 * by servers
	 */
	export const UTF16: [PositionEncodingKind](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#positionEncodingKind) = 'utf-16';

Prior to 3.17 the offsets were always based on a UTF-16 string representation

The client announces it’s supported encoding via the client capability

To stay backwards compatible the only mandatory encoding is UTF-16 represented via the string utf-16.

ok, you are right, looks like i initially misunderstood

But still, giving the choice of utf-8, it would be nice if it was supported to satisfy server needs

https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocuments

The only reason I can think where it would be beneficial for the server to support other encoding than utf-16 is when it would give serious performance gains. Otherwise it's just extra work both for the server and the client to support that.

Since we don't know of any servers that would benefit from it (not counting your private one since it's not clear why you'd want utf-8 to be supported), you can probably imagine that the incentive for implementing it is very small.

That said, we have acknowledged it as a feature request.

I'm just trying to make my server compliant to the specification