add syntax highlighting for Vala

[eyelash]

As I needed to convert the .tmLanguage to .sublime-syntax I added the file directly instead of using a submodule.

closes #67

[trishume]

Hmmm, I think I agree with this in principle, I'm just wondering if I want to go even further. Lots of people want highlighting for languages like Typescript that aren't part of the default package set. Projects like https://github.com/Keats/gutenberg maintain their own set of dumps for this.

I'm not sure if I want to:

• Add a bunch of third party syntaxes to the default dump.
• Add an option for an "extended" default dump that's the Sublime packages plus a bunch of common third party syntaxes.

I'm pretty busy for the next week so I'm not sure I'll get around to doing anything about this personally soon. Let me know if you really would like fast action on this, but I don't want to add Vala to the default dump and then make a non-compatible move of it from the default dump to an extended one.

cc @Keats

[eyelash]

No need to hurry. While working on this I noticed that quite a few other languages are missing as well, e.g. Swift. I believe there are use cases (such as a static site generator) where you really want to support as many languages as possible but also for a text editor like Xi I would actually prefer the syntaxes not to be compiled into the binary but instead be loaded from disk only when they are needed. I am also not sure how useful a default dump that only includes a few languages actually is.

Here is a nice list of the syntaxes that is used to highlight code on GitHub BTW.

[Keats]

I think the basic default dump (for theme and syntaxes) is fine as an example and to get things working after adding it to Cargo.toml but pretty much every application I can think of will want to extend one or both dumps.
Maybe keep the dumps as-is, add a section on the README explaining how to create your own dumps/load from file and call it a day?

[robinst]

I'm not sure about adding additional syntaxes to syntect itself.

Ideally, they would live in https://github.com/sublimehq/Packages/ directly, but I get the impression that @wbond seems to be opposed to that? @wbond, maybe you would be open to the idea of putting it in a separate directory tree, something like extra and have a CODEOWNERS file that will assign interested people as reviewers.

And if we can't do that, we should probably have a separate repository because this might be useful for other things than syntect itself and might be nice as a kind of "staging" area for Packages itself.

[wbond]

@robinst Effectively https://packagecontrol.io/ is where extra .sublime-syntax files live. Obviously there is a lot more than syntaxes there, but I don't foresee Jon (or myself) wanting to try and centralize other syntaxes, just due to impact on our workload and workflow changes to introduce non-employees to company repos.

[vors]

Hello! I like the original @eyelash 's suggestion about leveraging https://github.com/github/linguist/tree/master/vendor/grammars : this list is much broader than the https://github.com/sublimehq/Packages/ . It was created for exactly the same purpose and is already moderated by GitHub folks. It also resolves the situations when there is more than 1 tmLanguage in the ST package control.

[trishume]

If someone's willing to do the work to automatically convert all those tmBundles to sublime-syntaxes and add a cargo feature to bundle the extra syntaxes, I'm probably willing to accept that. Might need to set up Git LFS for the packdumps for that so they don't bloat the Git repo too much, but that's fine.

I'm totally okay with some curation though, especially since we can use sublime-synaxes I bet there are some higher quality syntaxes for certain languages than the ones Github uses.

[HarrisonMc555]

Has there been any progress in this front? I've been using bat and was wondering why it wasn't automatically detecting awk files by their shebang (but could detect other kinds of files by their shebang lines).

I would be willing to add the missing regex, but I don't know how to add anything to the packdump...

[Enselic]

The current consensus is that no additional language will be added to the set of languages supported natively by the syntect librarly. Clients have to make the necessary arrangesments themselves. So I'm closing this PR now.

That said, there is interest among several projects to share a common set of syntax definitions, see #168