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

[Dmitry Gutov <dgutov@yandex.ru>]

On 25/03/2023 16:41, Eli Zaretskii wrote:
>> Date: Sat, 25 Mar 2023 16:18:12 +0200
>> Cc: wkirschbaum@gmail.com, casouri@gmail.com, 62333@debbugs.gnu.org
>> From: Dmitry Gutov <dgutov@yandex.ru>
>>
>>> mixed-major-mode shouldn't be a problem.
>>
>> Why wouldn't it?
> 
> Because the sexp ends inside the current mode's block.

But if the mmm framework narrowed the region to the current mode's 
block, widening will force tree-sitter to parse the whole buffer. Which 
might even result in parse errors (instead of meaningful parse nodes) 
near point.

Or consider the case when the code in the current snippet is incomplete 
(e.g. a missing paren). Then it might find a "match" somewhere far outside.

>>>> Because if we wanted to widen in all similar situations, we might as
>>>> well make it not obey the narrowing at all.
>>>
>>> It is impossible to not obey narrowing, not in Emacs.  I told that and
>>> explained that many times already, including simple examples of what
>>> trouble this could cause to even the most innocent Lisp code.  I hoped
>>> that by now this should no longer be brought forward.
>>
>> Okay. But do you advocate all uses of tree-sitter to (widen) first?
> 
> No, just in sexp-movement functions, at least for now.  If we discover
> this is need in many more situations, we might consider more drastic
> measures.  But I don't think we are there yet.  We've discovered just
> one such case, in just one such mode, and it's on master.  We still
> have ample time to see how widespread this is.

I'm not sure whether tree-sitter is going to be used with mmm-mode (or 
similar) a lot, since it has its own provisions for mixing languages.

But I'd also like to consider the other cases where we *don't* want to 
widen first. Any of them come to mind?