Re: Local treesit parsers with disjoint ranges

> On Jul 14, 2026, at 2:24 AM, Arsen Arsenović <[email protected]> wrote:
> 
> Yuan Fu <[email protected]> writes:
> 
>>> Same embed level seems like it shouldn't be the case, but I suspect
>>> because we have to jump back to the host parser to handle the Astro
>>> expression that it parsed within the interpolation, the embed level is
>>> always 1, no matter how deep the nesting is, because any embedded
>>> Typescript parser will always be created as a direct descendent of the
>>> host Astro parser. So I agree that yeah, the parser is doing a bit of a
>>> hack here that makes it tricky to use. I guess the question now is
>>> whether we want to handle this case in treesit.el, or if we consider it
>>> a parser issue?
>> 
>> Ah, I see the problem. Yeah, the embed parser code is designed for parser
>> embedding another parser, which embeds another parser. But here we want the
>> same parser to create different levels of embedded parser. I need to think
>> about whether we can support this kind of paradigm.
> 
> Hm, but isn't the situation here already solvable by what exists today
> (at least since the addition of complex ranges for local parsers) in a
> way I described in my other message[1]?

No, because in Ruby’s case, he needs to create multiple parsers that are overlapping but on the same embed level. They shouldn’t be at the same embed level, but because how the grammar works, they are, and that causes the problem: when you have a existing local parser over a range, and you ask Emacs to create a local parser at the same embed level with an overlapping range, Emacs reuses that local parser.

Yuan