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:56:13 +0300 Message-ID: <83czayg5eq.fsf@gnu.org> References: <83czb1jrm3.fsf@gnu.org> <878rlo7on0.fsf@thornhill.no> <83o7uki5ol.fsf@gnu.org> <87tu4c5g9j.fsf@thornhill.no> <87k057j7gn.fsf@yahoo.com> <83ilkqg7ik.fsf@gnu.org> <874jwake9u.fsf@yahoo.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18770"; 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 10:23:15 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 1oiAXj-0004gz-Bm for ged-emacs-devel@m.gmane-mx.org; Tue, 11 Oct 2022 10:23:15 +0200 Original-Received: from localhost ([::1]:58144 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oiAXi-0008QS-8c for ged-emacs-devel@m.gmane-mx.org; Tue, 11 Oct 2022 04:23:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50352) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oiA7U-0000gd-71 for emacs-devel@gnu.org; Tue, 11 Oct 2022 03:56:08 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:44112) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oiA7R-0007lQ-So; Tue, 11 Oct 2022 03:56:05 -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=a4Xux3miZ0rUezJyZwyfkcsJ8IR4l6FukXobkRQEdF8=; b=Zu51X459HLFq m+hUGbtdkWF022NWJyHgiP3bNejXgXv2avcFUuKEzIDeJu0MC14g5N77L5kL/D2BoL9qksAsFU11m ggdnzYBrvZRRwxUjZQBZYiuOJ9cbYAlpQH5wQppSIUzbUIxScqzwULO15zq01RisXNLWjh28EigNQ wkRX/cuhWYUalWbH8uJHSWT9DgzqCkxgaIfE2DQYm7lfr8CPL/us4rmXZmv/c1X7P6Z1HTLxrjvwQ 4YYLrKrkms4SPeB7P1mt1US7hEMMFUfsgASM/wbuNhVwL+VyRIaM8J1Z4goZo0fc5OoMtH5L9Wt4o DHCWaTCLXCXsLujDqE3cYw==; Original-Received: from [87.69.77.57] (port=1853 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 1oiA7R-0007jd-7g; Tue, 11 Oct 2022 03:56:05 -0400 In-Reply-To: <874jwake9u.fsf@yahoo.com> (message from Po Lu on Tue, 11 Oct 2022 15:31:09 +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:297447 Archived-At: > From: Po Lu > Cc: theo@thornhill.no, acm@muc.de, emacs-devel@gnu.org, > jostein@kjonigsen.net > Date: Tue, 11 Oct 2022 15:31:09 +0800 > > Eli Zaretskii writes: > > > 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 isn't quite our business to develop mini-gmp either, yet it's also > kept in-tree. I'm okay with removing mini-gmp, if the GMP library is supported on all the platforms we care about. But mini-gmp is from Gnulib, so we don't need to develop or maintain it. > > 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. > > But editing text mostly does not involve editing complex shaped text, Only as long as you use Latin scripts. And even there, we want to support typographic ligatures and other features of modern fonts. > and likewise, TLS connections and image display is mostly orthogonal to > the business of editing text. Emacs is not just a text editor. Networking is nowadays an integral part of any development environment. E.g., package.el would be impossible without TLS connections. > > It is completely impractical to expect us to be able to develop this > > in-house. > > Why? Because we have past experience to indicate that. Look at Semantic, look at CC Mode, etc. My conclusion from that is clear, and it's non-negotiable, not as long as I'm doing this job. > The tree-sitter runtime library is only about 16,000 lines of C > source code and headers, which is less than xdisp.c alone, and only > slightly more than keyboard.c. Yes, and how many people do we have on board who know all of xdisp.c and all of keyboard.c? Exactly zero. Really, how many more examples of this do we need to understand what is and what isn't future-proof for Emacs?? How blind can we be if, based on long and rich past experience such as what we have, we don't realize that developing key technologies in-house is a dead end for us? Are we really _that_ blind?? > > , 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 > > Text shaping is, at least IME, immensely more complicated than > interactive language parsing. I don't see how that matters. Both are outside of our expertise. > > 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. > > That logic could also have been applied to bignums, yet there was no > objection to including mini-gmp. mini-gmp is from Gnulib, so it isn't our maintenance burden. > > 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. > > I'm not disputing that fact, which is why I proposed to write an > *implementation* of tree-sitter for inclusion with Emacs, and not to > develop an equivalent in-house. Sorry, I cannot agree with such a terrible waste of our scarce resources. I cannot prevent anyone from working on whatever they like, but don't expect me to agree to adding such an implementation to the Emacs sources and taking responsibility for its maintenance. It's completely against every goal towards which I worked since I became the Emacs maintainer, and is very wrong for the reasons I already abundantly explained.