Re: How to add pseudo vector types

[Eli Zaretskii <eliz@gnu.org>]

> From: Yuan Fu <casouri@gmail.com>
> Date: Thu, 29 Jul 2021 11:57:56 -0400
> Cc: Stephen Leake <stephen_leake@stephe-leake.org>,
>  Clément Pit-Claudel <cpitclaudel@gmail.com>,
>  monnier@iro.umontreal.ca,
>  emacs-devel@gnu.org
> 
> >> Anyway, I found a way that avoids this issue: the bounds of tree-sitter’s visible region never changes, and the next time when lisp narrows to a different region, we update tree-sitter’s bound to match that of the narrowing. Here is the latest patch. If the code is not entirely straightforward, I’m happy to add more comment to explain it.
> > 
> > I'm not sure we should do this, because it means we second-guess what
> > the Lisp program calling TS intends to do.  Why should we do that,
> > instead of leaving it to the Lisp program to DTRT?  And what happens
> > if our guess is wrong?
> 
> I don’t think the current implementation guesses anything. Let me turn around and ask you what is TRT: if the buffer is xxxAAAxxx, and lisp narrows to AAA and creates a parser, parser sees AAA; now widen, user inserts BBB in front of AAA, what do we tell tree-sitter? Nothing changed, or BBB inserted at the beginning?

Neither.  We should tell TS that instead of AAA there's now
xxxBBBAAAxxx, because the narrowing was removed.

> To where should lisp narrow? BBBAAA, or AAA, or BBB?

It's the question for the Lisp program, not for the low-level code
which we are discussing.

Anyway, you are once again bothered by a scenario that should not
happen at all: a Lisp program should not call TS first with, then
without narrowing (or the other way around).  I don't see why such
situation should happen, and if they do, the Lisp programs which need
them will have to figure out what to do and how.