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

From: Dmitry Gutov <[email-masked]>
Date: Sat, 25 Mar 2023 16:18:12 +0200

On 25/03/2023 16:09, Eli Zaretskii wrote:
>> Date: Sat, 25 Mar 2023 15:44:18 +0200
>> Cc: [email-masked], [email-masked], [email-masked]
>> From: Dmitry Gutov <[email-masked]>
>>
>>> If that's the only reason, then tree-sitter based modes could widen
>>> back in their sexp-moving functions, since they use the parse data for
>>> this, right?
>>
>> Not necessarily: it doesn't know the purpose for which the narrowing was
>> applied. Could be for a mixed-major-mode thing, or some other purpose.
> 
> mixed-major-mode shouldn't be a problem.

Why wouldn't it?

>> Long lines?
> 
> Easy to test, and the call to widen will do nothing anyway in that
> case.

Okay. Because of locked narrowing, I guess.

>> Do we recall the exact design idea why tree-sitter visibility is limited
>> by the narrowing bounds?
> 
> For the same reason: because the buffer is inaccessible outside the
> restriction, and tree-sitter wants to access the buffer text.
> 
>> 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?