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: Mode names for C-like tree-sitter modes Date: Mon, 14 Nov 2022 11:07:22 +0100 Message-ID: <87tu3126jp.fsf@thornhill.no> References: <3C23FEAC-6550-48BE-91A3-443B44717C40@gmail.com> <1E870C80-8435-4305-8FA1-A5A8FF681E2C@thornhill.no> <9B1731B7-3DF2-48E1-B18F-7E3FBE50B3DB@gmail.com> <2D2E7C73-87BB-4298-B7E1-6D813F8AF407@thornhill.no> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34376"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel , Simen =?utf-8?Q?Heggest=C3=B8yl?= To: Yuan Fu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Nov 15 01:52:41 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 1oukBs-0008hF-Oj for ged-emacs-devel@m.gmane-mx.org; Tue, 15 Nov 2022 01:52:41 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ouir8-0004L2-M5; Mon, 14 Nov 2022 18:27:10 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ouih0-0005mI-1j for emacs-devel@gnu.org; Mon, 14 Nov 2022 18:16:42 -0500 Original-Received: from out2.migadu.com ([2001:41d0:2:aacc::]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ouWNI-0002ab-TO for emacs-devel@gnu.org; Mon, 14 Nov 2022 05:07:35 -0500 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=1668420450; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=vAh0i/liZBzLDMOS/zCNt8bITiEXawUt9+NLvq5RrBI=; b=Efh0RdBBNo/kGK9wtCrAI0/sLfwFXXwZcwhB1xtl+zkzpN9Kn8A0+cYvIjYchtEdC1q28G dxqjmjLnM4XbIT1u9cdaR2G/mQ45sT3ANxZbY2Dkv+CtpyrmraXFkJYRO68TlVqndIs7e3 +PNrwLbYk1GI+HaYzegPps8RawpJf9HAYd0AL+NdvleOqnROS8p1kiQKQNJMwMoLkl+wnU 3T1zWI5H4UCvwYGL19PcYFg5xO6uKVGnITdKaJbA46UtbXbSJEIWkWMChLQnaWXTtBT1QH plBQm4ndI4hwAkg6FQj3q0gh4YQXxZNpBZZwxMU52rbisGbeh52r3a5KOmQRCg== In-Reply-To: <2D2E7C73-87BB-4298-B7E1-6D813F8AF407@thornhill.no> X-Migadu-Flow: FLOW_OUT Received-SPF: pass client-ip=2001:41d0:2:aacc::; envelope-from=theo@thornhill.no; helo=out2.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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:299804 Archived-At: >>>=20 >>>> c-ts-mode--base-mode should probably be a public mode, since the inten= tion (IIUC) is enable users to configure C and C++ together, by adding hook= s to this base-mode. So something like c-base-mode or c-ts-base-mode? >>>>=20 >>>=20 >>> Sure! >>>=20 >>>> CSS and JSON could be merged with current modes, I think. Css-ts-mode = could merge with css-mode, and json-ts-mode could be merged with js-json-mo= de. Or we can just have a dedicated json-mode. >>>>=20 >>>> Theo, WDYT? >>>>=20 >>>=20 >>> That's fine with me. In any case I think we should remove tree-sitter s= upport from js-json-mode (or merge them). I think there exist a json-mode = in both elpa and melpa, adding another isn't the best idea I think.=20 >>>=20 >>> Not sure what is best, really. >> >>Js-json-mode inherits from js-mode, which complicates the matter if tree-= sitter is enabled for js-mode=E2=80=A6 Probably should remove tree-sitter f= rom js-json-mode. Also if we decided cc-mode and tree-sitter should be mutu= ally exclusive (which we kind of have), we should remove some cc-mode init = in js-mode that runs even when tree-sitter is enabled. >> > > Strong agree there :) > >>The json-mode you mentioned is on ELPA, and is fairly small, we might be = able to merge json-ts-mode with it. Simen, WDYT? >> >>>=20 >>> My vote goes to merging css and keeping others separate, but I don't ha= ve the strongest opinion there.=20 >>>=20 >>> I can prepare such a patch after we decide on something. >> >>I can also do it, that=E2=80=99ll save us some patching and merging ;-) >> >>Yuan > > If that causes you less work just go ahead :) > I actually think it makes the most sense to extract javascript ts support into ts-mode.el. And then rename ts-mode.el to js-ts-mode.el. Keep js.el vanilla, avoid tree-sitter altogether there, and keep ourselves headache free. Then these modes also will follow the naming scheme we have now, and will possibly make migration to a different naming scheme easier. It actually makes sense from a tree-sitter perspective, considering that the typescript tree-sitter grammar inherits javascript. We also require js in ts-mode.el, but _only_ for the exported tree-sitter convenience functions. js-ts-mode could also imply javascript-typescript-mode, not just javascript-tree-sitter-mode, which also kindof make sense. What do you think? --=20 Theo