x/tools/gopls: create a new snapshot on didChangeConfiguration

[stamblerre]

It would probably simplify our logic to treat this as an invalidation event, especially since a change in environment leads to metadata invalidations.

[krobelus]

I'm not sure if this is the same issue: I expect that settings sent via didChangeConfiguration are applied immediately

For example, given this file

package main

func main() {
	println()

}

1. I start goplswith no configuration
2. I send {"jsonrpc":"2.0","method":"workspace/didChangeConfiguration","params":{"settings":{"formatting.gofumpt":true}}}
3. I send {"jsonrpc":"2.0","method":"textDocument/formatting", ...}
4. Nothing happens; I expect the empty line after pringln() to go away.

It works when I restart the language server, or when I use workspace/configuration instead.
I don't think a restart should be necessary, and not all clients (want to) implement workspace/configuration. For example it doesn't really make sense for the client I'm using - https://github.com/kak-lsp/kak-lsp - some implementation reasons prevent mult-workspace-in-single-editor-session for now.

---

Tangentially related: my main problem with workspace/configuration is that it needs section headers. To send "formatting.gofumpt", the user needs to specify {"gopls":"formatting.gofumpt"}. OTOH "formatting.gofumpt" already works when sent as initialization option. I'd like to use a single config object for both, so the user doesn't have to care about protocol details. In the config system of kak-lsp, there is one object for each language, so I'm having a hard time understanding the need for the section header.

[stamblerre]

@krobelus: Your topic is actually a separate issue, but I can answer it briefly. For some reason, VS Code doesn't actually send the modified settings in its didChangeConfiguration request, so we rely on workspace/configuration to get the updated values. We also use workspace/configuration to get the settings at initialization.

You shouldn't need section headers for workspace/configuration. Here is an example request/response from VS Code:

[Trace - 17:08:47.027 PM] Received request 'workspace/configuration - (2)'.
Params: {"items":[{"scopeUri":"file:///Users/rstambler/code/src/golang.org/x/tools","section":"gopls"}]}


[Trace - 17:08:47.033 PM] Sending response 'workspace/configuration - (2)' in 5ms.
Result: [{"verboseOutput":true,"ui.diagnostic.analyses":{"fillreturns":true},"ui.semanticTokens":true,"experimentalUseInvalidMetadata":true,"ui.diagnostic.staticcheck":true,"ui.completion.experimentalPostfixCompletions":true,"ui.completion.usePlaceholders":true,"build.experimentalTemplateSupport":true,"build.experimentalWorkspaceModule":true}]

[krobelus]

Thanks that's good to know. It looks like gopls accepts the same options in both didChangeConfiguration and workspace/configuration which makes things simpler, but other servers might not.

[findleyr]

This is a persistent source of bugs. We should fix in the next release.

[gopherbot]

Change https://go.dev/cl/524837 mentions this issue: gopls/internal: move Options and FileKind from View to Snapshot

[gopherbot]

Change https://go.dev/cl/526160 mentions this issue: gopls/internal/lsp/cache: move workingDir to workspaceInformation

[gopherbot]

Change https://go.dev/cl/526417 mentions this issue: gopls/internal/lsp/cache: move Option management to the Server

[gopherbot]

Change https://go.dev/cl/526159 mentions this issue: gopls/internal/lsp: move options into the snapshot