Re: Call for volunteers: add tree-sitter support to major modes

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Alan Mackenzie <acm@muc.de>,
>   emacs-devel@gnu.org,  jostein@kjonigsen.net
> Date: Tue, 11 Oct 2022 12:43:36 +0800
> 
> Theodor Thornhill <theo@thornhill.no> writes:
> 
> > My suggestion is to add the tree-sitter variant in these cases, and let
> > the other modes die a slow, deprecated death down the line.
> 
> In that case, will any of you object if someone writes a parser
> generator in C and an implementation of the tree-sitter runtime library
> that can be included with Emacs itself (namely, with the copyright
> assigned to the FSF?)

Yes, I will.

It isn't our business to develop language parsers, and we have no hope
of keeping up with the technology developments in that area and with
new languages being invented, well enough to offer reasonable and
modern support in Emacs for editing programs in those languages.

It's the same reason why we depend on text shaping engines like
HarfBuzz for rendering complex scripts and other typography-related
features, on image libraries to display images, on GnuTLS to support
TLS connections, etc. etc.

We cannot possibly be experts in all of those fields, we don't have
the manpower for that.  In the case of support for editing programs we
actually tried for many years, and the result is before our eyes --
and it's unsatisfactory at best.  We should advance Emacs towards
leveraging existing technologies, not try developing those
technologies in-house, or replacing them by cheap hacks and kludges.

> My opinion is that Emacs should not degrade its text editing
> capabilities so drastically if a non-system library (i.e. not ncurses or
> Xlib) is not present.

It is completely impractical to expect us to be able to develop this
in-house.  If tree-sitter becomes defunct (something that doesn't seem
like it will happen any time soon), we will have to find a suitable
replacement -- like we did with text-shaping engine, when the FLT
library stopped being actively developed.  Dealing with these changes
in the outside world is an important part of the job of the Emacs
maintainers (as is identifying new emerging technologies that can be
leveraged for new and enhanced Emacs features).  We are doing this
part for several years already, and doing it successfully.  I see no
reason to change that, and all the reasons, including past experience,
to keep up.

The present font-lock and indentation features based on our own code
can remain in Emacs forever, if someone wants a safe fallback for when
worse comes to worst.  But these implementations are from my POV a
dead end: they cannot be developed any further, and for some
languages, like C++, are already all but failing to reasonably and
efficiently support their complex grammars.  Using expertise of others
is simply a logical step based on past experience; the decision to
develop this in-house would be a step back and a disaster in the long
run, IMNSHO.