Remove support for .sublime-syntax

[pchaigno]

This pull request removes support for .sublime-syntax grammar files in convert-grammars until we find a better solution.

[arfon]

👍 thanks.

[codecat]

Hey! Hard to find a bit more information about this - does linguist support sublime-syntax yet, or will it ever in the future?

I wrote a new grammar in that format for a Sublime Text package I maintain, and am wondering if I should just make a new repository & package and leave the old grammar package in-place, to keep the current package compatible with Linguist.

The latest comment I can find on the matter is this one: #4157 (comment)

[lildude]

does linguist support sublime-syntax yet, or will it ever in the future?

No, Linguist doesn't support sublime-syntax grammars and it's not likely to in the future either.

[ratijas]

Hi, I understand that Sublime Text syntax is no longer supported. But there is not nearly enough information on why? What does it mean "until we find a better solution" — Is anyone actively looking for it (I bet not)? Why are you saying that "it's not likely to in the future either"? What can I do as a contributor?

[lildude]

Hi, I understand that Sublime Text syntax is no longer supported. But there is not nearly enough information on why?

Support for .sublime-syntax was removed because it stopped being compatible with TextMate and keeping the "compiler" working with it was proving to be very troublesome.

As for why, the syntax highlighting engine expects the grammars to be in JSON which is converted from the various TextMate-compatible formats when the grammar is "compiled" for each release.

What does it mean "until we find a better solution"

It means until someone updates the grammar "compiler" to be able to handle this different format and all the Sublime grammar features and convert it to our required JSON format.

Is anyone actively looking for it (I bet not)?

You bet right... no one is looking at this, no money for your bet though 😆

Why are you saying that "it's not likely to in the future either"?

Because no one is working on it and there isn't sufficient demand to dedicate time and resources to it. I think most people aim for VSCode compatibility first (which is TextMate compatible) and then consider Sublime Text later. Another thing to keep in mind is GitHub is very very slowly moving away from the TextMate compatible grammars in favour of TreeSitter grammars. There isn't a formal method for adding a Treesitter grammar yet. See #6073 for more details.

What can I do as a contributor?

If you really want to, you can take a stab at updating the current compiler to support the newer .sublime-syntax format and all it's features which aren't compatible with TextMate.

Warning: it's written in Go, is very basic, makes lots of assumptions, and has no tests 😁

[ratijas]

Thanks for the info.

Seems strange to me that there is low demand, since Sublime Text ecosystem provides quite some good-quality syntax definitions. And IIRC some ambiguous grammars are not possible to represent with the simpler TextMate rules (e.g. in QML we have this weird right-hand side of bindings that can be either an Object {} or a [List {}, OfObjects {}] or a regular javaScript().expression — good luck telling an obj list from a js array expression apart). I'm not a user of VS Code, but I've heard QML situation is quite underwhelming there — probably was built on top of the old QML.tmLanguage: just operators and homogeneous keywords in one huge list of |-separated matches.

If you really want to, you can take a stab at updating the current compiler to support the newer .sublime-syntax format and all it's features which aren't compatible with TextMate.

Warning: it's written in Go, is very basic, makes lots of assumptions, and has no tests 😁

Yeah, that's unlikely to happen soon. There are little-to-no comments, and I'm having hard times trying to understand what is it even compiling into 😅

Another thing to keep in mind is GitHub is very very slowly moving away from the TextMate compatible grammars in favour of TreeSitter grammars. There isn't a formal method for adding a Treesitter grammar yet. See #6073 for more details.

Good to know. I've heard of some attempts to implement a tree sitter grammar for QML within KDE community, and apparently there is also this 3rd party project on GitHub: yuja/tree-sitter-qmljs. I should probably audit them. Just briefly skimming through the commit history, I've already found a missing feature in my plugin, and quickly implemented it via SublimeText/QML#25