Re: How to add pseudo vector types

[Yuan Fu]

> On Jul 15, 2021, at 11:50 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Yuan Fu <casouri@gmail.com>
>> Date: Thu, 15 Jul 2021 11:17:02 -0400
>> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,
>> emacs-devel@gnu.org
>> 
>>> Great, then please try also to liberate the implementation from using
>>> JSON, it's a major slowdown factor.
>> 
>> JSON? I didn’t write anything involving JSON. 
> 
> Then what is json-module.zip about?

That’s a language definition for tree-sitter, so it tells tree-sitter how to 
parse a JSON file. There are definitions for Python, Ruby, C, etc. I just used 
JSON for an example. It’s named json-module because it is a dynamic module.

> 
>> While you are looking at the patch, here are some questions for integrating 
>> tree-sitter with out buffer implementation. What I envisioned is for each 
>> buffer to have a `parser-list’, and on buffer change, we update each 
>> parser’s tree. I think modifying signal_after_change is enough to cover al 
>> the cases?
> 
> Why do you need to do this when a buffer is updated? why not use
> display as the trigger?  Large portions of a buffer will never be
> displayed, and some buffers will not be displayed at all.  Why waste
> cycles on them?  Redisplay is perfectly equipped to tell you when some
> chunk of buffer text is going to be redrawn, and it already knows to
> do nothing if the buffer haven't changed.

Tree-sitter expects you to tell it every single change to the parsed text. Say 
you have a buffer with some content and scrolled through it, so tree-sitter has 
parsed the whole buffer. Then some elisp edited some text outside the visible 
portion. Redisplay doesn’t happen, we don’t tell this edit to tree-sitter. Then 
I scroll to the place that has been edited. What now? I’ve lost the change 
information, and tree-sitter’s tree is out-dated.

We can fontify on-demand, but we can’t parse on-demand. What we can do is to 
only parse the portion from BOB to the visible portion. So we won’t parse the 
whole buffer unless you scroll to the bottom.

> 
>> And, for tree-sitter to take the buffer’s content directly, we need to tell 
>> it to skip the gap.
> 
> AFAIR, tree-sitter allows the calling package to provide a function to
> access the text, isn't that so?  If so, you could write a function
> that accesses buffer text via BYTE_POS_ADDR etc., and that knows how
> to skip the gap already.

Yes, that function returns a char*. But what if the gap is in the middle of the 
portion that tree-sitter wants to read? Alternatively, we can copy the text out 
and pass it to tree-sitter, but you don’t like that, IIRC.

> 
>> I only need to modify gap_left, gap_right, make_gap_smaller and 
>> make_gap_larger, right?
> 
> Why would you need to _modify_ any of these?

Because I want to let tree-sitter to know where is the gap so it can avoid it 
when reading text.

Yuan