search

bathos / Ecmascript-Sublime

ECMAScript/JavaScript syntax (ES2015-ES2018, JSX, template highlighting, etc) with absurdly specific scopes
88 stars 8 forks source link

Add DOM support for built-in color schemes #84

Closed ltbits closed 4 years ago

ltbits commented 4 years ago

Standard JavaScript syntax that comes with SublimeText has pretty decent DOM support and to my surprise this package, though very good in other areas, has very limited support of it, if any at all. This appears to be an issue with the package not properly supporting built-in SublimeText color schemes (Monokai, Mariana, etc.)

bathos commented 4 years ago

It’s intentional that platform API names aren’t scoped. Some of them used to be.

Assuming we’re just looking at globals, for a regular window env, there are over 800 named global platform objects / instances, not counting intrinsics. The specific set changes depending on [SecureContext], being in different types of workers, etc. New items are added very frequently.

One can choose an arbitrary subset, like other JS scopers do, but this is pretty chaotic in practice. If one is writing for an env where those names exist, some platform object names will be highlighted and some won’t be, which makes it into just noise. The other problem occurs when you’re not writing for such an env, or a name is just shadowed. Many of the names of platform APIs are common in other contexts. For example, three I used to run into a lot being misidentified as builtins were history, location, document in non-platform contexts.

I’m not opposed to changing how we approach this if @blake-regalia feels differently, but from my POV this is sorta a bug in other syntax defs that this one fixes.

blake-regalia commented 4 years ago

@coloraggio : DOM globals are not part of the language. The same goes for node.js globals. If we assume too much about the user's environment, it can end up getting in their way as @bathos put it and cause annoying/misleading/unwanted syntax highlighting for those identifiers. I see the value in highlighting globals, but the browser is not the only environment this language is commonly used in (see here) and without knowing the environment, we would end up polluting the id space. However, we are open to user feedback and will take suggestions into consideration, so thank you for the comment!

This appears to be an issue with the package not properly supporting built-in SublimeText color schemes (Monokai, Mariana, etc.)

Just to clarify, this package ships its own color schemes because it creates 'ultra high-definition' scopes for your code that go far beyond the default color schemes available in ST3. Using Monokai with this package would be like watching a technicolor movie through goggles that make you color blind.

ltbits commented 4 years ago

Sorry for a late reply @blake-regalia @bathos. During this pandemic, I abandoned my 10y interpreted language writing career and moved to modern compiled ones recently for my own peace of mind, so above isn't an issue for me anymore and can be closed. Thanks for the package, still on my ST3 when I need to write js here and there.

bathos commented 4 years ago

np. It’s a good issue to have on file for others to discover if they’re looking for the same thing. Good luck with the new trajectory (but don’t leave us hangin! — which language(s)?)

ltbits commented 4 years ago

Thanks! mostly use go for apis and backends atm, also toying with rust a little and trying to not dislike bloated swift as I want to generate some income with ios/macos development in near future.