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.