Zig: Send patch to GitHub to add syntax highlighting for Zig

[rom1504]

It seems they merge PRs fairly often, it might be worth it. https://github.com/github/linguist

[thejoshwolfe]

from here:

In most cases we prefer that each new file extension be in use in hundreds of repositories before supporting them in Linguist.

I think it's too soon for .zig.

[rom1504]

Oh yeah I didn't see that. You're right, I guess that will be for a later time.

[rom1504]

I think this can be re-opened at a time when it makes sense.

[jfo]

github/linguist parses tmLanguage files, and their built-in compiler can also accommodate YAML-tmLanguage (but not JSON-tmLanguage, unfortunately). Many syntax repos point to sublime text plugins that use YAML and transform it to tmLanguage xml using PackageDev.

Sublime 3 has moved to a more full featured syntax format called sublime-syntax but it will still parse tmLanguage files. Linguist will not parse sublime-syntax files. This is an opportunity to get sublime syntax support for "free" along with linguist support, with the caveat that the YAML-tmLanguage file would have to be coupled/commited with a compiled tmLanguage file alongside and it would be using an "out of date" syntax format from sublime's perspective. There could also be a dedicated linguist repo with just the YAML, but this seems unnecessary.

I've gotten a decent start on this at https://github.com/jfo/sublime-zig-language. Note the now extraneous sublime-syntax file and the (compiled) tmLanguage file. This is mostly based on the vim syntax and the sublime syntax docs, hewing to semantic names wherever possible. I'd love help with completing this syntax; the regex's are fiddly and full of terrors and I feel that some of the more specific parts are worth getting right, since this would become the syntax highlighting that a lot of casual github perusing zig viewers would see first / most.

I've got a linguist commit ~ready to be PR'd, it would look something about like this. This includes the color that shows up in the bar! I think it randomly assigns unused colors, currently it's this but it could also be the zig yellow/orange, or whatever else.

there are some todo's I know about:

• [x] 10e+77
• [x] \\ something something
• [ ] "blah\xblah"
• [ ] 'c'

And a few others.

This would look about like:

• [x] finalize YAML grammar
• [ ] submit to packagecontrol.io
• [ ] PR to linguist
• [ ] profit.

If this looks like a good roadmap, I'd be happy to transfer ownership of the plugin repo to zig-lang, as I'm not a sublime user myself and would prefer not to maintain it after documenting.

It's not looking bad

But has a ways to go.

A note: if you'd like to test this locally in sublime text while iterating, you'll need sublime 3 and https://github.com/SublimeText/PackageDev. I've been compiling the yaml to tmLang from within sublime and then simply cp'ing that tmLanguage file into the sublime plugin path. That looks like

cp Zig.tmLanguage "/Users/jfo/Library/Application Support/Sublime Text 3/Packages/User/Zig.tmLanguage"

for me, on OSX 10.13. There is a github flavored theme built in, though I don't know how accurate it is.

The YAML references here are helpful:
http://docs.sublimetext.info/en/latest/reference/syntaxdefs.html
http://docs.sublimetext.info/en/latest/extensibility/syntaxdefs.html

and the og textmate ref:
http://manual.macromates.com/en/language_grammars#naming_conventions.html

[tiehuis]

Looks like a great start!

I've installed sublime-text-3 locally and everything works as you've stated. I'll see if I can help you fix up those outstanding issues and finalize the grammar this week. I would like to compare against the vscode grammar too, since I'm sure there'll be a few missing edge cases there.

[jfo]

awesome, thanks! Yes strictly speaking the vscode plugin and the YAML-tmLanguage / tmLanguage are both using the same namespacing conventions and it would probably be best to keep them in sync. It's unfortunate there's no more universal representation of this mapping, although it seems like sublime-syntax is gaining general traction (I saw an atom thread about moving towards it). It is much nicer to work with in my limited experience. It's too bad linguist doesn't support that out of the box but the above linked PR leads me to believe they had implementation problems of some kind with it.

I wanted to mention that there are good opportunities for splitting up some of the keyword groups some more. afaict subgroups only affect highlighting if they've been targeted by the theme directly and default to the most specific ns that's available.

Glad the sublime workflow worked for you, it took me a little while to figure out how to set it up :)

[jfo]

I've moved the sublime repo to: https://github.com/zig-lang/sublime-zig-language

Please all feel free to hack on that, I'm going to revisit the numerics' regexes sometime in the next few weeks before cleaning it up and packaging it as a subl plugin.

[jfo]

I meant to add closing syntax to the PR, not to the commit. This is not merged yet.

[jfo]

This is blocked for now due to pending popularity, see https://github.com/github/linguist/pull/4005#issuecomment-364741546

[kristate]

What is the latest on this? @jfo @andrewrk

[jfo]

@kristate still pending on popularity afaict tracking the linguist pr. Not actionable from our end (except, of course, to make a bunch of new zig projects 😁)

[kristate]

@jfo Thanks for the fast reply. Looking forward to writing more projects!

Kind of hard to gain popularity on languages that are hard to parse in the interface.

[andrewrk]

I just ran their popularity checker and it seems we have something like 72 zig repositories on GitHub and they require "hundreds". So presumably we are at 37% of the necessary popularity.

Status

• June 04, 2018
  
  
  
  • 72 / 200 (37%)
  
  
• June 18, 2018
  
  
  
  • 87 / 200 (44%)
  
  
• Aug 03, 2018
  
  
  
  • 96 / 200 (48%)
  
  
• Nov 04, 2018
  
  
  
  • 151 / 200 (76%)
  
  
• Nov 21, 2018
  
  
  
  • 186 / 200 (93%)
  
  

https://gist.github.com/andrewrk/33650712e74a65873dd84d82d25f449a

[numsim1415]

I just wanted to point out here that specifying rust as the highlighting language works quite well, in my opinion. Just prepend the code with ```rust

Sample:

const std = @import("std");
pub fn main() !void {
    var stdout_file = try std.io.getStdOut();
    try stdout_file.write("Hello highlight!\n");
}

[andrewrk]

Thanks @jfo! This is done, merged by GitHub staff and will be live within a month.