Skip to content
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

x/tools/gopls: semantic tokenizing of numeric modifiers and imaginary unit #45792

Open
soypat opened this issue Apr 27, 2021 · 4 comments
Open

x/tools/gopls: semantic tokenizing of numeric modifiers and imaginary unit #45792

soypat opened this issue Apr 27, 2021 · 4 comments
Assignees

Comments

@soypat
Copy link

@soypat soypat commented Apr 27, 2021

What version of Go are you using (go version)?

$ gopls version
golang.org/x/tools/gopls v0.6.10
    golang.org/x/tools/gopls@v0.6.10 h1:8Ebz8PymS2umcuCFhoz67unyJfWsipjTIrkBUF9kypg=

$ VsCode settings:
 "gopls": {	
        "ui.semanticTokens": true,
	},
    "editor.semanticHighlighting.enabled": true,

What did you do?

Write following code in VSCode with semanticTokens enabled

const (
    hexReg  = 0x1337
    bitmask = 0b0110_1100

    google = 1E100
    planck = 2e-23
    // How to tokenize this?
    c = 1+20i
)

What did you expect to see?

Semantic tokenization of 0x, 0b, E, and e numeric modifiers. This was colored before enabling LSP semantic tokenization. The coloring for these could be keyword (this was the default coloring I was accustomed to seeing before enabling semantic tokenizing). As a bonus maybe the 0 in octal notation could be colored for clarity?

I'm not sure how i (imaginary unit) should be tokenized. It seems to serve a different purpose as it is a number by itself. It would probably be helpful to color it though! Maybe property token for it?

What did you see instead?

Monocolor numbers.

@gopherbot gopherbot added this to the Unreleased milestone Apr 27, 2021
@soypat soypat changed the title x/tools/gopls: semantic tokenizing of x/tools/gopls: semantic tokenizing of numeric modifiers and imaginary unit Apr 27, 2021
@stamblerre
Copy link
Contributor

@stamblerre stamblerre commented Apr 27, 2021

/cc @pjweinb

@ALTree
Copy link
Member

@ALTree ALTree commented Apr 27, 2021

0x1337, 1e100 and 1+20i all are a single number, all should be one single token, and if you have colourization enabled I would not expect e.g. the e in 1e100 to be of a different colour (why would it be? It's part of the number and has no meaning by itself). Same for the + and the i in complex literals.

@soypat
Copy link
Author

@soypat soypat commented Apr 27, 2021

I could really do without the e and i colorization in 1e10i. That said, I would benefit from some sort of colorization of 0x and 0b in 0x1337 and 0b0101 since they have a fundamental impact to the interpretation of the digits. It would make surfing Register definitions, flags and bitmasks a more pleasant task.

@suzmue suzmue modified the milestones: Unreleased, gopls/unplanned Apr 27, 2021
@hyangah
Copy link
Contributor

@hyangah hyangah commented Apr 27, 2021

@pjweinb FYI I added the numeric number highlighting here jeff-hykin/better-go-syntax@43a6d98 in the textmate rule. I don't know if this makes sense for 'semantic token' feature - they are all numbers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
7 participants