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

[Yuan Fu]

> On Mar 31, 2023, at 10:47 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Yuan Fu <casouri@gmail.com>
>> Date: Fri, 31 Mar 2023 11:43:49 -0700
>> Cc: Eli Zaretskii <eliz@gnu.org>,
>> Wilhelm Kirschbaum <wkirschbaum@gmail.com>,
>> Gregory Heytings <gregory@heytings.org>,
>> 62333@debbugs.gnu.org
>> 
>> I think the distinction lies between “I want to narrow to this defun and 
>> work on it without distraction” vs “treat this region as an isolated 
>> buffer”. The former used by users, the latter used by lisp programs like 
>> Info and mmm-mode. The former still considers the visible region part of the 
>> whole buffer, just temporarily narrowed for convenience, the latter wants to 
>> make everything thinks the visible region _is_ the whole buffer.
> 
> Users can do both, for whatever reasons.

Yeah, but it might be beneficial for lisp programs to be able to distinguish 
between the two types of narrowing, and act differently.

>> It might be good for tree-sitter or other parsers to be exempt from (but 
>> still acknowledges) the first kind of narrowing. This way the parser can 
>> avoid unnecessary re-parse, and always provide the optimal information. We 
>> just need to modify tree-sitter functions to check for this narrowing and 
>> don’t return anything beyond the boundaries. It’s probably going to be a lot 
>> of hair, but should be doable, I think?
> 
> I don't see why it would be a lot of hair.  If a parser always has the
> regions on which it is supposed to work, then a Lisp program using a
> parser can simply widen the buffer when it needs to be sure a
> narrowing doesn't get in the way.

Yes, the current situation is straightforward. I’m just saying that supporting 
what I described would require some work (let tree-sitter be able to peek 
outside the visible region but still pretend to respect narrowing).

Yuan