x/tools/gopls: semantic tokenizing of package identifier #46475
Comments
gopherbot
added
Tools
|
package names are 'namespace', err is 'variable'. In the theme of my
vscode, the color of namespace is #4EC9B0 and variable is #9CDCFE (using
the command Editor: inspect tokens and scopes) What theme are you using?
there's a setting editor.tokenColorCustomizations, but the documentation
doesn't mention semantic tokens.
…On Mon, May 31, 2021 at 5:33 PM Patricio Whittingslow < ***@***.***> wrote:
What version of Go are you using (go version)?
$ go version
go version go1.16.3 linux/amd64
gopls versiongolang.org/x/tools/gopls v0.6.11
***@***.*** h1:7S2k0xuVYc3secjy2uz0n+fGYxGJU6gXsLOmQ/r1HoI=
What did you do?
Import any package like so:
import main
import "io"
func main() {
err := io.EOF
panic(err)
}
What did you expect to see?
io tokenized differently from variables such as err in this case.
What did you see instead?
io and err have same color.
Motivation
I may be wrong, but are packages tokenized just like variables? It seems
to be the case. I propose there be some distinction so that one can easily
identify when one is dealing with a package level identifier (i.e. io.EOF)
vs. a method/field (i.e. err.Error()).
Tokens available for a LSP implementation are listed here.
<https://microsoft.github.io/language-server-protocol/specifications/specification-current/#textDocument_semanticTokens>.
I believe class semantic token would be suited for packages as they
represent a similar namespacey construct.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#46475>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABJIAI63N66CY54ZEO367GTTQP6BXANCNFSM453PUZJQ>
.
|
|
First of all thanks for the quick reply. You are right about there being a
I'm on VSCode using Darcula theme. Using |
I just wanted to point out that there's a mistake in this example--it should be |
|
@stamblerre I was testing actual working packages, I typed the example up as a MWE. The issue still holds. |
|
I think that, in this instance, this is an issue with the Darcula theme that you could perhaps raise in that repository. For contrast, see how it looks with VS Code's default dark theme:
which logically makes more sense than changing it to class. And
If the Darcula theme doesn't provide differing colorization for namespace tokens, then that is an issue with the theme, not the tokenization here. |
stamblerre
added
the
WaitingForInfo
|
You are right. Switching to VSCode default highlighting I can see the namespace colorization. I'm not sure what I was doing wrong before but after testing this and changing the settings (below) I can change Darcula's "editor.semanticTokenColorCustomizations": {"rules": {"type": "#ff0000","namespace":"#ff0000"}},I'm closing this as it is not an issue related to go or gopls. |
What version of Go are you using (
go version)?$ go version go version go1.16.3 linux/amd64 gopls version golang.org/x/tools/gopls v0.6.11 golang.org/x/tools/gopls@v0.6.11 h1:7S2k0xuVYc3secjy2uz0n+fGYxGJU6gXsLOmQ/r1HoI=What did you do?
Import any package like so:
What did you expect to see?
iotokenized differently from variables such aserrin this case.What did you see instead?
ioanderrhave same color.Motivation
I may be wrong, but are packages tokenized just like variables? It seems to be the case. I propose there be some distinction so that one can easily identify when one is dealing with a package level identifier (i.e.
io.EOF) vs. a method/field (i.e.err.Error()).Tokens available for a LSP implementation are listed here.. I believe
classsemantic token would be suited for packages as they represent a similar namespacey construct.The text was updated successfully, but these errors were encountered: