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

From: Dmitry Gutov <[email-masked]>
Date: Sat, 25 Mar 2023 15:00:24 +0200

On 25/03/2023 14:34, Eli Zaretskii wrote:
>> 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.

Performance: to avoid scanning for the matching paren too far in the buffer.

Which might seem like not that big a deal, or could even be handled in a 
special way here using the parse tree, but narrowing has been used for 
this purpose for a long time (to limit various kinds of searches or 
movements), so fundamentally the problem will still be with us.