Go Syntax Highlighting has many bugs

[stevekuznetsov]

As the image shows below, there are a number of issues with the Go syntax highlighting provided by this package (and inherited from GoSublime?):

• Grave accent ``` strings do not correctly highlight for formatting arguments like %s
• Normal " strings do not syntax highlight correctly for numbered formatting arguments like %[1]s
• Primitives inside of function definition arguments or returns do not syntax highlight
• Function definitions that take more than one line cause the function name to stop highlighting
• Type definitions for function types cause the type keyword to stop highlighting
• Function definitions following a type definition of a function type do not highlight the func keyword or the function name
  

[stevekuznetsov]

Not all string formatting expressions are highlighted correctly:

[stevekuznetsov]

@jskinner Are you guys looking to maintain these .sublime-syntax repositories? Or is that going to be external-user based?

[jasonwilliams]

Would it be easier to just take the syntax parsing that the go-sublime package does?

[stevekuznetsov]

I remember that package having similar bugs, I wouldn't be surprised if the authors here re-formatted go-sublime's syntax into this one.

[stevekuznetsov]

Is there anyone at Sublime that will ever be actively working on getting this to a better state?

[jasonwilliams]

@stevekuznetsov ive been wondering this myself, their communication seems a little inept

[ottob]

DisposaBoy/GoSublime#660

It seems like someone is looking at this now.

[stevekuznetsov]

@wbond Can we get any communication on if there is a member of your team that is tasked with updating these syntax files? Will we ever see this fixed?

[wbond]

@stevekuznetsov I have been working through various issues and PRs recently. The best way to help would be to provide small self-contained examples of syntax that causes issues. That way I can make a test out of it to use while implementing a fix. Big PRs that change a lot are harder to review and accept.

I don't believe there is any specific roadmap for syntax tweaks, but I'll be spending some time on it.

[stevekuznetsov]

@wbond The original post in the issue highlights some of the issues I have found. Is this a reasonable format for you? Please let me know how to best aid you in your efforts.

[wbond]

I can re-type the samples provided in this issue. For future reports, if you create one issue per bug, with a description and text snippet of code, that will allow me to get them fixed most efficiently.

[stevekuznetsov]

@wbond awesome, will do.

[wbond]

Fixed the following issues:

• Indexed placeholders: 0329b1a
• Placeholders in raw strings: 162227f
• %q placeholder support: 263854f
• Handling for multiline params and return types: c21ab36

Commit c21ab36 also improves the symbol list by including the receiver type, making it possible to disambiguate between receiver functions for different types.

The highlighting of the parameters and return types is part of the color scheme. It may be possible to further improve the parsing of params and return types, but I know with the color scheme I use (Base 16), they are highlighted specially. If you are interested in specific highlighting of params, please open a new issue with details of how you think it could be improved.

[FichteFoll]

variable.receiver is not part of the textmate naming conventions. I don't mind derivating from these on occasions, but only where deemed appropriate and it should be documented somewhere so that color scheme authors have a good call at matching significant scopes. Having at least the first two leaves of every scope name within that documented set should ease highlighting considerably.

Personally (without Go experience), I think in (t Type) you should match t as variable.other.receiver and Type as storage.type.receiver. Unsure about return-types, that might be frequent enoug to warrant an addition to the conventions list.

FWIW, I derived this list from the textmate list and added scopes for punctiation, since they didn't exist there.

[wbond]

@FichteFoll I used the existing scope names (including variable.receiver) so that it would be backwards compatible. The only change was from meta.function.receiver.go and meta.function.plain.go to just meta.function.go since the parser now shares param and return type parsing between the various function types.

It certainly seems that there could be some work done at a high level to survey the existing syntaxes, extract scope information and try to document usage for the sake of making them more consistent and for informing color scheme authors. That however, would be a separate issue from this, and should be opened as such.

[stevekuznetsov]

@wbond +1 for Base 16 highlighting suggestion

[FichteFoll]

@wbond true, I'll see what I can do.