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

[Eli Zaretskii <eliz@gnu.org>]

> From: Po Lu <luangruo@yahoo.com>
> Cc: theo@thornhill.no,  acm@muc.de,  emacs-devel@gnu.org,
>   jostein@kjonigsen.net
> Date: Tue, 11 Oct 2022 15:31:09 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > 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 isn't quite our business to develop mini-gmp either, yet it's also
> kept in-tree.

I'm okay with removing mini-gmp, if the GMP library is supported on
all the platforms we care about.  But mini-gmp is from Gnulib, so we
don't need to develop or maintain it.

> > 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.
> 
> But editing text mostly does not involve editing complex shaped text,

Only as long as you use Latin scripts.  And even there, we want to
support typographic ligatures and other features of modern fonts.

> and likewise, TLS connections and image display is mostly orthogonal to
> the business of editing text.

Emacs is not just a text editor.  Networking is nowadays an integral
part of any development environment.  E.g., package.el would be
impossible without TLS connections.

> > It is completely impractical to expect us to be able to develop this
> > in-house.
> 
> Why?

Because we have past experience to indicate that.  Look at Semantic,
look at CC Mode, etc.  My conclusion from that is clear, and it's
non-negotiable, not as long as I'm doing this job.

> The tree-sitter runtime library is only about 16,000 lines of C
> source code and headers, which is less than xdisp.c alone, and only
> slightly more than keyboard.c.

Yes, and how many people do we have on board who know all of xdisp.c
and all of keyboard.c?  Exactly zero.

Really, how many more examples of this do we need to understand what
is and what isn't future-proof for Emacs??  How blind can we be if,
based on long and rich past experience such as what we have, we don't
realize that developing key technologies in-house is a dead end for
us?  Are we really _that_ blind??

> > , 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
> 
> Text shaping is, at least IME, immensely more complicated than
> interactive language parsing.

I don't see how that matters.  Both are outside of our expertise.

> > 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.
> 
> That logic could also have been applied to bignums, yet there was no
> objection to including mini-gmp.

mini-gmp is from Gnulib, so it isn't our maintenance burden.

> > 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.
> 
> I'm not disputing that fact, which is why I proposed to write an
> *implementation* of tree-sitter for inclusion with Emacs, and not to
> develop an equivalent in-house.

Sorry, I cannot agree with such a terrible waste of our scarce
resources.  I cannot prevent anyone from working on whatever they
like, but don't expect me to agree to adding such an implementation to
the Emacs sources and taking responsibility for its maintenance.  It's
completely against every goal towards which I worked since I became
the Emacs maintainer, and is very wrong for the reasons I already
abundantly explained.