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.
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 firsttextDocument/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'.
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