Re: How to add pseudo vector types

[Yuan Fu]

> 
> From my absolute ignorance on tree_sitter and your changes. There is a
> function ts_parser_set_included_ranges that is a way I used once to
> reduce the parsing region and improve (notably) the performance in a
> test api.
> 
> Can't narrow regions use that? I think it is the same idea but I am
> probably wrong.

We could use ts_parser_set_included_ranges to implement narrowing, but that 
would limit the usefulness of ts_parser_set_included_ranges: 
ts_parser_set_included_ranges allows us to set multiple discontinuous ranges, 
and narrowing only allows us to narrow to a single continuous range. Therefore 
I’d like to expose ts_parser_set_included_ranges in a separate function.

> 
> Limiting the region to parse to the modified region (that in emacs may
> be known thanks to the gap and maybe the undo-tree) and using the output
> tree from the previous parse as the `old_tree` parameter in
> ts_parser_parse_string made tree_sitter incredibly fast in my case (and
> useful to run it on every key press).

Interesting, the official documentation doesn’t mention that trick. It only 
tells me to re-parse with the old tree. If I limit the range to the modified 
region before re-parse, re-parse, do I get the tree for the entire buffer, or 
do I only get the tree of the limited range?

> 
> In my case using old_tree reduced the time by a factor of 10 in a big
> source file; and limiting the parser to the "changed" region only made
> it almost instantly in more than 80% of the executions with small
> modifications. (I repeat; it was a much simpler use case)
> 
>> And about language definitions and font-locking, I just realized that
>> tree-sitter language definitions provides highlighting patterns, and we
>> only need to minimally modify them to use them for Emacs, so there
>> aren’t much manual effort involved.
>> 
> I think tree-sitter has many more language definitions than Emacs in
> some languages, and probably we may want to properly support them. So
> maybe: instead of just modifying what is on tree-sitter to make it
> similar to what emacs currently has; we could just use the node's
> syntactic information and then let emacs use it adding more faces if
> needed... Does it makes sense?

The current code does the latter, if I understand you correctly.

> The idea is to have real syntactic information on the text itself
> because that may help in the future to implement indentation and
> navigation commands using three-sitter's information (commands like
> up-list or forward-sexp) will be the equivalent to
> ts_tree_cursor_goto_parent or ts_tree_cursor_goto_next_sibling.

You mean adding syntactic information to the text as text properties? That’s an 
interesting idea, maybe that’s easier to use than using tree-sitter’s api.

Yuan