bug#62333: 30.0.50; Issue with tree-sitter syntax tree during certain changes

[Eli Zaretskii]

> Date: Sat, 25 Mar 2023 03:51:48 +0200
> Cc: Wilhelm Kirschbaum <wkirschbaum@gmail.com>, 62333@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> 
> On 24/03/2023 09:34, Yuan Fu wrote:
>  > Well, this is a bit embarrassing, there is even a comment warning 
> this mistake, but anyway, I pushed a fix, once it gets merged into 
> master, the problem should go away.
> 
> Excellent, thanks.
> 
> > As things stands right now, every time blink-match-open blinks the matching 
> > parenthesis, tree-sitter would reparse the buffer twice, that’s not exactly 
> > ideal. Blink-match-open’s use of narrowing is legit, and we can’t just 
> > automatically widen in tree-sitter functions.
> 
> 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.