Re: How to add pseudo vector types

[Óscar Fuentes]

chad <yandros@gmail.com> writes:

> I think I understand your point, and I agree that it would be ill-advised
> to remove the ability to change the "scope" in question from lisp's
> control. What I'm trying to say (and I think Yuan Fu is also suggesting) is
> that while emacs necessarily has *one* view of the buffer, narrowed or not,
> tree-sitter might want to maintain multiple trees of that buffer, with the
> default being the same as emacs' widened view, and narrowed views being
> separate parse trees created as needed. I'm suggesting this as an
> alternative to having emacs+ts effectively throw away most of the parse
> tree every time the user narrows, then have to re-build it on each widen.
>
> In other words, I think this might be a communication issue about the
> default trade-off behavior: generally keep a fully-widened tree and
> create/use narrowed trees as needed, versus generally keeping only a tree
> that matches whatever a higher-level view of the buffer might give at any
> one moment, rebuilding each time.

IIUC this is not about the user doing M-x narrow-to-defun or somesuch,
we can agree that (in general) the right thing to do for TS is to keep
using the whole buffer.

I think Eli is trying to control what TS sees because doing so would
make possible some features and/or simplify implementing them. Think of
an Org file with some code blocks. It makes no sense to expose the whole
Org file to TS and, I guess, it would just complicate things for no
benefit. On that scenario, it might make sense to deal with the code
blocks as independent entities instead of parts of something else.