Not ideal indeed.
Aside from the performance impact, we could also see cases where the
"narrowed" parse tree contains errors (due to incomplete code) which
make the tree itself less useful. Especially when the narrowing's end is
closer to the current position than in blink-matching-open's usage.
Not sure how to solve that, but suppose we had a way to convey to
treesit.c that it shouldn't change the visibility bounds for the parser
in this particular instance? Though that would raise the issue of code
trying to use node positions beyond the current accessible range.
Exactly. Which is why I don't think this is the right way.
Is there any real reason blink-matching-open narrows the buffer? If
we could remove that narrowing, the problem with the parser's taking
notice of it would be gone.