Re: How to add pseudo vector types

[Eli Zaretskii]

> From: Stephen Leake <stephen_leake@stephe-leake.org>
> Cc: casouri@gmail.com,  monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> Date: Wed, 21 Jul 2021 08:49:15 -0700
> 
> > I fail to see the significance of the difference.  Surely, you could
> > hand it a block of text with changes to mean that this block replaces
> > the previous version of that block.  It might take the parser more
> > work to update the parse tree in this case, but if it's fast enough,
> > that won't be the problem.  Right?
> 
> tree-sitter doesn't store the previous text, so there's nothing to
> compare it to.

There was nothing about comparison in my text.  You tell TS that
editing replaced a block of text between A and B with block between A
and C, without revealing the fine-grained changes inside that block.
This must work, because editing could indeed do just that.

> Alternately, this would require the parser to store the
> previous text so it can compute the diff; that could be added in a
> wrapper around tree-sitter.

Presumably, TS has already solved this problem, because it needs that
for allowing the clients to communicate the changes to it.

> > That's why I'm trying to find a simpler, less wasteful strategies.
> > Since TS is very fast, we can trade some of the speed for simpler,
> > more scalable design of tracking changes.
> 
> I don't see how optimizing the change list makes it more "scalable";

Keeping too much information about each buffer is less scalable,
especially with many large buffers.

> In practice font-lock is triggered on every character typed by the user
> (Emacs is faster than people can type), so there will typically be only
> one change; nothing to optimize.

Editing doesn't include just typing one character at a time.  There's
killing, yanking, C-x i, M-/, M-\, C-M-\, smart completion, etc.