Conversation
In many cases (including any time an embed block's end delimiter was not on its own line), the highlighting from an embedded grammar was breaking out of its embed block because it was not configured to properly detect the embed block's end. The root cause is that TextMate only tests the `end` of the rule when it is not currently inside another highlighting rule, so injected grammars with open multi-line constructs (a JS comment, for instance, or Markdown's indented-code or paragraph rule), were never tested against our `end` pattern. Fix this by wrapping each injected grammar in a `while` rule expressing "this line holds no end-delimiter". The engine re-tests `while` conditions at the start of each line, so we never miss being consulted. Note that we modified the generator to write a rule per embed delimiter since the `while` condition has no way to know which embed delimiter opened its block. The one very minor tradeoff here is that due to the limitations of TextMate's line-by-line testing, the last line of an embed block which does not have a newline before its embed-end goes unhighlighted by the injected grammar. I call this tradeoff "very minor" because the formatter always puts the embed end delimiter on its own line (lined up with the block's minimum indent), so this will be rare in practice.
`generate-tm-embed-block.ts` now writes a correct and typo-free reference back to itself in its generated content.
joeslice
approved these changes
Sep 16, 2026
joeslice
left a comment
joeslice
left a comment
Contributor
There was a problem hiding this comment.
Approved:
Nice simplifications in this one.
| : lang.contentName; | ||
|
|
||
| // Build the patterns array | ||
| const noEndDelimiterOnLine = `(^|\\G)(?!.*${endDelimiterPattern})`; |
Contributor
There was a problem hiding this comment.
Wow, reading about \G sent me down a fun TextMate rabbit hole.
| // that ends the tag. The lookahead is non-capturing so `end` can backreference \1. | ||
| begin: `(%|\\$)[ \\t\\r]*${langPattern}${isGeneric ? '' : '(?=[ \\t\\r]|$)'}(:|.|\\s)*?$`, | ||
| // that ends the tag. | ||
| begin: `(${delimiterPattern})[ \\t\\r]*${langPattern}${isGeneric ? '' : '(?=[ \\t\\r]|$)'}.*?$`, |
Contributor
There was a problem hiding this comment.
I guess these capture groups aren't really necessary, but doesn't seem to hurt. Especially if we later want to use them.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
In many cases (including any time an embed block's end delimiter was not on its own line), the highlighting from an embedded grammar was breaking out of its embed block because it was not configured to properly detect the embed block's end.
The root cause is that TextMate only tests the
endof the rule when it is not currently inside another highlighting rule, so injected grammars with open multi-line constructs (a JS comment, for instance, or Markdown's indented-code or paragraph rule), were never tested against ourendpattern.Fix this by wrapping each injected grammar in a
whilerule expressing "this line holds no end-delimiter". The engine re-testswhileconditions at the start of each line, so we never miss being consulted.Note that we modified the generator to write a rule per embed delimiter since the
whilecondition has no way to know which embed delimiter opened its block.The one very minor tradeoff here is that due to the limitations of TextMate's line-by-line testing, the last line of an embed block which does not have a newline before its embed-end goes unhighlighted by the injected grammar. I call this tradeoff "very minor" because the formatter always puts the embed end delimiter on its own line (lined up with the block's minimum indent), so this will be rare in practice.