GNU bug report logs -
#62333
30.0.50; Issue with tree-sitter syntax tree during certain changes
Previous Next
Full log
Message #56 received at 62333 <at> debbugs.gnu.org (full text, mbox):
On 25/03/2023 16:09, Eli Zaretskii wrote:
>> Date: Sat, 25 Mar 2023 15:44:18 +0200
>> Cc: wkirschbaum <at> gmail.com, casouri <at> gmail.com, 62333 <at> debbugs.gnu.org
>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>>
>>> 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?
This bug report was last modified 2 years and 77 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.