~xerool/fennel-ls#7: 
fix workspace/didChangeConfiguration

Thank you to ~adjuvant for finding this.

Apparently, the spec's description of workspace/didChangeConfiguration involves the server sending a request for the configuration.

It seems like it should be possible to simply add some code to make the request.

Status
REPORTED
Submitter
~xerool
Assigned to
No-one
Submitted
1 year, 3 months ago
Updated
5 months ago
Labels
bug

~adjuvant 1 year, 3 months ago*

Earlier I wrote (https://lists.sr.ht/~xerool/fennel-ls/patches/43841)

Configuration is not possible, because there is no way to trigger a workspace/didChangeConfiguration notification, without the server requesting the section first.

I was wrong. Of course there is a way to send arbitrary notifications with the vscode-languageclient library. Now I am sending the configuration notification. And it works.

However, I fear, we still have to send the configuration request to ensure that the configuration is loaded before anything else happens. Even if I send the workspace/didChangeConfiguration directly after initializing the client, the first textDocument/didOpen still occurs earlier.

[Trace - 22:07:39] Sending request 'initialize - (0)'.
[Trace - 22:07:40] Received response 'initialize - (0)' in 191ms.
[Trace - 22:07:40] Sending notification 'initialized'.
[Trace - 22:07:40] Sending notification 'textDocument/didOpen'.
[Trace - 22:07:40] Sending notification 'workspace/didChangeConfiguration'.
[Trace - 22:07:40] Received notification 'textDocument/publishDiagnostics'.

~adjuvant 1 year, 3 months ago

We could issue the 'workspace/configuration' request in response to the 'initialized' notification. But that would not help with the bad timing. The client will send the 'textDocument/didOpen' notification directly after 'initialized', and wont wait for our request. The only way this could work reliably is, if the server were to delay processing all notifications and requests, until the 'workspace/configuration' response is received. But I do not like that very much, as the server would need to buffer those requests and "replay" them after the configuration is received. Lots of special handling just for this one configuration request.

Another way, which I find more practical and intuitive, is to embed the configuration directly into the 'initialize' request. This way, we can easily ensure, that the configuration is set before anything else happens. This is how the rust-analyzer does it. (In addition to the 'workspace/configuration' request.) https://github.com/rust-lang/rust-analyzer/blob/master/docs/dev/lsp-extensions.md#configuration-in-initializationoptions

Register here or Log in to comment, or comment via email.