4 ms·

Can someone explain to me how the new `embed` pattern [https://www.sublimetext.com/docs/3/syntax.html#match_patterns https://www.sublimetext.com/docs/3/syntax.h

by kmfrk 8y ago

Can someone explain to me how the new `embed` pattern [https://www.sublimetext.com/docs/3/syntax.html#match_patterns https://www.sublimetext.com/docs/3/syntax.html#match_pattern...] works compared to `push` for syntaxes with a side-by-side example? It looks like I'm supposed to use embed for syntax scopes like p-lang highlights, but the docs don't really provide a good example of how it's meant to be used.

wbond 8y ago
So embed is designed for embedding one syntax within another. Such as the script tag in HTML, or fenced code blocks in Markdown. Previously to embed another language, you would have to use a with_prototype that would prepend a pop pattern to escape the nested contexts once you reached the end marker, whether is be a close script tag or three backticks. Typically this would be a lookahead that would pop. However, when using with_prototype, you are create a complete transitive set of new contexts that all include the prepended match rules. This also means that new regex patterns have to be compiled for each of those contexts. This leads to higher memory usage, potentially in multiple places. For instance, the HTML syntax can have CSS embedded in a style tag, or a style attribute, both with different end markers. So two complete sets of the CSS syntax had to be copied into the HTML syntax. With the embed action, the escape pattern is scanned for first. Once found, the embedded context is then used to highlight the text up until the escape, at which point the syntax pops any number of contexts up to where the embedding happened. This means that we don't have to compile new contexts since the escape is matched separately before the regular matching. This, combined with optimizing our syntax definition memory layouts and de-duping our regex pattern cache is the majority of the memory savings we managed to accomplish in this dev cycle.

by kmfrk 8y ago

wbond 8y ago

So embed is designed for embedding one syntax within another. Such as the script tag in HTML, or fenced code blocks in Markdown. Previously to embed another language, you would have to use a with_prototype that would prepend a pop pattern to escape the nested contexts once you reached the end marker, whether is be a close script tag or three backticks. Typically this would be a lookahead that would pop. However, when using with_prototype, you are create a complete transitive set of new contexts that all include the prepended match rules. This also means that new regex patterns have to be compiled for each of those contexts. This leads to higher memory usage, potentially in multiple places. For instance, the HTML syntax can have CSS embedded in a style tag, or a style attribute, both with different end markers. So two complete sets of the CSS syntax had to be copied into the HTML syntax. With the embed action, the escape pattern is scanned for first. Once found, the embedded context is then used to highlight the text up until the escape, at which point the syntax pops any number of contexts up to where the embedding happened. This means that we don't have to compile new contexts since the escape is matched separately before the regular matching. This, combined with optimizing our syntax definition memory layouts and de-duping our regex pattern cache is the majority of the memory savings we managed to accomplish in this dev cycle.