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 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.
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.