Re: Tree-sitter api

[Eli Zaretskii]

> From: Yuan Fu <casouri@gmail.com>
> Date: Tue, 28 Sep 2021 09:10:32 -0700
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,
>  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-sheets.org
> 
> > 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?

Examples include native-compilation (comp.el), xwidgets (xwidget.el),
and threads (thread.el).

> 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.

Yes, that's generally what optional packages do.