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

Binary number literals with underscores appear as error blocks #2588

Closed
shabbyrobe opened this issue Nov 14, 2019 · 1 comment
Closed

Binary number literals with underscores appear as error blocks #2588

shabbyrobe opened this issue Nov 14, 2019 · 1 comment

Comments

@shabbyrobe
Copy link

What did you do? (required: The issue will be closed when not provided)

I created a source file with a binary number that contained underscores (i.e. 0b0000_0000)

What did you expect to happen?

I expected it to have the same colour as a binary number without underscores.

What happened instead?

It was a very different colour - a huge red error block!

Configuration (MUST fill this out):

vim-go version:

Current master (b7c7109)

vimrc you used to reproduce (use a minimal vimrc with other plugins disabled; do not link to a 2,000 line vimrc):

This isn't needed - I've attached the change I believe solves the issue below.

Vim version (first three lines from :version):

8.1.1368

Go version (go version):

1.3

Go environment

This isn't needed - I've attached the change I believe solves the issue below.


The syntax file invim-go is classifying binary number literals with underscores as goBinaryError instead of goBinaryInt.

I think the minimal change required is this, but I'm not sure and I'm not confident with complex vim regex nests that I'm not breaking something someone else relies on, hence an issue report rather than a PR:

-syn match       goBinaryInt         "\<-\=0[bB][01]\+\>"
-syn match       goBinaryError       "\<-\=0[bB][01]*[^ \t01]\S*\>"
+syn match       goBinaryInt         "\<-\=0[bB][_01]\+\>"
+syn match       goBinaryError       "\<-\=0[bB][_01]*[^ \t_01]\S*\>"

It looks like goHexadecimalInt and goOctalInt have the same problem, but similar minimal interventions like the above did not produce the desired outcome for me (octal ints and hex ints were no longer classified).

@bhcleek
Copy link
Collaborator

bhcleek commented Nov 18, 2019

fiexed by #2584

@bhcleek bhcleek closed this as completed Nov 18, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants