Support `workspace/configuration` request for every server initilize

[July541]

In the latest release of vscode-language-server-node, they don't send workspace/didChangeConfiguration more when the server is initialized, which causes haskell/vscode-haskell#920.

Following the comment of the SynchronizeOptions below, they suggest using workspace/configuration, so I'm thinking to extend ServerDefinition with a new field to send workspace/configuration while the server is initiated.

lsp/lsp/src/Language/LSP/Server/Core.hs

Line 280 in 97c7660

data ServerDefinition config = forall m a.

https://github.com/microsoft/vscode-languageserver-node/blob/f2ff7d55464a1f58f978cb6635bd8865f050553c/client/src/common/configuration.ts#L132

[michaelpj]

This is actually pretty bad. We can't send workspace/configuration requests during initialize. The "solution" seems to be "use dynamic registration for everything so you can request the configuration"?? This is very much not the model that we use, and probably requires significant re-architecting.

Possibly we can get away with doing this work when we receive the initialized notification from the client, but I'm really not sure.

I have read several of the issues about this and honestly I'm very confused about how this is supposed to work :(

[michaelpj]

Okay, so I think we could try and do something like what is described here as what rust-analyzer does: microsoft/language-server-protocol#972 (comment)

Namely:

• The server definition should specify the "section" that its configuration is in
• We must have a default value for the config
• If initializationOptions contains a member with the name of the section, use that as the initial config
• In the handler for initialized, we send workspace/configuration for the whole section, and replace the config with that (maybe don't do this if it was in initializationOptions? IDK)
• Whenever we receive workspace/didChangeConfiguration, ignore the value and refresh the whole config with workspace/configuration.

[July541]

Okay, so I think we could try and do something like what is described here as what rust-analyzer does

That is what I want.

I think the only problem is I'm not sure if we can send workspace/configuration after initialized. I'll try this several days later if you don't have time:)

Night is long, let me try it now:)

[michaelpj]

You're explicitly allowed to send workspace/configuration in the handler for initialized: microsoft/language-server-protocol#567 (comment)

The only thing is that I guess the client might start sending you requests during that time, so you probably have to be responsive. But we do already have the facility to change the config dynamically, so it shouldn't be too bad.

[michaelpj]

It just means that e.g. if you somehow hit a formatting request immediately after initialization you might get the default behaviour. But that probably just means that the default behaviour should be "no formatting", I guess.

[michaelpj]

Sounds like indeed the answer is "tough, accept it": microsoft/language-server-protocol#1006 (comment)

[July541]

BTW, I'm trying to find a way to ensure the client will send workspace/didChangConfiguration after restarting.

[michaelpj]

I think we can't count on that, though, so we probably need to handle the other case anyway.

[July541]

After reading some lsp code I found that patching handlers for SMethod_Initialized seems very hard in lsp side.

Is it possible to add a field about workspace/configuration handler, and then run it after SMethod_Initialized handler?

[michaelpj]

So, we already have this callback that should give us all the information we need to process config:

lsp/lsp/src/Language/LSP/Server/Core.hs

Line 284 in 97c7660

, onConfigurationChange :: config -> J.Value -> Either T.Text config

I think the only thing we need to be told additionally is the "section".

I agree it's a little tricky in lsp: the idea of having multiple handlers for things and then gluing them together is a HLS thing. So maybe we just want to provide people with helper functions to call in doInitialize and an Initialized handler. But I'm not really sure. It would be very nice if it just magically worked...

[July541]

So, we already have this callback that should give us all the information we need to process config:

Seems not this, onConfigurationChange is for handling the didChangeConfiguration notification. I think we need a function to send workspace/configuration request.

Left this up and see if haskell/haskell-language-server#3745 works firstly...

[michaelpj]

Seems not this, onConfigurationChange is for handling the didChangeConfiguration notification

I mean, that tells us what to do when we get a new config. Actually implementing it we can probably pull out a part of handleConfigChange.