search

bathos / Ecmascript-Sublime

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

Switch to new `embed` feature once 3153 is stable #50

Closed blake-regalia closed 6 years ago

blake-regalia commented 6 years ago

The embed feature allows nesting syntaxes by naming their scope rather than their syntax definition file. It also overcomes bugs introduced by sub-syntaxes eating up the escape tokens by allowing a specified regex to always supersede the sub-syntax's context rules.

https://forum.sublimetext.com/t/dev-build-3153/33014/8

blake-regalia commented 6 years ago

I just successfully implemented this, but unfortunately the embed feature is not as great as I'd hoped. The issue is that we want to interpolate strings inside of nested syntaxes, but every time there is an interpolation with embed, the only option is to completely pop out of the nested syntax which causes it to lose the current context. So once the interpolation ends and we're back in the string again, the nested syntax starts over at the root context and usually thinks everything after that is invalid. Here's an example:

screen shot 2018-05-09 at 12 28 23 am

Notice how everything goes to crap after the interpolation ends. The way we are currently doing it with set works because we can push a new Ecmascript context when we encounter the interpolation token under with_prototype (which only works with set/push). If embed also allowed with_prototype, then this wouldn't be an issue :(

51

bathos commented 6 years ago

I’m not sure there’s any way around this — even if the nested context could be retained after leaving the interpolated sequence, it could easily be invalid on account of whatever got "black boxed" by the interpolation. That is, if I have a grammar that expects X Y Z, but considers X Z unintelligible, and the interpolation is like X ${ 'Y' } Z, there would be no recovery regardless of context.

I ran into this when I did the StyledJSX stuff: the built-in CSS syntax definition freaked out every time a property value was interpolated. To deal with it I ended up implementing a light, purely (or nearly purely) lexical grammar for CSS within ES Sublime:

https://github.com/bathos/Ecmascript-Sublime/blob/master/ecmascript.sublime-syntax#L5379-L5480

This approach happened to work well with CSS because it’s easy to reduce to small lexical constructs and its structure has little impact on producing good highlighting. It likely wouldn’t be as effective with most languages, which would end up loosing detail/correctness in more noticeable ways.

blake-regalia commented 6 years ago

'Fixed' in 646e0e4