From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Call for volunteers: add tree-sitter support to major modes Date: Mon, 10 Oct 2022 08:55:06 +0300 Message-ID: <83o7uki5ol.fsf@gnu.org> References: <83czb1jrm3.fsf@gnu.org> <878rlo7on0.fsf@thornhill.no> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="849"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Theodor Thornhill , Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Oct 10 07:56:23 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 1ohlm3-000AXE-0u for ged-emacs-devel@m.gmane-mx.org; Mon, 10 Oct 2022 07:56:23 +0200 Original-Received: from localhost ([::1]:46984 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ohlm1-0001d4-HG for ged-emacs-devel@m.gmane-mx.org; Mon, 10 Oct 2022 01:56:21 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35624) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ohlkm-0000qd-MJ for emacs-devel@gnu.org; Mon, 10 Oct 2022 01:55:04 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:45136) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ohlkl-0001Io-Tf; Mon, 10 Oct 2022 01:55:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=c56Rivqp78krBUpapwtcWgYZhELSVAvIUiTM5BFMChg=; b=q+v4QfxfzDFP Jdm/+7tEEiDGbK/VZNPbQgofFvdD3TJ9RD+x/+ludHYzm4A5fA5KxVe7K5WrPjzVPNRUP8A0sO8+K ogQeKmTmJfBCZZB97VnNWce51y1kGlSNf5sfi16wwTKe/254QGl0RTTBvOnqU1wss2W3ExRvvm3as 1IZZBeGCwE3/dgk8fMnFDuuXg0vhGiruXHjSAJdq2u/BxVfJAuAITEd00ai4L6vuGjnHHBdswDucc fwvMKPH0KYzhkqvVLrvVjI4PwUlHGMab+9qKu4Q+a4M9sOT0b0re4q40KhtIKc3bSzjwMoY/hXVOX MGfWn6Ao0T5VUH61YjG53Q==; Original-Received: from [87.69.77.57] (port=4995 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ohlkj-0001Oi-Fz; Mon, 10 Oct 2022 01:55:03 -0400 In-Reply-To: <878rlo7on0.fsf@thornhill.no> (message from Theodor Thornhill on Sun, 09 Oct 2022 22:01:07 +0200) 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:297308 Archived-At: > 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. > 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.