Sublime Forum

**zizzo** · February 9, 2016, 6:28pm

Just updated to 3103 before rolling back due to the changes in the js syntax highlighting. Just wondering if they were intentional, and perhaps how to change the back to how they were in 3083. Some screenshots for reference:

3083 (Before): http://i.imgur.com/OSJhaPx.png

3103 (After): http://i.imgur.com/JeFNaV0.png

The differences are fairly obvious but to point a few out:

$ losing red color
object name itself turning string color
object key without quotes is colored yellow like string instead of white
. between an object and it’s prop/value turning red instead of white
commas separating parameters turns white instead of orange
console now blue

The last three I actually don’t mind but the first 3 seem erroneous

Sorry if this has been addressed or I’m missing something here

**kaan** · February 9, 2016, 7:04pm

++

Rolling back as it’s a pretty breaking change, my mind can’t handle sudden color changes (actually trying to roll back)

**austenpayan** · February 9, 2016, 7:39pm

+1 Yeah its very different. Throwing me off quite a bit

**wbond** · February 9, 2016, 7:40pm

If you could, please post some examples of broken syntax at https://github.com/sublimehq/Packages/issues. That way we can get it fixed up.

Please include the code in addition to the screenshot so that we don’t have to re-type it!

**subhaze** · February 9, 2016, 7:49pm

For what it’s worth, that should’ve never been colored to begin with…

**zizzo** · February 9, 2016, 8:16pm

I quite like the coloring, useful when saving jQuery elements as variables and denoting them from others.

**zizzo** · February 9, 2016, 8:16pm

Will do, however, the code I posted was simply some personal code from a project, not anything sublime related. Was mostly to illustrate the differences.

**wbond** · February 9, 2016, 8:22pm

Based on some digging in https://github.com/sublimehq/Packages/issues/141, I’m not sure much of anything is broken. I realize the colors are different, but believe the old syntax had a number of issues that are fixed, and more consistent in the new version. See the example PHP I posted.

**zizzo** · February 9, 2016, 8:24pm

I made a comment on the Github issue as well, sorry if it’s getting confusing bouncing back and forth.

Agreed, I only meant to point out the differences, not classify them all as bugs/broken. The main one seems to be the string (yellow) coloring on nested objects. And the $ color change was understandable, I can resolve that by supplementing the syntax highlighting myself. I quite like the other changes (console, periods as red, etc).

**kaan** · February 9, 2016, 8:38pm

I’m just wondering how "Theme"s are going to catch up and re-normalize their highly-optimized color balances

For me the colorscheme is like a religious thing, I spend weeks looking for the best one and stick to it practically forever, currently “Afterglow” is my theme, but with 3103, It’s no longer the mellow colorscheme I’ve fell in love with

With variable colors becoming pale blue, the average color went from light orange to an ugly shade

I will stay at 3083 as long as I can and probably have to select a new colorscheme in the end, and hope for an Afterglow update in the meantime

**QED1224** · February 9, 2016, 9:00pm

Indeed. It seems like a number of the complaints about 3103 have to do with the way ST’s color schemes have handled changes to language grammars (not necessarily the grammars themselves).

I’m also curious about the decision to limit the packages on Github to those that are just “syntax-definition-focused.” Aren’t these packages inherently tied to color schemes, which are not hosted?

**wbond** · February 9, 2016, 9:06pm

What I think is most important is the scope names are as correct as they can be since they are semantic information that are used for various things throughout Sublime Text. I’ve discussed more technical details on the issue tracker at https://github.com/sublimehq/Packages/issues/141.

I just think it would be unfortunate for users to roll back to rather old versions that contain plenty of known (fixed) bugs, rather than working towards a solution that includes fixes.

Additionally, I should include a call to install the dev build (currently 3102, which is identical to 3103) to help test changes and provide feedback as we iterate.

**wbond** · February 9, 2016, 9:10pm

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”.

**QED1224** · February 9, 2016, 9:35pm

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).

**FichteFoll** · February 9, 2016, 9:52pm

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.

**subhaze** · February 9, 2016, 10:02pm

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.

**braver** · February 9, 2016, 10:15pm

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.

**QED1224** · February 10, 2016, 12:19am

@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…)

**wesbos** · February 10, 2016, 2:07am

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.

**braver** · February 10, 2016, 8:21am

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.

JavaScript syntax highlighting changes in 3103