GNU bug report logs - #62333
30.0.50; Issue with tree-sitter syntax tree during certain changes

Previous Next

Full log

Message #44 received at 62333 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: wkirschbaum <at> gmail.com, casouri <at> gmail.com, 62333 <at> debbugs.gnu.org
Subject: Re: bug#62333: 30.0.50; Issue with tree-sitter syntax tree during
 certain changes
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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.