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.