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

From: Dmitry Gutov <[email-masked]>
Date: Fri, 31 Mar 2023 04:25:41 +0300

On 30/03/2023 19:04, Eli Zaretskii wrote:
>> Date: Thu, 30 Mar 2023 15:50:31 +0000
>> From: Gregory Heytings <[email-masked]>
>> cc: Dmitry Gutov <[email-masked]>, [email-masked], [email-masked],
>>      [email-masked]
>>
>>> 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).