On Sun, Oct 2, 2022 at 2:19 AM Eli Zaretskii <eliz@gnu.org> wrote:

> Again, I don't see why tree-sitter should be handled differently from
> other optional libraries.
>

I'm not sure if this is Yuan Fu's concern, but for me:

If I want to build a changed tree-sitter language definition myself, the
second-ish step is "install Node.js", and I stop there. (Whether this is a
sign of taste or curmudgeonliness is left as an exercise for the reader. :-)

On Sun, Oct 2, 2022 at 2:19 AM Eli Zaretskii <eliz@gnu.org> wrote:

> We might discover good reasons for that after we gain some actual
> experience, but up-front I see no reason to assume any special issues.
> IOW, I think we are "putting the cart before the horse" here.


This is an excellent point; it seems likely that we can gain useful
experience with tree-sitter in emacs without having pre-built a
distribution channel for version-specific binary pieces. In practice, I
suspect that the concern is responding to the current situation, where
tree-sitter experimentation is largely confined to people who already hack
on tree-sitter itself (rather than just wanting to use it), OR to people
who, in practice, download pre-compiled binaries from github. At least,
that's the situation I find myself in.

For now, I suspect that something akin to the Windows snapshots on
alpha.gnu.org might be a workable compromise if the problem actually comes
up.

Hope that helps.
~Chad