-
Notifications
You must be signed in to change notification settings - Fork 730
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve workflow for enabling/disabling semantic tokens #3338
Comments
Change https://go.dev/cl/579337 mentions this issue: |
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 <rfindley@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Alan Donovan <adonovan@google.com>
@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. |
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: