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

[Eli Zaretskii <eliz@gnu.org>]

> From: Theodor Thornhill <theo@thornhill.no>
> Date: Sun, 09 Oct 2022 22:01:07 +0200
> 
> I'd like to add in Java support here as well.

Sure, that'd be very good, TIA.

> But since java is part of cc-mode.el, maybe it'd be best if it got
> its own mode, say java-treesitter-mode.el, so that we don't add a
> dependency into cc-mode?  If you agree, I can create such a
> major-mode as well.

It depends on practical considerations.  If cc-mode's Java part has
significant features beyond those we intend to have supported by
tree-sitter, then a minor variation of cc-mode's java-mode is probably
the best; it could be via some minor mode or simply an optional
feature turned on by a defcustom.

OTOH, if Java support in cc-mode is more or less the same features as
we intend to provide with tree-sitter, a separate mode is probably the
best.

Alan, any comments and/or suggestions?

> Also, how should we mandate what modes get the new tree-sitter support?

Ideally, all of them.  The list I presented was just the minimal
program, considering the short time until Emacs 29 starts its release
cycle.  But there's no upper bound on the modes which should get
tree-sitter support.

> It is pretty fast to add new modes, and adding support for languages not
> already supported in core, such as say, golang, should be very feasible.
> But maybe that is something that should live in elpa?

I don't think programming-language modes should be outside of core, as
a matter of principle.  So, unless there are some specific reasons not
to include a mode (like lack of copyright assignments or the
author/maintainer objections), such modes should be in core.

There's also an issue of having popular modes for those languages as
3rd-party packages out there: it is best to try to bring them into
core and then add tree-sitter to them (unless they already support
it), than to come up with a completely separate implementation -- this
will allow their today's users to keep using the same more, instead of
having to decide whether to switch.

But otherwise, if it's easy to add support for more languages using
tree-sitter, let's do that, yes.