GNU bug report logs - #62333
30.0.50; Issue with tree-sitter syntax tree during certain changes

Previous Next

Full log

Message #53 received at 62333 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: wkirschbaum <at> gmail.com, casouri <at> gmail.com, 62333 <at> debbugs.gnu.org
Subject: Re: bug#62333: 30.0.50; Issue with tree-sitter syntax tree during
 certain changes
Date: Sat, 25 Mar 2023 17:09:33 +0300

> 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.

> Long lines?

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

> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.