[Go] Syntax highlighting picks up commented code

[sublimehq]

[Go] Syntax highlighting picks up commented code

[ottob]

Yes, something is fishy with the var keyword. I have this:

v := "var f"
fmt.Println(v)

resulting in:

Notice that fmt.Println(v) is highlighted as a comment, as is the rest of the file after the var keyword. If I edit the string to be just "var" or "varf" the highlighting doesn't break.

[ottob]

Adding a string with comment slashes seem to reset the highlighting:

If I remove the slashes, the comment highlighting continues:

[wbond]

There is a bug in Sublime Text's sregex engine that is treating the [[:blank:]] posix range as all of ascii. Should be fixed in the next dev build.

[FichteFoll]

I see that the Go syntax definition uses [[:blank:]] twice and \s everywhere else. Any particular reason?

From what I can tell, they differ in that \s also matches 000A, 000B, 000C, 000D, 0085(NEL), 2028 and 2029 characters, so mostly characters separating lines. Regular expressions are never applied on "multiple lines" though, except for when ST does not implement a unicode line separator character as an actual line separator (which is anything but 000A and 000D; see sublimehq/sublime_text#548).

[wbond]

@FichteFoll I believe the reason, in this case, is that someone wrote the .tmLanguage version and it was converted to .sublime-syntax. I have noticed that in general the syntax tends to handle unicode better than many, such as by using [[:alpha:]] and [[:alnum:]] instead of just [a-zA-Z] and [a-zA-Z0-9]. My guess is that they used [[:blank:]] for such a reason.

[wbond]

In the process of testing the fixes in ST for ``[[:blank:]]` I fixed a few small issues with the syntax in 380a68e.

[stevekuznetsov]

@wbond thanks so much for doing this work. If I'm trying to pick up your changes, is there a faster way than waiting for a new beta build?

[FichteFoll]

@stevekuznetsov follow the 'Installation' guide in the readme.

[ottob]

My issues are fixed now. Thanks @wbond!