Re: Is it better to add treesitter modes to core?

[Eli Zaretskii <eliz@gnu.org>]

> From: Philip Kaludercic <philipk@posteo.net>
> Cc: dmitry@gutov.dev,  stefankangas@gmail.com,  emacs-devel@gnu.org,
>   stephen_leake@stephe-leake.org
> Date: Tue, 09 Jan 2024 20:21:02 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Philip Kaludercic <philipk@posteo.net>
> >> Cc: dmitry@gutov.dev,  stefankangas@gmail.com,  emacs-devel@gnu.org,
> >>   stephen_leake@stephe-leake.org
> >> Date: Tue, 09 Jan 2024 19:27:50 +0000
> >> 
> >> Eli Zaretskii <eliz@gnu.org> writes:
> >> 
> >> >> From: Philip Kaludercic <philipk@posteo.net>
> >> >> Cc: Stefan Kangas <stefankangas@gmail.com>,  emacs-devel@gnu.org,  Stephen
> >> >>  Leake <stephen_leake@stephe-leake.org>
> >> >> Date: Mon, 08 Jan 2024 06:15:07 +0000
> >> >> 
> >> >> > Possible grammar versioning problems. But the above should be small
> >> >> > and stable enough, nor should they require many changes over the
> >> >> > years.
> >> >> 
> >> >> I don't think this has to be a problem.  Last year I had suggested that
> >> >> `treesit-install-language-grammar' should download release GitHub
> >> >> tarballs, not just clone the repository (which requires Git, and is
> >> >> prone to upstream breakage).
> >> >
> >> > Alas, this solution is incomplete, because some grammar libraries
> >> > don't have releases at all.
> >> 
> >> Most if not all git forges should support requesting an archive for a
> >> specific commit (basically git-archive over https).  For example, this
> >> will provide a tarball for the current newest commit for the python
> >> tree-sitter library:
> >> 
> >>   https://github.com/tree-sitter/tree-sitter-python/archive/4bfdd9033a2225cc95032ce77066b7aeca9e2efc.tar.gz
> >
> > I was responding to the suggestion to download release tarballs.
> 
> Then I misunderstood you, my argument is just that we could avoid
> grammar versioning issues by fetching specific revisions (be it by
> commits or by releases), and that we don't even have to use git for
> that.

With that method, how do we know which revisions are good for us to
recommend them?  If a grammar library has releases, then its
developers already provide us with "stable" versions, but if they
don't, how do we know?