From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Theodor Thornhill Newsgroups: gmane.emacs.devel Subject: Re: Call for volunteers: add tree-sitter support to major modes Date: Mon, 10 Oct 2022 08:44:56 +0200 Message-ID: <87tu4c5g9j.fsf@thornhill.no> References: <83czb1jrm3.fsf@gnu.org> <878rlo7on0.fsf@thornhill.no> <83o7uki5ol.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10293"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org, jostein@kjonigsen.net To: Eli Zaretskii , Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Oct 10 08:47:38 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ohmZe-0002PR-2v for ged-emacs-devel@m.gmane-mx.org; Mon, 10 Oct 2022 08:47:38 +0200 Original-Received: from localhost ([::1]:38236 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ohmZb-0001RO-LL for ged-emacs-devel@m.gmane-mx.org; Mon, 10 Oct 2022 02:47:36 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57000) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ohmX9-0000MM-2y for emacs-devel@gnu.org; Mon, 10 Oct 2022 02:45:04 -0400 Original-Received: from out0.migadu.com ([94.23.1.103]:45697) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ohmX6-0002Jn-Kq; Mon, 10 Oct 2022 02:45:02 -0400 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thornhill.no; s=key1; t=1665384298; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=UCZMi9GTb2fQNl+blVVkvaMA+SIcLT88GGxSXZ8jM2w=; b=XF/TlsAAoO6eguEmd74eVsBWf25LqJXL8sZgx6blB5x8OMmC+tVcVssmkhohPyq4DuxJ6n 9OB+ag3p94+5ix6d8CYUM56uvhFAL4r5iw4Hhmtx6F5QyETCu8J9EN/AZh4nP5aUPuUqWS OctgP9iN2E017oiDD3UshrXnS+TeX2DMTHEPobNSDB/lc5vZfZp2AOJbzjEl820ymDM/AJ j6+l3G+IFT/qrOtOHkavo5f/6Cu/YTl7rCW0a9eIcjHStba/N3dIwPU7FNUYpnUtxY4uAJ oTvibtyPUR6a5kZ0T9IX0I8ECqGSWEdJEacyaPVqy1imI1zx1yMyQF3L+/Gyzg== In-Reply-To: <83o7uki5ol.fsf@gnu.org> X-Migadu-Flow: FLOW_OUT Received-SPF: pass client-ip=94.23.1.103; envelope-from=theo@thornhill.no; helo=out0.migadu.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:297316 Archived-At: Hi Eli, Eli Zaretskii writes: >> From: Theodor Thornhill >> 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