GNU bug report logs -
#62333
30.0.50; Issue with tree-sitter syntax tree during certain changes
Previous Next
Full log
View this message in rfc822 format
On 30/03/2023 19:04, Eli Zaretskii wrote:
>> 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)
What kind of code would be calling this?
What happens when the user types a character before START? What happens
when they delete a character at START or END? Or a whole line?
> and
>
> (treesit-parser-set-included-ranges RANGES...)
>
> (the latter already exists).
Indeed, a way to do this using tree-sitter indeed already exists,
offloading the parsing of the regions to tree-sitter. OTOH, this way we
only get tree-sitter features sorted into regions (parse tree,
indentation, highlighting).
Whatever other Lisp-level features we wanted to behave differently
between regions, we'd have do implement them the old way.
>> 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.
IOW, user-defined narrowing should be only for visual purposes, as
described in another email. And perhaps to restrict movement (which is
related: you can't move to where you can't see).
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.