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

[Dmitry Gutov]

On 31/03/2023 21:43, Yuan Fu wrote:
> I think the distinction lies between “I want to narrow to this defun and work 
> on it without distraction” vs “treat this region as an isolated buffer”. The 
> former used by users, the latter used by lisp programs like Info and mmm-mode. 
> The former still considers the visible region part of the whole buffer, just 
> temporarily narrowed for convenience, the latter wants to make everything 
> thinks the visible region_is_  the whole buffer.

This distinction lies in how user-level features are implemented, 
though. E.g. for font-lock we have the variable font-lock-dont-widen 
which determines whether it will widen before getting the syntax 
information (calling syntax-ppss and so on) and acting on it.

>   It might be good for tree-sitter or other parsers to be exempt from (but 
> still acknowledges) the first kind of narrowing. This way the parser can avoid 
> unnecessary re-parse, and always provide the optimal information. We just need 
> to modify tree-sitter functions to check for this narrowing and don’t return 
> anything beyond the boundaries. It’s probably going to be a lot of hair, but 
> should be doable, I think?
>
> This way, most lisp programs still obeys the narrowing, but specific things 
> like tree-sitter can choose to secretly look around while still appear to obey 
> the narrowing, when peeking around wouldn’t hurt. And when the narrowing is 
> really indented, tree-sitter (or other parser) knows not to look around.

I'm not sure this is different from the "regular" major modes which use 
syntax-ppss as their parser. They also call 'widen' in a lot of cases to 
"peek around".

So that was my point: the external requirements for tree-sitter modes' 
behavior don't seem that different from the "classic" modes.

Narrowing in blink-matching-paren, BTW, also should have a similar 
cache-busting effect on syntax-ppss, with the main difference that it 
keeps two caches around, so it might end up reparsing only once (the 
narrowed parse state), hence the performance impact, over the smaller 
range of text, would be limited.