[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.
- bug#62333: 30.0.50; Issue with tree-sitter syntax tree during certain changes,
Eli Zaretskii <=