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