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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: wkirschbaum <at> gmail.com, casouri <at> gmail.com, 62333 <at> debbugs.gnu.org,
 dgutov <at> yandex.ru
Subject: Re: bug#62333: 30.0.50; Issue with tree-sitter syntax tree during
 certain changes
Date: Thu, 30 Mar 2023 19:04:30 +0300

> Date: Thu, 30 Mar 2023 15:50:31 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: Dmitry Gutov <dgutov <at> yandex.ru>, wkirschbaum <at> gmail.com, casouri <at> gmail.com, 
>     62333 <at> debbugs.gnu.org
> 
> > No, the idea is to create the parser with these restrictions to begin 
> > with.
> 
> Could you perhaps explain, with some fictitious code, what kind of 
> solution you imagine?  I'm not sure I understand (euphemism for: I'm sure 
> I don't understand) the problem statement.

Something like

  (treesit-make-parser LANGUAGE BUFFER nil START END)

and

  (treesit-parser-set-included-ranges RANGES...)

(the latter already exists).

> In what way would the restrictions you have in mind be different from 
> those of a regular narrowing?

User-defined narrowing will never contradict parser restrictions.

> Also, would such a parser always/never/sometimes obey the user narrowing?

It will always obey narrowing (it must), but we can then widen the
buffer temporarily inside some functions without caring about the
semantics of the narrowing and its source/purpose.

Previous Next

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