Accessing syntax tree of nested language within autocomplete

1

I’m currently working on a completion context function for a nested language. I need to use the syntax tree of the nested language in order to make decisions about what to return in the autocomplete. However, I find that when I call syntaxTree(context.state), it only gives me information about the outer language and not the inner language.

I’ve put together an example to demonstrate this behavior. The example nests javascript inside of python (which is a bit horrible) inside of a fake javascript function. I am using the overlay option in parseMixed so that everything inside of the python function string is parsed by the javascript parser (I need to use the overlay option so I don’t also parse the quotes that wrap the javascript code).

If you use the example and trigger the autocomplete within the javascript portion, you can see that it logs all of the node types for the python nodes, but it doesn’t log any of the nodes for javascript–it just says String which describes the entire javascript block.

Is there a way to access the parse tree of the inner language in this context? I went looking in the docs and found MountedTree that seems related to what I’m asking about but I don’t see a clear way to make use of that class to do what I’m after.

2

syntaxTree(state).resolveInner(pos) will give you the innermost syntax tree at the given position. You can then scan up to the top node if you need to, but usually you’re interested in the nodes around the cursor anyway.

3

I was able to use resolveInner and then recursively scan up to the top node of the subtree–thank you!

I do wonder if it would make sense to have a way of getting the subtree of a specific language when working in a mixed language setup? While I see the value in being able to see the parent tree (since you may need to use that to make decisions), it wasn’t obvious that a subtree could be accessible with resolveInner (I thought that would just give me the node that was being overlaid, in this case, String). Though, I’m not sure how narrow this use case is and if it warrants an addition or not.