[JavaScript] additional keywords/builtins

[leeoniya]

• |DOMParser|Worker|Image are DOM constructors, so they probably belong elsewhere, but where?
• |location|history|localStorage|sessionStorage are in the right place
• |setInterval|clearInterval|requestAnimationFrame|cancelAnimationFrame are in the right place

cc @Thom1729 @wbond

[Thom1729]

See also #1563.

Generally, the core syntax only provides support scopes for things that are part of the language itself, rather than specific to the browser or to Node. There are a few exceptions left over from before #1641, including the DOM support variables in your screenshot (like window).

I think it's worth discussing how to maintain these moving forward. I don't think it would be a good idea to add a lot of environment-specific features, because JavaScript is used in all kinds of environments and highlighting that is appropriate for one environment might be inappropriate in another. We don't really have an articulated philosophy for environment-specific support scopes in the core syntax. The general vibe seems to be to highlight the most important and obvious items like window that would be conspicuous by their absence. I think that before we add more, we should come up with a more specific standard and proceed from there. I would welcome suggestions along these lines.

(I've been meaning for some time to get around to adding user-specified support scopes to JS Custom. This would allow users to customize these supports at a granular level. However, even if this feature were available now, that wouldn't necessarily mean that the core syntax shouldn't highlight any environment-specific scopes, because as long as those scopes are added in a modular fashion, JS Custom could remove them when not needed.)

[leeoniya]

I don't think it would be a good idea to add a lot of environment-specific features, because JavaScript is used in all kinds of environments and highlighting that is appropriate for one environment might be inappropriate in another.

while i sympathize with this sentiment, the reality is that the browser, Node and Electron probably cover 99.9999% of JS environments in practice. it feels like a disservice to simply discard anything that's env specific (while also leaving some legacy env stuff in place). when the env-specific scopes story is figured out (who knows when), then moving it all out should be uncontroversial. the fact that the majority of JavaScript files carry a .js extension makes this issue more difficult, because there's no way to discern which scopes have to be active for any particular file.

Sublime-JS-Custom looks to be more powerful than is technically necessary for this particular issue, since there's no additional parsing machinery necessary here, just some extra scope tags added based on a keyword dict, eg: nodejs, browser, electron

[Thom1729]

the reality is that the browser, Node and Electron probably cover 99.9999% of JS environments in practice

Sure, but this is three different environments. Back in the days before Node when >99% of JavaScript ran in a browser, it would have made sense to treat the browser as the de facto default environment. Nowadays, highlighting specific to any one environment is likely to be inappropriate for the substantial fraction of developers working in a different environment.

when the env-specific scopes story is figured out (who knows when)

There's no time like the present. :-) This the perfect opportunity to have a discussion about it.

moving it all out should be uncontroversial

Unfortunately, this has not historically been the case. There are dozens of lines of code in the syntax definition providing special scoping for identifiers beginning with dollar signs because of an old unofficial convention among some jQuery devs. When the special case was removed, complaints poured in, and now we're stuck with it.

[leeoniya]

There are dozens of lines of code in the syntax definition providing special scoping for identifiers beginning with dollar signs because of an old unofficial convention among some jQuery devs.

😢

so nodejs, browser, electron and jquery then?

^ i guess that's my position on this.

is it possible to expand the scope syntax in .sublime-color-scheme files to support something like CSS's :not(), eg:

{
  "name": "String",
  "scope": "string.foo:not(.definition)",
  "foreground": "#fff176",
}

something like this might allow themes to be more resilient to changes where scopes diverge and become more granular.

[wbond]

is it possible to expand the scope syntax in .sublime-color-scheme files to support something like CSS's :not()

This is how scope selectors work: https://www.sublimetext.com/docs/3/selectors.html.

[leeoniya]

@wbond thanks, that looks good.

do you guys think that prepending or appending nodejs, browser, electron and jquery to the entire scope chain would work? this sounds better than adding a multitude of more granular env-specific scopes like support.class.builtin.nodejs or support.function.nodejs.

[deathaxe]

I think especially JavaScript environments move forward too fast to keep track with all the changes and update syntax definitions. To accomblish that a fulltime developer is needed.

Furthermore the way JavaScript is abused by JSX and all the other stuff mixing it with XML/HTML/CSS etc. is nearly unmanagable and changes too quickly. Some days ago jQuery was the none-plus-ultra. A year later Angular, now ReactJS, ... . A never ending story.

I think a static syntax definition such as the sublime-syntax format should only contain special scoping for the very basic language entities provided by the core syntax itself.

Trying to add any kind of support for libraries is like a lost war.