Enable by scope, not syntax file

[idleberg]

Currently, your plugin depends on certain syntax files, otherwise it won't work. Personally, I'm using “JavaScript Next” to highlight JavaScript files. I understand I could easily add JavaScript Next.sublime-syntax to the settings, but wouldn't it be better to check the scope (e.g. if scope.startswith('source.js')) rather than for a syntax file?

[aziz]

I'd love to be able to use the scope but it's an API limitation of Sublime which is probably in place for performance reasons. I'm using the new ViewEventListener class that comes with a is_applicable class method, in which we have only access to settings of the view but not the content. If you know a better solution I'd love to implement it.

For now I've added "Javascript Next" to the list of supported syntaxes.

[braver]

It's possible to build the same functionality using the EventListener class in stead. This would give access to the view and scopes, etc., and something similar like is_applicable can be implemented to bail out of doing any heavy work early. It's quite a refactor of some elements, perhaps most importantly it's impossible to maintain compatibility with existing settings. It would be cleaner and easier to extend, so worth the effort IMO, but if I'm going to pursue this it'd be good to know if you would at all consider such a breaking PR.

[cristianl]

It would actually be a good thing to break compatibility with existing settings for v2, but I'm not sure how to (mostly) safely migrate existing installations.

Detect when user settings have been changed and notify about the v2 changes? If so, should we start notifying users in v1, before v2 is released? I remember SublimeLinter doing that in the last breaking major.

[braver]

With SublimeLinter we had a really long run time before going to v4. An enormous amount of work was done between 3 and 4. But we also have a huge number of users and settings play a central role in how you use SL, because a lot of linters need at least a little configuration. So we did the leg work of pre-announcing via package control messages and the forum. Of course, you'll never reach everyone, and we did get some backlash, but at least you can point to the communication about it.

For known languages and scopes we could try and auto-upgrade user settings... that tends to get hairy pretty quickly though. Let's just first fire up a PR and see what it looks like. Then we can always send some messages out about what we're doing and how to upgrade.