Re: Hosting tree-sitter pre-built language definitions on ELPA?

[Yuan Fu <casouri@gmail.com>]

> On Oct 2, 2022, at 10:06 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: chad <yandros@gmail.com>
>> Date: Sun, 2 Oct 2022 12:36:23 -0400
>> Cc: luangruo@yahoo.com, casouri@gmail.com, emacs-devel@gnu.org
>> 
>> On Sun, Oct 2, 2022 at 9:52 AM Eli Zaretskii <eliz@gnu.org> wrote:
>> 
>> We are not talking about changing the language definitions, we are
>> talking about installing the ones provided by tree-sitter.  The use
>> case you mention is akin to your wanting to modify librsvg -- in which
>> case you'd need to start by installing Rust.
>> 
>> I _think_ I disagree about that analogy. If I want to use tree-sitter with a language that is not already somehow
>> installed on my computer, I need a language definition for it. Right now, I can either install Node.js and build it
>> myself, or download a binary from github. Is there another option?
> 
> Yes, you can download the C source of the language definition and
> compile it yourself.

Yeah, for the record, you don’t need nodejs to compile the language definitions, only a C compiler. (Sometimes a C++ compiler.)

> 
>> IIUC, the current expectation is NOT that
>> an emacs+tree-sitter release will bundle language definitions for every language we expect the users are
>> likely to want, or even for, say, the top 10 languages already supported by emacs outside of treesit. Is that
>> understanding incorrect? 
> 
> Yes.  I don't think it's fair to expect the Emacs project to provide
> such degree of hand-holding.  It would place too much burden on our
> insufficient resources.
> 
> If downloading and building the tree-sitter language definitions is
> too much for many users, I expect the Emacs distros to provide
> prebuilt packages for that.

I brought this up because someone suggested to bundle language definitions with Emacs for better access. If we decide to not provide hand-holding, I don’t mind doing less work ;-)

Yuan