bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: bug#62333: 30.0.50; Issue with tree-sitter syntax tree during certain changes
Date: Sat, 01 Apr 2023 08:47:50 +0300

> From: Yuan Fu <casouri@gmail.com>
> Date: Fri, 31 Mar 2023 11:43:49 -0700
> Cc: Eli Zaretskii <eliz@gnu.org>,
>  Wilhelm Kirschbaum <wkirschbaum@gmail.com>,
>  Gregory Heytings <gregory@heytings.org>,
>  62333@debbugs.gnu.org
> 
> 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.

Users can do both, for whatever reasons.

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

I don't see why it would be a lot of hair.  If a parser always has the
regions on which it is supposed to work, then a Lisp program using a
parser can simply widen the buffer when it needs to be sure a
narrowing doesn't get in the way.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]