Just submitted my Package Control pull req. Provided I did that correctly, it should be available via Package Control in the next few days. However you can always just clone github.com/bathos/Ecmascript-Sublime to your package folder and use it now.

Ecmascript Syntax is a very thorough ES6 syntax definition, making use of the new sublime-syntax format instead of tmLanguage, which allows it to match things very precisely, for example:

• in operator vs in keyword
• {} object literal, {} block statement, {} binding pattern, and {} namespace import
• * operator, * generator keyword, * namespace import, * yield iterable keyword
• (etc)

It’s also extraordinarily specific about scopes, so that theme designers can decide, for example, that they want try block braces colored differently from loop block braces or switch braces, etc. All of ES6, as well as a number of ES7 strawmen like decorators, async functions, etc are supported. The readme at the previous link goes into (much) greater detail and there’s also information there which may be useful to other people trying to write sublime-syntax definitions.

Although I still have a fair amount to do to polish it up – right now there’s only a single real theme bundled with it – I’ve been using it as my sole JS syntax def for over a week and I haven’t found any new bugs in a while, so I figured it was time to release it.

The first theme, Excelsior, is a bit gaudy as it aims to demonstrate more of the possible coloring than is probably wise; but on the other hand, it’s actually come into its own a bit as I kept at it. Hopefully more talented themers will have a go at it – if they do, I would be happy to include their efforts in the package.

Note that sublime-syntax, and therefore the Ecmascript Syntax package, is currently only supported in versions >= 3084, which are still dev-channel specific.

Thanks for this! Amazing I just want to say thanks and report a little weird thing, the following code has some portions marked as invalid:

    for (var i = 1, l = this.points.length; i < l; i++) {
    }

That kind of error also repeats in other places where a second coma is used

			ctx.beginPath()
			ctx.clearRect(0, 0, scr.width, scr.height);

Thanks! The second one looks like a regression I just introduced last night by mistake, and is obviously pretty major! The first is more surprising though and I’ll have to investigate further. Good catches. I should have fixes for these up tonight.

EDIT: I’ve figured out the first. It’s great actually, such a great find on your part because this could easily have slipped by for weeks without anybody noticing. It failed to work correctly because the lookaheads that determine what kind of loop it is – so that we can correctly distingush “in” operator from “in” keyword – were not confirming word boundaries on “in”. Thus “points” made it illegal!

EDIT: Both are now fixed and live. Not sure how long it takes Package Control to discover new versions but it’s up.

Hi Bathos, thanks a lot --_–

Two things, this is very minor but I consider it important, would be possible to correct the case of all instance of ECMAScript and JavaScript? Ecmascript => ECMAScript, Javascript => JavaScript

For some reason in JSON files the “:” is marked as invalid, for example:
{
“a”:
“b”}

Thanks!

The reason JSON files do that is because this definition doesn’t include JSON

One would naturally think, “but that’s just an object literal”. As JS, though, what you just pasted is:

{ <-- the start of a block statement
“a” <-- a string literal, as part of an expression statement
“:” <-- an invalid token

I could add a JSON def if you think it would be useful though. The reason I didn’t bother is because I figured I didn’t have anything to offer that wasn’t in the existing JSON def. But on the other hand, if I did do a JSON def, I could do it in such a way that it uses the same scopes as regular object literals, which makes sense for consistent coloring.

As for the case, that doesn’t seem like it has anything to do with utility or functionality of the definition. Personally, I really dislike kowtowing to idiosyncratic “official” casing in natural language. A word can be a proper noun, or it can be an acronym, but as far as I’m concerned, being both is an eyesore, trademarks and corporate styling edicts be damned. When I have the option, I prefer to write in English, not advertising But I realize this places me in a minority. If you really find it’s somehow affecting the experience for you, I could change how the name appears in the menu (though the readme and comments I’d really prefer to leave in peace).

In my opinion I think would be nice to add JSON for consistency. As for the case, is not about writing ads, but just capitalising “correctly” it does not look nice to my eyes they way is now, just that, I feel as if you were typing my name in lowercase.

Another way to see the problem with the capitalization: even if your package is in english your wider audience is pretty international, from all around the world, many countries and languages involved, I think is better to give everyone a nice international ““standardized”” “picture” of the things provided. (this apply to all sort of things to me). But hey… In any case(lol) this will not opaque your great work! (thank you very much)

Yep, I understand how you feel about observing official styling; you’re in the majority in considering styling edicts from authors and bodies to be correct. There was a time when my take wouldn’t have seemed particularly silly (and not only within English), but it’s long gone (with a few exceptions – for example, most style guides still suggest not to observe branded styles that are entirely lowercase, since that goes too far even for the sorts of editors who normally trip over themselves to obey these sorts of things).

In any case, there’s no need to convince me there’s such a thing as correct, or what it might be: I’m already willing to make the change. (On the condition that you remember me in 40 years when someone tells you that you’ve spelled Google wrong because the letters aren’t colored )

Changing the syntax name as it appears in the list should be simple. I’m not sure if there’s any reasonable means to change the name as it appears in Package Control though. AFAICT, the plugins are identified uniquely only by name, and I don’t want to cause clutter or break updating for people who have already installed it. If you can turn up a means to adjust that on Package Control without causing other problems I’ll switch the casing there, too. Perhaps it’s case insensitive? If so, that will be easy, too.

I have a few small updates pending but I probably won’t post a new version proper until I have a good handful more. JSON will be among those things.

Dianaazura, it looks like you were trying to quote one of the posts above but maybe accidentally replaced your own post in the process? Or are you just seconding the desire for including a JSON syntax def in the package?