Dev Build 3084 is out now, with support for an additional syntax definition format, .sublime-syntax. Details at sublimetext.com/docs/3/syntax.html and Syntax Fun.
There are some menu items under Tools to either create a new .sublime-syntax file with a basic example, or create a new one using the tmLanguage file that’s being used for the current file as a basis. When converting files, you may want to take a look in the console for any warnings, which would indicate unsupported functionality.
A quick summary of the benefits of sublime-syntax files:
- Ability to switch the context at the top of the stack, rather than just push/pop. Can also push multiple contexts on the stack at once, giving the ability to recognise any LL(1) grammar.
- Easier to edit: compact YAML representation, and the prototype context can be used to reduce repetitious includes of things such as comments.
- More robust inclusion of other syntax definitions. The tmLanguage format allows including another syntax definition (e.g., HTML including JavaScript), but isn’t well behaved in the face of syntax errors in the included code (e.g., see what happens if you have an unclosed string in embedded JavaScript). This is because any patterns modifying the included syntax (e.g., popping a context when is encountered) are only added to the root context. Using the with_prototype construct in sublime-syntax files, this issue can be avoided.
The plan in the near future is to update the existing tmLanguage files, convert them to sublime-syntax ones, and then put them on GitHub to accept patches. The primary reason the syntax testing functionality is in this build is to enable this.
The sublime-syntax is not set in stone, and may be changing over the next few builds.