bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Dmitry Gutov
Subject: bug#62333: 30.0.50; Issue with tree-sitter syntax tree during certain changes
Date: Sat, 25 Mar 2023 16:18:12 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0

On 25/03/2023 16:09, Eli Zaretskii wrote:
Date: Sat, 25 Mar 2023 15:44:18 +0200
Cc: wkirschbaum@gmail.com, casouri@gmail.com, 62333@debbugs.gnu.org
From: Dmitry Gutov <dgutov@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?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]