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

[Theodor Thornhill]

Hi Eli,

Eli Zaretskii <eliz@gnu.org> writes:

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

My pleasure.

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

Yeah, that makes sense - I'll let Alan chime in.

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

Agreed.  Well, I'm a maintainer and contributor to two fairly popular
modes, 'csharp-mode' and 'typescript-mode'.  The former is in ELPA, the
latter in nongnu ELPA.  For the former, I'm not sure if bringing the
cc-mode variant into core is a good plan, for several reasons.

- It has some perf issues with multiline strings
- There's some problems with indentation and other very c# related stuff
- It _will_ cause more maintainer burden onto Alan, because of cc-mode
  lineage.


In this case it makes sense for me to add only the tree-sitter variant,
found here [0].


For 'typescript-mode', it isn't feasible to enter the most use variant
into core because of copyright issues, but more importantly, it has some
very long-standing unfixed issues that are impossible to solve.

- tsx cannot be supported reliably by js-mode derivation because it uses
  same syntax for types and tsx ( <, >).  This is handled just fine by
  tree-sitter.  Same for template string literals.

- The tree-sitter variant is made by me and Jostein (CC'd) [1], so there are
  no issues there with assignment.


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.

What do you think?

Theo

[0]: https://git.sr.ht/~theo/tree-sitter-modes/tree/master/item/csharp-mode.el
[1]: 
https://git.sr.ht/~theo/tree-sitter-modes/tree/master/item/typescript-mode.el