It seems mostly to be focused around JS, which has seen the biggest corrections in the syntax (from what I can tell). Unfortunately the color schemes aren’t tied to a specific language, and instead are shared among all different syntaxes. These colors have been used previously for many other languages, which means changing it to make JS look nice could have the effect of change the look of all other languages also.
In short, I don’t know if there is a simple “fix”.
I understand that color schemes are not language-specific and I was not advocating for changing the color schemes to solely make JS “look nice.” Rather, I’m curious as to why color schemes are viewed as being static (i.e., not being hosted on Github) while the underlying grammars are seeing so much change.
Consider the difference in wording between the following issues:
(1) “I don’t like that ‘$’ is no longer red in ST’s default Monokai theme.”
(2) “I think ‘$’ is being incorrectly scoped in the JS grammar.”
I don’t see why (1) has to imply (2). That is, to me, it seems like (1) is more of a color scheme issue than a grammar issue (assuming the scopes are indeed correct).
While you are right with your differentiation in general, this particular issue involves both color schemes and syntax definitions.
At this moment, $ does not receive any special scoping and gets the general scope variable.other.readwrite, just like any other variable in JavaScript. In comparison, console gets support.type.object.console.
I take it that the majority prefers to have special highlighting for the commonly used identifiers $ and jQuery. With that in mind, I suggest assigning the scope names variable.other.jquery to these two identifiers that color schemes can then highlight differently, if they so desire. This would be a JavaScript-specific change and more in the sense of “opt-in”.
The other way would be to highlight them as support.type.jquery (like console) or support.variable.jquery, which is way more likely to trigger different coloring of these identifiers in almost all color schemes and would require opting-out in order to not receive special highlighting.
It has to be debated which of these third-party identifiers should be marked as such and which should not. JavaScript (or ECMAScript) is often used as a plugin language, for example, or within Node.js, where things are different.
Custom identifiers starting with a dollar sign (e.g. $this) should at most receive a special scope in the sense of variable.other.readwrite.jquery and thus opt-in, since they are … well, custom.
I’d prefer to see the JS syntax extended to a new syntax (such as jQuery.sublime-syntax, lodash.sublime-syntax, node.sublime-syntax, etc…) to include those special identifiers. I just like having my $ the same color and not giving one library hidden support which could start requests for more frameworks or libs. Would be nice to set the stage of extending it to provide more scope variants for libs than PRs to inject more scopes into the core syntax.
The fact that color schemes can make language specific exceptions is exactly the problem though. The default JavaScript syntax package used to be pretty useless, but because so many people write JS color schemes have been adjusted to make the most of it. Now that the syntax package is actually pretty good, the colors have changed. There is no way to prevent that from happening and we just have to move through this to move forward.
The only way forward is for color schemes to catch up. The new syntaxes are better, richer and more consistent. They’re only just out in public for a reason days, give it some time to settle. It will improve.
As someone who put some serious time in a color scheme (Solarized) I can only say that the quality of the syntaxes was pretty lame before the move to open source them. I understand the end user only sees the colors and doesn’t want them to change, but I can only applaud the move forward.
@braver: I’m not sure how that is relevant to what I said above but I agree with you, for what it’s worth.
Essentially I was trying to say that, from my perspective, it seems like a “regression” in terms of highlighting color can actually be indicative of a grammar improvement. (I only re-state that because it seems like people thought I was saying the opposite…)
I didn’t read this whole thread - but the JS highlighter is much better. Yes its different, but its much better for both ES5 and coming ES6 code that you will write.
So just get used to it - I’ve been using it for well over 2 years now.
Oh definitely. I also don’t disagree with your post. I just meant to quote your first line though, so that’s why the reply.
Anyway, this thread is something I’ve seen at Atom, and when working on Solarized: people don’t like it when you change their theme. Completely understandable, you just have to explain what happened and kinda “weather the storm” in a way.
For those of us looking for that previous syntax highlighting, I’ve discovered that the “Better Javascript” package does exactly what I need. Object.keys are white, ‘strings’ are yellow, = and $ are red.
https://packagecontrol.io/packages/Better%20JavaScript
Almost had to rollback to 3083 because the colour changes in JS were screwing with my head. As @lopac1029 mentioned the Better Javascript package changed them back so all good for now…
Sorry to be that harsh, but did ANYBODY test the new JS syntax colors with anything but jQuery, like an AMD based framework? There almost everything is an object key, so my whole JS code suddenly turns yellow… This is really awkward. Thanks for the alternative package @lopac1029.
I use require, backbone+marionette and yup, everything is weirdly yellow. Like EVERYTHING…
A view for example: Methods are yellow, properties are yellow… And why the hell basecheckoutview is green in events (green is for methods with function as value, normally) but not anywhere else (like at .extend() ?
Again, properties are all yellow…
i18n file: Variables are white with the strings being yellow (correct), but then all properties are yellow (wtf?)
Rolling back
Unfortunately there are quite a number of threads about the JS scope changes, so it isn’t easy to keep everyone updated.
In short, I am currently working on merging enhancements from https://github.com/sublimehq/Packages/pull/96 and making the changes discussed at https://github.com/sublimehq/Packages/issues/141#issuecomment-182826789.
It’s also worth saying that Sublime only tells your theme what things are - are strings, methods, functions, numbers, booleans, block etc?
Then your theme tells sublime what color to make them. It might be worth trying a few other themes.
Yours is weird just like we said. expando and isReady shouldn’t be green (string), had to be yellow like noop, isFunction, etc.
@wbond
Thanks for the update 
I’ve committed tweaks to the JS syntax via https://github.com/sublimehq/Packages/commit/10073d7f7d559514c9a48230ba6b9986ed4687fa.
Additionally, there are a bunch of fixes from https://github.com/sublimehq/Packages/pull/96.
These will be part of the next dev build.
About that, do you think that Packages would be shipped separately from Build in a near future?
It feel strange to have to wait for a build when official Packages change but not when other Packages change…
I also wish you update the beta build as soon as the most crucial syntax coloring stuff has been fixed and tested. Thanks for keeping the community updated on the issue!