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

[Yuan Fu <casouri@gmail.com>]

> 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