Re: Tree-sitter api

[Yuan Fu]

> On Sep 28, 2021, at 12:02 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Yuan Fu <casouri@gmail.com>
>> Date: Mon, 27 Sep 2021 22:33:17 -0700
>> Cc: Eli Zaretskii <eliz@gnu.org>,
>> Tuấn-Anh Nguyễn <ubolonton@gmail.com>,
>> Theodor Thornhill <theo@thornhill.no>,
>> Clément Pit-Claudel <cpitclaudel@gmail.com>,
>> Emacs developers <emacs-devel@gnu.org>,
>> Stephen Leake <stephen_leake@stephe-leake.org>,
>> John Yates <john@yates-sheets.org>
>> 
>> With that said, I still have one thing not too sure. What should 
>> tree-sitter.el do if libtree-sitter is not on the system, and tree-sitter.c 
>> is not included in Emacs? Should we simply not include tree-sitter.el? Is 
>> there existing build facility that can do that (exclude tree-sitter.el when 
>> libtree-sitter is not found on system)?
> 
> I don't think I understand the problem: why would you need "not to
> include" tree-sitter.el?  We have quite a few *.el files that need
> support from built-ins which could not be available at run time, and
> yet we don't hesitate to include those *.el files.  How is this case
> different?  I guess some details of what bothers you are missing.

Nothing in particular except the naive assumption that we won’t provide 
functions that don’t work. I didn’t know that we have quite a few *.el files 
that could potentially not work before. Do you have some examples? Anyway, I 
can provide a function tree-sitter-avaliable-p similar to native-compilation, 
that way a user knows if he can use tree-sitter features.

Yuan