emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How to add pseudo vector types


From: Ergus
Subject: Re: How to add pseudo vector types
Date: Tue, 27 Jul 2021 18:50:40 +0200

On Tue, Jul 27, 2021 at 10:49:44AM -0400, Yuan Fu wrote:


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.

I agree here.

Therefore I’d like to expose ts_parser_set_included_ranges in a
separate function.

Exposed in the lisp side could make sense then.


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?

It worked for me; but it was a much simpler use case; maybe in the
general case it breaks. I think the only way to know is to try it.

Any way the official documentation suggests to use
ts_tree_get_changed_ranges.


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


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.

I think that was the initial Eli's idea when this topic came out. But
maybe I understood it wrongly.

Theoretically in a re-parse doing ts_tree_get_changed_ranges will give
the list of changes needed in the whole text, so updating properties
there may be simpler and cheap (even when they are not in the visible
part of the buffer).

Also, any action that doesn't modify the text (scrolling, moving the
cursor, windows split/resize) won't call any tree-sitter and redisplay
could handle almost everything easily on the beginning.

The only concern here may be that adding properties to the entire text
may be memory consuming. Or maybe that this could overlap part of the
font-lock functionality.

But probably Eli can make a more accurate critic of this idea..

Yuan

Very thanks for doing this!
Ergus.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]