On Mon, Jul 26, 2021 at 9:49 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > It doesn’t harm for tree-sitter to see the rest of the buffer, it
> doesn’t modify anything, all it does it reading the text. OTOH, restricting
> tree-sitter to the bounds of narrows adds complexity for no benefit (as far
> as I can see).
>
> Which complexity does it add?  You just compare with BEGV_BYTE instead
> of BEG_BYTE etc.
>

In order to exercise many of its over-all benefits, tree-sitter builds and
maintains a parse tree of the whole file, and takes care to modify that
tree in-place with minimized changes. If emacs+ts were to remove everything
outside the narrow and then re-add it each time something temporarily
narrowed a file (say, to enhance mental focus), then emacs+ts would be
(wastefully) throwing away some of the underlying assumptions that makes ts
useful.

Emacs' internals use narrow/widen *and mostly honor them at most levels*
because they are emacs' abstraction for separating parts of a buffer from
other parts. Tree-sitter has a separate abstraction for doing this -- the
developer can have ts use different internal objects for different parts of
the file. This allows editors like Atom (a major influence on ts' original
feature set) to support what emacs would call multiple major modes. (Emacs
could still use some help here, c.f. Alan's proposal for "islands" from a
few years back.)

Using the ts multiple parsers support inside emacs+ts to "handle" narrowing
seems like a strong idea, but there are likely some complexities involved
in "switching" back and forth between the full-file parse and the narrowed
parse, plus making sure that the right parses are updated when the buffer
changes. With that in mind, it might be easier to start with an emacs+ts
prototype that always uses the full-file parse, and then adding the
"sub-parses" later. In that sense, it seems like it's primarily a matter of
what level of itch people want to start scratching when.

 emacs-dev islands discussion:
https://lists.gnu.org/archive/html/emacs-devel/2016-04/msg00585.html

Hope that helps,
~Chad