Re: Tree-sitter integration on feature/tree-sitter

[Yuan Fu]

> On May 10, 2022, at 4:11 PM, Yuan Fu <casouri@gmail.com> wrote:
> 
> 
> 
>> On May 10, 2022, at 12:58 PM, Stefan Monnier <monnier@iro.umontreal.ca> 
>> wrote:
>> 
>>> Eli/Stefan, please guide us!
>> 
>> I don't have much to say. OK, let's invent something:
>> 
>> 1- Maybe it would be good to expose "compiled query" objects to ELisp,
>> so the compilation could be performed by explicit requests (so you
>> don't have to cache it, instead the major modes would call the
>> function when installing their indentation/fontlock rules).
> 
> Maybe something like (treesit-cache-query key query), that saves exposing 
> another type to lisp.
> 
> 
>> 
>> 2- I don't understand why the use of hash map is perceived as complex.
>> It seems like a fairly simple solution.
> 
> I’m not sure how would we garbage collect unused queries, maybe I’m missing 
> something. And is there a C hash table that we can use? Or we need to use the 
> lisp hash table? 
> 
> Maybe we can use a buffer-local treesit--query-cache hash table and store 
> USERPTR of TSQuery in it, so we don’t worry about garbage collecting. Would 
> that be slow (getting the buffer-local variable, do a lookup, takeout the 
> TSQuery object)?

Or just expose query object, and let user store them in lisp. Is there any 
downsides of exposing another type to lisp? Currently tree-sitter adds two new 
types: treesit-node and treesit-parser.

Yuan