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

From: Yuan Fu <[email-masked]>
Date: Sun, 26 Mar 2023 15:57:55 -0700

> On Mar 25, 2023, at 9:28 PM, Eli Zaretskii <[email-masked]> wrote:
> 
>> From: Yuan Fu <[email-masked]>
>> Date: Sat, 25 Mar 2023 12:31:58 -0700
>> Cc: Dmitry Gutov <[email-masked]>,
>> Wilhelm Kirschbaum <[email-masked]>,
>> [email-masked]
>> 
>> 
>> I don’t think we should blindly widen in tree-sitter sexp functions, but not because of mmm-mode—tree-sitter ranges should have that mostly covered. My primary concern is that what if narrowing is intended by the caller?
> 
> What could be the reason for the caller to narrow when calling a
> sexp-movement function?  Keep in mind that the only narrowing that
> matters is one that prevents the sexp-movement function to find the
> target of the movement.

Maybe the user narrowed to a defun when writing code. There is a bug report on narrow-to-defun not working right in c-ts-mode, so there are definitely people who work like that.

>> But I don’t have any good idea for blink-matching right now.
> 
> We could leave this alone for now, but in that case let's at least add
> some FIXME comment in the relevant place(s), so that we could later
> revisit this.

Dmitry’s idea sounds good, we can add a tree-sitter backend for show-paren-data-function, and make the backend for blink-matching-paren configurable, then add a backend for it that uses show-paren-data-function, which in turn uses tree-sitter (or we add a backend that uses tree-sitter directly). In either case, the tree-sitter backend don’t need to use narrowing and we are good.

Yuan