Re: Tree-sitter introduction documentation

[Tim Cross]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Tim Cross <theophilusx@gmail.com>
>> Date: Sat, 17 Dec 2022 11:03:50 +1100
>> 
>> Given the installation of language grammars is reasonably straight
>> forward (from what you posted earlier), what about adding a package to
>> GNU ELPA which could facilitate/do the installation of a set of
>> language grammars (similar to what the
>> admin/notes/tree-sitter/build-modules/batch.sh script does.
>
> I don't mind, but then I don't take care of ELPA, so I'm not the guy
> to talk to about this.
>
> Up front, it would be a strange kind of "package" for what ELPA is
> supposed to hold, and I also don't understand what would package.el do
> with such a "package".  But that's me.

I get your points. My thoughts are that this could be an easy temporary
solution that would provide a smoother initial transition until
distributions do bundle the language grammars.

However, given other editors apart from Emacs use tree sitter, I wonder
why none of the distributions I've looked at are bundling language
grammars? Most of them seem to have packages for the main tree sitter
libs, but none have the language grammars (with possible exception of
Arch, where I think they are available via the AUR, which technically,
isn't part of the distribution).

Wasn't there a MELPA package which provided these language grammars? If
so, I guess we know the idea can work. I also note there are other
packages which will automatically install some non-elisp dependencies
i.e. lsp-mode, ps-tools, all-the-icons etc. 

I'd like to stress my point that I would see this as a temporary and
easy to deprecate approach that would help in the adoption of tree
sitter. There are some options on how it would work - it could do a
direct install of pre-compiled binaries, clone and build from git
repositories, provide an install script the user then has to run or some
other combination.

Once the major distributions have packaged the grammars, it would be
expected they would be automatic or possibly optional dependencies for
the main emacs package. At this point, we might decide to deprecate the
package in favour of using distribution based packages (or possibly just
keep it for platforms which don't provide them?).