Re: Tree-sitter introduction documentation

[Dmitry Gutov <dgutov@yandex.ru>]

On 27/12/2022 14:11, Eli Zaretskii wrote:
>> Date: Tue, 27 Dec 2022 00:42:55 +0200
>> Cc: emacs-devel@gnu.org
>> From: Dmitry Gutov <dgutov@yandex.ru>
>>
>> On 17/12/2022 17:42, Stefan Monnier wrote:
>>> Those grammars have been in use for a while now
>>> (by other editors), AFAIK, so why would the situation change just because
>>> Emacs starts to use them as well?
>>
>> I guess "other editors" that use tree-sitter do bundle the grammars?
>>
>> Or include them in the optional language packages. Or provide built-in
>> recipes to install them.
> 
> WDYT about what we have in NEWS about this?

Those instructions seem to be written foremost with distro maintainers 
in mind. Definitely better to have them than not, but I'd hate to 
present them to the average user.

Do we expect all (most?) distros to compile all the popular grammars?

That would still leave out the users of the less popular languages whose 
grammars were not included. Or grammars which saw updates since the 
distro-distributed version (so it's useful to install the newer version).

>> E.g. nvim-treesitter seems to be doing the latter:
>> https://github.com/nvim-treesitter/nvim-treesitter#language-parsers
>>
>> The corresponding recipes look like:
>>
>> list.ruby = {
>>     install_info = {
>>       url = "https://github.com/tree-sitter/tree-sitter-ruby",
>>       files = { "src/parser.c", "src/scanner.cc" },
>>     },
>>     maintainers = { "@TravonteD" },
>> }
> 
> It sounds like a non-trivial maintenance burden to keep this kind of
> DB up-to-date.  So I'm not sure we should do this in the upstream
> project.
> 
> But if Someone(TM) wants to provide Emacs commands to download,
> compile, and install a grammar library, I see no reason not to add
> that to Emacs.  This could be part of treesit.el, for example.

I wouldn't worry too much about the maintenance burden (keeping the list 
of urls up-to-date?), especially since we could refer to such lists by 
other projects.

I think ELPA is a better place for this feature, though. Because we 
always want the user to get the latest version of the recipes.

Or if we put this into treesit.el, it would be better to keep the set of 
recipes as a separate package, so the updates to it can be put into ELPA 
(as a :core package).

> One condition, though: please implement the commands in Emacs Lisp,
> without invoking any shell scripting features (which shouldn't be
> needed to begin with), just by using compiler, Emacs commands and
> functions that deal with files, and (possibly) Git.
> 
> Also, if we provide some list of grammar libraries we support
> officially and their respective sites, that list should include only
> libraries with a Free license.

Makes sense.