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: Suggesting that feature/tree-sitter be merged (was Re: Tree-sitter and major mode inheritance) Date: Sat, 19 Nov 2022 15:05:42 +0200 Message-ID: <83fsef857d.fsf@gnu.org> References: <0249C656-21C8-49F2-B979-A1894BF80637@gmail.com> <874juvhoyi.fsf@posteo.net> <83zgcn8i08.fsf@gnu.org> <87sfif43xq.fsf@posteo.net> <83pmdj89cf.fsf@gnu.org> <87fsef3zu9.fsf@posteo.net> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13363"; mail-complaints-to="usenet@ciao.gmane.io" Cc: jostein@secure.kjonigsen.net, casouri@gmail.com, emacs-devel@gnu.org, theo@thornhill.no, jostein@kjonigsen.net To: Philip Kaludercic Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Nov 19 14:06:49 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 1owNYW-0003GO-ND for ged-emacs-devel@m.gmane-mx.org; Sat, 19 Nov 2022 14:06:48 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1owNXi-0003ck-7G; Sat, 19 Nov 2022 08:05:58 -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 1owNXQ-0003WG-Dw for emacs-devel@gnu.org; Sat, 19 Nov 2022 08:05:46 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1owNXP-00026i-HV; Sat, 19 Nov 2022 08:05:39 -0500 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=zhw244LsPyz7SxhcVihG2Bu+LAB78eOBr3Ou+GWk+nQ=; b=lMGipOfNI2+p T+KMve6BgoA98PmwLCLmHMm3J5c/y+P3qFD1M1y3061uDiSHx/6X2CouEmBJn5X1y7FqzjG89Ab5R lfaYckUnkivpc1AJe3tsMluhtnvVYgFzO9jMblBVzmmfTpbpWPXLh/aiasEGQNlLNsDp1HRGxhzoD lIgqo1bYz/HLZnjCY0YqdjreJoQCjJ2q76z83IwPETZ75/eT5tcQk5oa4cN8gv9l16W38NDBbS4B1 HSdRIV/YwchqzkazTmmmvVBS4IcsDaBv3LigxYlHk+3usbu5YZOqE1UVLtbWj13s1Y45MVYABDrqg NupMt8PS/8O91fFhV6hK/Q==; Original-Received: from [87.69.77.57] (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 1owNXN-0003V7-SR; Sat, 19 Nov 2022 08:05:39 -0500 In-Reply-To: <87fsef3zu9.fsf@posteo.net> (message from Philip Kaludercic on Sat, 19 Nov 2022 12:15:10 +0000) 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:300175 Archived-At: > From: Philip Kaludercic > Cc: jostein@secure.kjonigsen.net, casouri@gmail.com, emacs-devel@gnu.org, > theo@thornhill.no, jostein@kjonigsen.net > Date: Sat, 19 Nov 2022 12:15:10 +0000 > > >> IIUC these modes aren't ripe yet, or at least aren't satisfying > >> replacements for the existing modes. > > > > What concretely isn't ripe? > > Jostein said: > > Me and Theodor faced these same issues with "our" C# and TypeScript > major-modes, and the only "clean" way we agreed we could make this > work was to create wholly new implementations. I can come up with many > good, objective reasons for this, but I think Theodor has already > represented this view fairly well. That's Jostein's opinion. We've heard it before, and AFAIU the branch addresses these problems in ways that at least to me look adequate and consistent with how I'd like to see this feature in Emacs 29. In particular, the TypeScript mode in the branch is indeed a separate mode. Any other problems that will be flagged before the release we will handle when they pop up. > > If that was your reasoning, then I think you are three steps ahead of > > where we are, and you are trying to find solutions for problems that > > don't necessarily exist. We should see what concrete problems are > > left after the merge, and take it from there. We have ample time for > > figuring that out and fixing whatever will need fixing. > > You are right, I'll have to test the branch more seriously. Thanks.