Re: Local treesit parsers with disjoint ranges

Arsen Arsenović <[email protected]>
Newsgroups gmane.emacs.devel
Message-ID <[email protected]>
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]?

In short, all the permissible_text nodes that should share a parser are
parented by the same node, so if the embedding rule was to query for
that parent (seems to be html_interpolation), but have its range-fn
return a complex range covering the permissible_text children, that
should do it.

[1] https://lists.gnu.org/archive/html/emacs-devel/2026-07/msg00098.html
-- 
Arsen Arsenović
signature.asc (application/pgp-signature, 418 B)
-----BEGIN PGP SIGNATURE-----

iQECBAEWCgCqFiEE/uKz0RP8AKMWLWBhUsKUMB6ixJMFAmpWAGkbFIAAAAAABAAO
bWFudTIsMi41KzEuMTIsMiwyXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25z
Lm9wZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGRUUyQjNEMTEzRkMwMEEzMTYyRDYw
NjE1MkMyOTQzMDFFQTJDNDkzEBxhcnNlbkBhYXJzZW4ubWUACgkQUsKUMB6ixJPT
QwEA/HLmW20KKHvYvYZHIOjdDdWUfvsmddd2kVGdIPpKze0BANyhof41mbY1EZQ8
YScM/tAMydLFC6aKH02QzzIag4UM
=J8ZJ
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.