Dev Build 3087 is out now.

Several of the core syntax definitions have been updated and converted to .sublime-syntax format. One of the primary changes is that HTML no longer includes any other syntax definitions other than CSS and JS (It used to have hard coded transitions to Ruby and PHP).

Another experimental change is that Python and JavaScript will highlight over-closed brackets.

Smashing, thanks Jon, the speed up is noticeable for sure!

I have a custom SQL package with default one disabled. Now rendering Python files ends with error because Python’s syntax includes SQL syntax which comes from disabled package. Same with HTML and CSS. I think this might be a common issue when some default packages were replaced with third-party ones. Maybe instead of failing with error continue parsing with some kind of warning?

I have the same issue today with Java referring a disabled Javascript package, but I’m not sure that I have edited a Java file since I disabled Javascript package.
Is your issue has appeared in this build ?
Wonder how it worked before.

[quote=“bizoo”]I have the same issue today with Java referring a disabled Javascript package, but I’m not sure that I have edited a Java file since I disabled Javascript package.
Is your issue has appeared in this build ?[/quote]

Yes, it is. I believe the reason for your error is that syntax for Javadoc in Java package includes syntax for HTML which in turn includes the disabled JavaScript.

Simple, in the old approach you need to include a scope name and the editor will load any syntax defined for this scope. Now we need to specify the concrete file with syntax.

The new default JS def has some odd differences from the old one. The old one, while by no means thoroughly covering ES6, did recognize keywords like class, extends and static correctly. The new one marks these as invalid (and in the case of static, curiously, “deprecated”). While on one hand I kind of like this as someone who’s just written an ES6 sublime-syntax def since it means more people will search for it , I have a feeling these regressions weren’t actually intended. Even if the def only means to provide coverage of Javascript up to ES5, it probably shouldn’t be scoping these things (which, in the case of the examples listed, are already implemented in V8, Spidermonkey, and whatever the IE Edge’s JS engine is) as invalid.

The PHP syntax isn’t working properly in some cases:

But if I take off some tags:

[quote=“lastsecondsave”]

Simple, in the old approach you need to include a scope name and the editor will load any syntax defined for this scope. Now we need to specify the concrete file with syntax.[/quote]

Make sense, wonder why it was modified.
This issue can probably be considered as a bug.

Not sure I can see anything - can you provide an example when this would happen?

Also, looks like javascript inside of script tags highlighting has changed. On the left is the newer syntax

and it’s a little different than when just in a plain JavaScript file:

Then again - I think the entire JS highlighter needs to be updated for something like the JavaScript Next package or Bathos’ github.com/bathos/Ecmascript-Sublime

Awesome, that should clear many of the PHP&HTML issues (e.g. github.com/SublimeTextIssues/De … 3A+HTML%22) and the issue where ST is displaying PHP or HTML in the status bar, and I am still unsure when it does which.

For the curious, like me:

>>> sublime.find_resources("*.sublime-syntax") 'Packages/CSS/CSS.sublime-syntax', 'Packages/HTML/HTML.sublime-syntax', 'Packages/JavaScript/JavaScript.sublime-syntax', 'Packages/JavaScript/JSON.sublime-syntax', 'Packages/JavaScript/Regular Expressions (JavaScript).sublime-syntax', 'Packages/PHP/PHP.sublime-syntax', 'Packages/Python/Python.sublime-syntax', 'Packages/Python/Regular Expressions (Python).sublime-syntax', 'Packages/Rails/HTML (Rails).sublime-syntax', 'Packages/Rails/JavaScript (Rails).sublime-syntax', 'Packages/Rails/Ruby Haml.sublime-syntax', 'Packages/Rails/Ruby on Rails.sublime-syntax', 'Packages/Rails/SQL (Rails).sublime-syntax', 'Packages/Ruby/Ruby.sublime-syntax', 'Packages/SQL/SQL.sublime-syntax', 'Packages/XML/XML.sublime-syntax', 'Packages/YAML/YAML.sublime-syntax']

With the change to switch multiple packages to .sublime-syntax some users are reporting issues with JS, CSS or HTML packages that disable the corresponding default packages. The reason is that the new syntax definitions use explicit relative file references for importing while .tmLanguage uses the base scope name (which can be changed “dynamically”). Thoughts on that? github.com/SublimeTextIssues/Core/issues/855

I hope that this will be resolved completely once the default packages are opened for contributions and people can fix stuff officially instead of going the way of providing an alternative that just disables the default.

go bathos go! Thanks for the efforts!

Ugh…that will make drop in replacements impossible and require multiple language changes just to drop in a custom JS language. I haven’t upgraded yet to 3087, and probably won’t until some of this is resolved.

Hopefully, this syntax thing is just temporary, because I bet that many (WordPress) developers have pieces of php in html and everything looks a bit off…

[quote=“facelessuser”]

Ugh…that will make drop in replacements impossible and require multiple language changes just to drop in a custom JS language. I haven’t upgraded yet to 3087, and probably won’t until some of this is resolved.[/quote]

Well, the most straight forward solution is to just override the original file, which imo is also the most proper way to do this as it allows for consistend syntax def file paths outside of syntax includes (e.g. creating files with a default syntax highlighting using view.set_syntax).

This can be done currently by creating an override file from another plugin with Python code, but that requires some logic to be properly removable (only remove file on uninstallation, via PC event, if it’s the same as we placed there before) or could be prone to losing modifications if the user happened to have a modified CSS.sublime-syntax file already on his machine.

The other way would be to have a package on Package Control with the same name as a default package (which is currently not allowed due to technical and other reasons!) which can then take advantage of installed packages > shipped packages and still allow users to override. I think I’ve said this a couple times, but I hope that some day we can get proper Package Control integration into Sublime Text, so that all the shipped packages can get updates from publicly accessable and official repositories any time without having to update ST, but this will go a long way. Still, I’m looking forward to that.

Yeah, I know it can be done this way, but that is sloppy with Package Control. This is a very annoying and very involved approach to do this. I’ve done similar things like this for packages like TabsExtra, but I hate doing it. What if you want to try out a couple variations of a certain syntax. Instead of just disabling one and enabling the other, you now have to do some coding gymnastics to uninstall your override and then install the other override…ugh.

I don’t know. I personally didn’t have a problem with the way it was done before. I wonder why the change. This current change is very disruptive to the current syntax ecosystem. Maybe not for syntaxes that never include anything outside their own local package, but I imagine for any package that imports outside itself will have trouble with this.

Maybe the idea is that the default packages in the future will be so perfect that no one will need to look elsewhere, but no matter how good the default is, there will always be someone who has a quirky preference and will want to roll their own.