Re: How to add pseudo vector types

[Eli Zaretskii <eliz@gnu.org>]

> From: chad <yandros@gmail.com>
> Date: Mon, 26 Jul 2021 11:32:23 -0700
> Cc: Yuan Fu <casouri@gmail.com>, Clément Pit-Claudel <cpitclaudel@gmail.com>, 
> 	Stephen Leake <stephen_leake@stephe-leake.org>, Stefan Monnier <monnier@iro.umontreal.ca>, 
> 	EMACS development team <emacs-devel@gnu.org>
> 
> 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.) 

We are mis-communicating.  The issue is not _whether_ to allow TS to
access most or all of the buffer text, the issue is _on_what_level_
should this be controlled.  All I'm saying is that the right level is
NOT the function which accesses buffer text, the right level is
higher.  At that higher level, if some parser (or even almost every
parser) needs to access the entire buffer, some code should call
'widen'.

By contrast, if the text-reading function always treats the buffer as
widened, we will never be able to invoke a TS parser on a portion of
the text, something that is needed by specialized features.  It makes
no sense to require those features to start using TS-specific means of
restricting access to portions of the buffer to that effect, when a
simple restriction is good enough and is already being used.

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

I disagree.  The cost of having the text-reading function look only
inside the restriction is very small: a single call to 'widen' in the
caller.  The cost of having that function ignore the restriction is
much higher.