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

Previous Next

Full log

Message #182 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:40:19 +0300

> Date: Thu, 30 Mar 2023 16:28:58 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: wkirschbaum <at> gmail.com, casouri <at> gmail.com, 62333 <at> debbugs.gnu.org, 
>     dgutov <at> yandex.ru
> 
> > Something like
> >
> >  (treesit-make-parser LANGUAGE BUFFER nil START END)
> >
> > and
> >
> >  (treesit-parser-set-included-ranges RANGES...)
> >
> > (the latter already exists).
> >
> 
> Where "RANGES..." are included in [START..END], right?

Probably.  Or maybe instead of START and END we should have RANGES...

> > User-defined narrowing will never contradict parser restrictions.
> 
> You mean, they will be independent, right?  In other words, if the user 
> sets the narrowing to 1000-1200 in a buffer in which treesit-make-parser 
> has been called, say, once with 'php 400 1100' and once with 'js 1100 
> 1500', the two parsers will continue to have access to these ranges?

The parsers _can_ have access to those ranges, if they need it for
some reason.  In general, everything in Emacs should honor the current
restriction, unless there's a good reason to ignore it.  The problem
with ignoring it is that we can never know which code/user defined the
restriction and for what purpose.  I hope that keeping the parser's
restrictions as part of the parser itself will allow us to break free
of that issue when we have to widen.

> >> 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.
> >
> 
> Here I'm confused, that sentence seems to contradict the previous one. 
> "It" in "it will always obey narrowing" is the parser, right, and 
> "narrowing" is "the narrowing bounds set by 'treesit-make-parser'", right?

See above.  I hope that explains what I meant.

Previous Next

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