emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Tree-sitter introduction documentation


From: Dmitry Gutov
Subject: Re: Tree-sitter introduction documentation
Date: Tue, 27 Dec 2022 14:43:06 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]