From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Po Lu Newsgroups: gmane.emacs.devel Subject: Re: Call for volunteers: add tree-sitter support to major modes Date: Tue, 11 Oct 2022 15:31:09 +0800 Message-ID: <874jwake9u.fsf@yahoo.com> 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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13106"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux) Cc: theo@thornhill.no, acm@muc.de, emacs-devel@gnu.org, jostein@kjonigsen.net To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Oct 11 09:50:11 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 1oiA1i-0003E0-HD for ged-emacs-devel@m.gmane-mx.org; Tue, 11 Oct 2022 09:50:10 +0200 Original-Received: from localhost ([::1]:48458 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oiA1h-0003rL-9A for ged-emacs-devel@m.gmane-mx.org; Tue, 11 Oct 2022 03:50:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45046) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oi9je-0002SE-6t for emacs-devel@gnu.org; Tue, 11 Oct 2022 03:31:30 -0400 Original-Received: from sonic303-20.consmr.mail.ne1.yahoo.com ([66.163.188.146]:39751) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oi9jW-0003H6-O3 for emacs-devel@gnu.org; Tue, 11 Oct 2022 03:31:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1665473480; bh=xi8zQX0d6DQuOTtPCImlNdmwNJvxDnMEaUx1Jgs6tAQ=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=TwMgcXU8/LkRzCUz/RorcLfzQDiHjTQif0TSI++QO7wvq6cifNFjHPfmdBJFAYDptirZvldw0wSp1Q38z6iINXIc5Qf0xgyhj9fyoJFEYIkxex/sikXB0GjIx8HngKQJqzI942kMf+LSCDoClw7TVmSksk1Ph/loVpOEykhY4eZaDCXAFLd+lGKceXlWWbT6Dj0EGYM4eWlKpU782ItkHv0wV38586zwdBzDWmrY5mpHLYQ2MuIiv91UEt2JJKStKGFezv8dUl1uT3Q+PLdPzqUSPNaJTgwQJadXkXT+6yvGA4GrUjgnWHkRpVObKdONUOEWxK6Vw3gRlyoRAd7chg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1665473480; bh=S3ndrngNYipl0+fgMoqqHb/0wuTav2PlYgyMLYeJO4z=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=J1DC1KCWCjJ1e1RQ3RUr+oaLzmx6wjEyxrXkBfIAVSfsX4VwUTzIMZZzZHKzeRo8HRBzucjodiBXnFDDQQk01VNrfpnzyLhNfIiimeeDGK9jHIL8eKJr6IDneKdrCGvsCu1GwsNrOMnVTHk28ADJ8hs6foNoCabS00VptCG/G0kylNJUW8sLHZF7cqa68qXo+N9Wj6xT9N3oLr3mHKeYSDBI11aS4Kbcx03rakDIxMzvb6mwI3s5ZUVnLubigTdkMwBq8l6L5qH82648M5v9hCLHSCeToMktXJQx9zZ3mg9ilWw+Ub37VymApwNdzWmNENfzdABeY5bPYDBOygsH0Q== X-YMail-OSG: VNwRCgwVM1kDgEIGijTdg2aYYhIYyKqtl7wR.NGEpl3lzMxVhr3GCIsSzRkQB85 jPXcjBUjTxwP8.GvjSFyRJdBUHBBflZ5d.KGAWSgDi.GaqX7vzypg16TY3oqi.7qB4KquJmKKxLG MOTin_bZ7DYShnuNGAXNoaQ1Vbn_wyEMgx_EYNuKCy2iOSV1UDvVrdEaBG4xgz6o0YIVKbFojGjk 4SlVOcFutqnSl_rt4U3H54ws31rlz3Fndacv8iPHhUi2zIEf2hnNemfrsF0ZjjwQQBCRAy_vckIV rnyAcHNu9xBsuVEqYD5lgeUUi1JF58pZt2QvqQeyQWqrHI4ImwQ6BXxg4mIB9jB.8xMqW7PhjrHV _iuBzIqVNtp6T_1HOsNH9A1by7rp3.HXNba2KoNkfi1EBhdym1J_tdUir8V8.Jbj0K8Vs4645Xwr GIVmuZj_s1THt_LW4XpUgh9f_k._3J1Vh1.ubhQPYb83_I_CrzaK8yV8QeQJ8SqncH66Is0xssYR 06ibTjJTF4JynEjGa0GoDcSKQAc4J5JUYvMccT1PvRKcYI2Hg8hBiRQezl00fQEl8NZ32upqucO6 Ag8El_NAcXZmsRhmRKY9QRuEUDNEHTLXACWpZN__AX2uaoo9OiYPg1AuRqTvJHXzmD4GP23OGXaJ TQhwlnGV2YVYaMmLjhe.Wkf0dVPXnsnjWuUxDFGZfVzYjyzLlp_QYxiL_u1i8lBMuGpQTMkURgtJ gM9Zy.FTyHSwOTq5v_X1yMKa_6JhzZo7.EPfQqKraqAofhulj28wiHuJCxrrw8x6w2toQEbZY79t E8.qYgfSuEKLLZnbfzkagaWJVoGNhIIgBpdLFUCX2E X-Sonic-MF: Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.ne1.yahoo.com with HTTP; Tue, 11 Oct 2022 07:31:20 +0000 Original-Received: by hermes--production-sg3-785466d859-nkfcl (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID dc511abfa7d1edc3d44b079a071e625a; Tue, 11 Oct 2022 07:31:15 +0000 (UTC) In-Reply-To: <83ilkqg7ik.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 11 Oct 2022 10:10:43 +0300") X-Mailer: WebService/1.1.20740 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Received-SPF: pass client-ip=66.163.188.146; envelope-from=luangruo@yahoo.com; helo=sonic303-20.consmr.mail.ne1.yahoo.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable 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" Xref: news.gmane.io gmane.emacs.devel:297438 Archived-At: 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. > 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, and likewise, TLS connections and image display is mostly orthogonal to the business of editing text. > 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. Then why is mini-gmp kept in-tree? Portable multiple precision arithmetic is at least as complicated (if not more) than tree-sitter, yet mini-gmp is a completely satisfactory solution for people who do not have libgmp installed. mini-tree-sitter would fill the same role: it would expose the same API as tree-sitter, but be small enough for Emacs to include and use when tree-sitter is not available. > It is completely impractical to expect us to be able to develop this > in-house. Why? 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. In addition, the path to the current implementation of tree-sitter is well-trodden, so it can't be that hard to walk down that path again. Such an implementation would be able to make use of existing and new tree-sitter grammars without changes. > If tree-sitter becomes defunct (something that doesn't seem like it > will happen any time soon) Famous last words. > , 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. > 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. > 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.