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: Tue, 11 Oct 2022 10:10:43 +0300 Message-ID: <83ilkqg7ik.fsf@gnu.org> References: <83czb1jrm3.fsf@gnu.org> <878rlo7on0.fsf@thornhill.no> <83o7uki5ol.fsf@gnu.org> <87tu4c5g9j.fsf@thornhill.no> <87k057j7gn.fsf@yahoo.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26988"; mail-complaints-to="usenet@ciao.gmane.io" Cc: theo@thornhill.no, acm@muc.de, emacs-devel@gnu.org, jostein@kjonigsen.net To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Oct 11 09:36: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 1oi9oM-0006sj-JX for ged-emacs-devel@m.gmane-mx.org; Tue, 11 Oct 2022 09:36:22 +0200 Original-Received: from localhost ([::1]:45608 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oi9oL-0004F1-1a for ged-emacs-devel@m.gmane-mx.org; Tue, 11 Oct 2022 03:36:21 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52980) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oi9PR-00043c-Gu for emacs-devel@gnu.org; Tue, 11 Oct 2022 03:10:37 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:39000) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oi9PQ-0007pb-PH; Tue, 11 Oct 2022 03:10:36 -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=VKZULSuvt17JhR6NZvAQhyL1V4SOLk8nNWFClOeL8oM=; b=HHK77Xw2qfjd hhF2DOmc/lk/WApOkn7gkG7gDFY8Ci+ElM1+7uePhij9xEZBamfjTWu/jKtCIRQNDMBLJtQxN4hmo aKiYOGLz7ixdH3t3Qjb6awnVJyqPbPE2sgrcB/pTUZatDy6kIXLoZzxVwaZRwI/JP4Wp2pxfluPNS SDFYGzqMIzvDTBSLX060oYhj22t8hm+pl+WhFYevuOXJjI6TEIwdp1ieWju8PcWYA8j8cx9Bi+eAQ N7DpFwT9IyTklSKkAGZhis3NdcmRSywYc3xqD+Xy78uh417HE6GtwQiRrdBPDv9RXrVpeymCw6Y1s rDLbuYfoU8Y7WkCnwitApg==; Original-Received: from [87.69.77.57] (port=3051 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 1oi9PQ-0005d9-6u; Tue, 11 Oct 2022 03:10:36 -0400 In-Reply-To: <87k057j7gn.fsf@yahoo.com> (message from Po Lu on Tue, 11 Oct 2022 12:43:36 +0800) 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:297435 Archived-At: > From: Po Lu > Cc: Eli Zaretskii , Alan Mackenzie , > emacs-devel@gnu.org, jostein@kjonigsen.net > Date: Tue, 11 Oct 2022 12:43:36 +0800 > > Theodor Thornhill writes: > > > 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. > > In that case, will any of you object if someone writes a parser > generator in C and an implementation of the tree-sitter runtime library > that can be included with Emacs itself (namely, with the copyright > assigned to the FSF?) Yes, I will. It isn't our business to develop language parsers, and we have no hope of keeping up with the technology developments in that area and with new languages being invented, well enough to offer reasonable and modern support in Emacs for editing programs in those languages. It's the same reason why we depend on text shaping engines like HarfBuzz for rendering complex scripts and other typography-related features, on image libraries to display images, on GnuTLS to support TLS connections, etc. etc. We cannot possibly be experts in all of those fields, we don't have the manpower for that. In the case of support for editing programs we actually tried for many years, and the result is before our eyes -- and it's unsatisfactory at best. We should advance Emacs towards leveraging existing technologies, not try developing those technologies in-house, or replacing them by cheap hacks and kludges. > My opinion is that Emacs should not degrade its text editing > capabilities so drastically if a non-system library (i.e. not ncurses or > Xlib) is not present. It is completely impractical to expect us to be able to develop this in-house. If tree-sitter becomes defunct (something that doesn't seem like it will happen any time soon), we will have to find a suitable replacement -- like we did with text-shaping engine, when the FLT library stopped being actively developed. Dealing with these changes in the outside world is an important part of the job of the Emacs maintainers (as is identifying new emerging technologies that can be leveraged for new and enhanced Emacs features). We are doing this part for several years already, and doing it successfully. I see no reason to change that, and all the reasons, including past experience, to keep up. The present font-lock and indentation features based on our own code can remain in Emacs forever, if someone wants a safe fallback for when worse comes to worst. But these implementations are from my POV a dead end: they cannot be developed any further, and for some languages, like C++, are already all but failing to reasonably and efficiently support their complex grammars. Using expertise of others is simply a logical step based on past experience; the decision to develop this in-house would be a step back and a disaster in the long run, IMNSHO.