Re: Tree-sitter introduction documentation

[Eli Zaretskii <eliz@gnu.org>]

> Date: Tue, 27 Dec 2022 14:43:06 +0200
> Cc: monnier@iro.umontreal.ca, theophilusx@gmail.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> 
> > WDYT about what we have in NEWS about this?
> 
> Those instructions seem to be written foremost with distro maintainers 
> in mind.

Or users who build and install Emacs by themselves.

Frankly, I don't see why we, the upstream project, need to worry about
anyone else.  It isn't our job.  That's what distros are there for.

> Definitely better to have them than not, but I'd hate to present
> them to the average user.

"Hate"?  That's a strong word.  The questions that the NEWS entries
answer were asked here and elsewhere several times, so presumably that
information has some non-trivial value.

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

I honestly don't know.  On the one hand, there aren't many Emacs modes
which use tree-sitter, but OTOH they could start growing like
mushrooms once Emacs 29 hits the streets.  I do expect them to offer
the ones they consider useful/needed, for some value of that.  I
really don't see any significant difference in this regard between
grammar libraries and, say, librsvg.  Both are used in Emacs, and the
lack of either disables useful Emacs features.  So it's a no-brainer
for me.  But then I'm not a distro maintainer, and never have been.

> 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).

What's the solution?  All the "solutions" I saw until now require a
working and well-configured C/C++ compiler (sometimes both C and C++),
linker, and C/C++ runtimes.  A user who has them already installed can
easily build a grammar library with two simple commands.  A user who
doesn't have a C/C++ development environment will not find those
"solutions" useful at all.  And asking us to distribute binaries for
half a dozen popular systems is IMNSHO unreasonable.

> > 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 cannot disagree more.  Look at this from my POV: once the list
becomes even semi-official, people will expect it to be of the same
high quality as all the rest of Emacs, and they _will_ complain and
report inaccuracies.  It's a nuisance, especially for such a "hot"
feature set.

And which "other projects"? who can track those and know which ones
have the most accurate, up-to-date, and comprehensive list?  I'm a bit
interested in this (and have several dozens of grammar libraries built
locally), and I discover another project with a useful list of
grammars almost every day.  These things are highly dynamic: I see
some of the grammars get updates every couple of days.  Some languages
have more than one grammar library maintained by different people --
who will figure out which one is better for us and keep that
information up-to-date?

> 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.

That solves only part of the problem.  (And not an important part: our
Git repository is public, so people can track it and download updates
for files as easily as they track ELPA.)  The hard part -- keeping the
information accurate and up-to-date -- still needs a motivated
volunteer.  And we hardly have resources to work on our code and docs,
let alone help people install external software.

(Of course, if such a motivated volunteer steps forward, he or she
will be most welcome.)