TextMate tokens for the Jinja language are not always present with languages jinja-*.
Sometimes tokens are present, but if the Jinja substitution is inside a TOML quoted string for example - no Jinja tokens, only the global Jinja language token.
Examples
Example with Jinja over TOML.
Language 'jinja', TOML value quoted
Language 'jinja-toml', TOML value quoted
Language 'jinja-toml', TOML value without quotes
Example with Jinja over shell.
Language 'jinja'
Language 'jinja-shell'
Comments
When the underlying language stops parsing the text bit, so does the jinja parser? I don't have time to collect more evidence, but it seems like a parser priority issue or something. In the real world the file will supposedly be processed like so: jinja -> underlying language. But I have no idea how VSCode works with multiple parsers. I would assume in the same order they are listed... What would it place in the Jinja substitutions then? Blanks? What if the Jinja substitution closes a quoted string for example? Highly unlikely, but possible non the less.
I don't have a good idea of how the whole multiple parsers thing should work, but since in this particular case Jinja comes first for sure, this extension should always parse for Jinja substitutions first and definitely add TextMate tokens for it before the underlying language.
Problem
TextMate tokens for the Jinja language are not always present with languages
jinja-*. Sometimes tokens are present, but if the Jinja substitution is inside a TOML quoted string for example - no Jinja tokens, only the global Jinja language token.Examples
Example with Jinja over TOML.
Language 'jinja', TOML value quoted
Language 'jinja-toml', TOML value quoted
Language 'jinja-toml', TOML value without quotes
Example with Jinja over shell.
Language 'jinja'
Language 'jinja-shell'
Comments
When the underlying language stops parsing the text bit, so does the jinja parser? I don't have time to collect more evidence, but it seems like a parser priority issue or something. In the real world the file will supposedly be processed like so: jinja -> underlying language. But I have no idea how VSCode works with multiple parsers. I would assume in the same order they are listed... What would it place in the Jinja substitutions then? Blanks? What if the Jinja substitution closes a quoted string for example? Highly unlikely, but possible non the less.
I don't have a good idea of how the whole multiple parsers thing should work, but since in this particular case Jinja comes first for sure, this extension should always parse for Jinja substitutions first and definitely add TextMate tokens for it before the underlying language.