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

[Yuan Fu]

> On Mar 25, 2023, at 4:29 PM, Dmitry Gutov <dgutov@yandex.ru> wrote:
> 
> On 25/03/2023 21:31, Yuan Fu wrote:
>> 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?
> 
> Yes.
> 
>> But I don’t have any good idea for blink-matching right now.
> 
> show-paren-mode has show-paren-data-function (which treesit should also plug 
> into, I think).
> 
> Since we're looking for ad-hoc solutions, we could add a similar extension 
> point for blink-matching-paren.
> 
> Or even try to reuse show-paren-data-function: just specialize in a limited 
> number of cases - check that (nth 1 data) matches point, and then take the 
> elements 3,4 and perform the existing checks on them. There might be some 
> differences in behavior, but probably nothing some checks using 
> 'syntax-after' couldn't handle.

Sounds good, I can work on this. This links to something I’ve been working on, 
namely some system that allows one to map abstract general constructs like 
pair, list, defun, assignment, etc, to grammar-specific definitions like a 
tree-sitter node type, and automatically construct functions accessing those 
information. We already have a primitive version of it: right now if you set 
treesit-defun-type-regexp, treesit-beginning/end-of-defun and 
treesit-defun-at-point would just work. I want to extend it further to allow 
you to get defun name, argument list, etc, and everything else I mentioned 
earlier.

If we can pull it off, a user only need to specify what is a pair and how to 
find the matching pair according to the language grammar, and the rest is 
automatic (a tree-sitter function for show-paren-data-function and 
blink-matching-paren).

Yuan