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

[Eli Zaretskii]

> 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 16:15:00 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Only as long as you use Latin scripts.
> 
> Or CJK ones, which work perfectly fine without HarfBuzz text shaping.
> I have no experience with others.

Well, Emacs supports, and will continue to support, many others.

> > And even there, we want to support typographic ligatures and other
> > features of modern fonts.
> 
> Typographic ligatures and modern fonts are also orthogonal to editing
> code

No, they aren't: witness the requests to support ligatures in program
sources, which are driven by modern fonts like Iosevka and FiraCode.

> > 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.
> 
> But why would package.el and similar features be an integral part of any
> development environment?

Can you imagine a development environment nowadays that is unable to
update or upgrade optional packages or install new optional packages?
I can't.

> Remove networking support and TLS from Emacs, and people will still use
> it.  Then, delete (or slowly waste away) CC Mode, and almost all of our
> users will disappear.

I think both will cause users to disappear.  But we can argue about
this till Kingdom Come, because such an experiment will never happen.

> > 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 difference between Semantic and tree-sitter is that Semantic is
> comparatively slow, and written in Emacs Lisp, while the latter is
> written in C, a much faster language with multiple higher quality
> implementations.

You see only the aspects that support your POV, and dismiss the rest.
One aspect you ignore is the fact that Semantic is where it is today
because people who developed it stopped its development.  This is
directly relevant to your proposal to develop parsing capabilities as
part of Emacs -- the result in the long run will be the same, because
no one stays in Emacs development forever.

By contrast, using external implementations of technologies which are
important to IDEs has a much higher chance of finding Free Software
implementations that we can use, even if some of them become defunct.

> CC Mode barely qualifies as "language parsing technology."

Yes, and look at the problems with which it needs to struggle, and the
resulting performance issues.

> Not to mention that the scope of CC Mode is really much wider than that
> of tree-sitter.  i.e. tree-sitter does not provide style guessing
> functionality.

We will keep the parts that are independent of language parsing.

> > 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??
> 
> What is actually demonstrated is that Emacs Lisp and the existing C
> primitives are unsuitable for implementing language parsing technology.

That, too.  But it's the more general conclusions that matter in the
long run.