Improve workflow for enabling/disabling semantic tokens #3338
Milestone
Comments
|
Change https://go.dev/cl/579337 mentions this issue: |
gopherbot
pushed a commit
to golang/tools
that referenced
this issue
Apr 17, 2024
Whether or not semantic tokens are enabled should be a client-side setting. Clients that don't want semantic tokens should not ask for them, and if clients send textDocument/semanticTokens requests, gopls should handle them by default. Unfortunately, as described in golang/vscode-go#3338, this is not how semantic tokens were configured in the past. This CL changes the default value of the "semanticTokens" setting to true. We should not release a gopls version with this change until addressing golang/vscode-go#3338, but by making this change in master now it is easier to test the fix in vscode-go. For golang/vscode-go#3338 Change-Id: I05d7084436cd4dfe312460cfe08e3b1777f190ed Reviewed-on: https://go-review.googlesource.com/c/tools/+/579337 Auto-Submit: Robert Findley <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]> Reviewed-by: Alan Donovan <[email protected]>
|
@findleyr Can we mark this gopls setting deprecated or to-be-deprecated to reduce confusion? |
|
@hyangah yes, we can do that. |
|
Note: we need to stage this configuration change in VS Code first, before un-reverting the change to gopls. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Right now, to enable semantic tokens with gopls, it is required to set
"gopls": { "semanticTokens": true }. Without this setting, gopls will return empty responses to semanticTokens requests (previously it returned an error, which led to the very verbose logs reported in golang/go#65712).This is a bit backward: if gopls advertises the semanticTokens capability, and an LSP client requests semanticTokens, gopls should provide semanticTokens as best it can. If clients don't want semanticTokens, they should not request them.
We'd like to fix this by changing the default value of the hidden "semanticTokens" setting in gopls to "true". After this change, gopls will behave as expected by default: if clients ask for semantic tokens, they will get them.
However, if we make this change to gopls, it will implicitly enable semantic token for all VS Code users. This is a very large and observable change, and it is likely that many users will not want this behavior. For example, I personally do not want semantic tokens as I find them to be visually distracting.
We should update vscode-go so that users will still opt-in to semantic tokens, even after this gopls change. Should we change the default behavior of the VS Code LSP client to not request semantic tokens? Should we inject
{"semanticTokens": false}into the vscode-go LSP settings, if it is unset?CC @hyangah
The text was updated successfully, but these errors were encountered: