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 11:34:01 +0300 Message-ID: <83a662g3nq.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> <83czayg5eq.fsf@gnu.org> <87mta2ixob.fsf@yahoo.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12370"; 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 11:02:28 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 1oiB9g-00033H-H2 for ged-emacs-devel@m.gmane-mx.org; Tue, 11 Oct 2022 11:02:28 +0200 Original-Received: from localhost ([::1]:40638 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oiB9f-0006UD-5h for ged-emacs-devel@m.gmane-mx.org; Tue, 11 Oct 2022 05:02:27 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34154) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oiAi4-0000pM-Se for emacs-devel@gnu.org; Tue, 11 Oct 2022 04:33:56 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:49682) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oiAi3-0006V3-J3; Tue, 11 Oct 2022 04:33:55 -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=ws+HCbOtffWaf59R+o/1+dcg3xOXW2pQxdF7DxoZJy4=; b=S6TjzAvJKIkc JSoRYVCpE/bHo37d8pnhq5bgUWj8FgOXOjAv454KaNiaJQLY4Cfk557YT2W1YV89D5u0vZrEPMk/P mgjLNMk3CZd16pbaTrmbiJl7QUO6uP1dd/eOYDAuIpwdFzSfr0+scu1W2taJ4v0G6dxC9XZ/LJR61 DZjSzuqjvsnQgyAi8c553ocTwZUliIJB3Nl64uuPQGllPZAnRcUBoPzwdotvNMI6cnTVdjB09ZlJ+ uiC4OvZUjljcGOqWFvnchaXwWkdWM1zybuyydOt+O3XwYpjgQKf2HZlNRmmpIsIXuhYYig0C5jTQ0 2QRis6ngS1f6G5MOeV7Scg==; Original-Received: from [87.69.77.57] (port=4173 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 1oiAi2-0003Ll-0u; Tue, 11 Oct 2022 04:33:55 -0400 In-Reply-To: <87mta2ixob.fsf@yahoo.com> (message from Po Lu on Tue, 11 Oct 2022 16:15:00 +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:297459 Archived-At: > From: Po Lu > Cc: theo@thornhill.no, acm@muc.de, emacs-devel@gnu.org, > jostein@kjonigsen.net > Date: Tue, 11 Oct 2022 16:15:00 +0800 > > Eli Zaretskii writes: > > > Only as long as you use Latin scripts. > > Or CJK ones, which work perfectly fine without HarfBuzz text shaping. > I have no experience with others. Well, Emacs supports, and will continue to support, many others. > > And even there, we want to support typographic ligatures and other > > features of modern fonts. > > Typographic ligatures and modern fonts are also orthogonal to editing > code No, they aren't: witness the requests to support ligatures in program sources, which are driven by modern fonts like Iosevka and FiraCode. > > 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. > > But why would package.el and similar features be an integral part of any > development environment? Can you imagine a development environment nowadays that is unable to update or upgrade optional packages or install new optional packages? I can't. > Remove networking support and TLS from Emacs, and people will still use > it. Then, delete (or slowly waste away) CC Mode, and almost all of our > users will disappear. I think both will cause users to disappear. But we can argue about this till Kingdom Come, because such an experiment will never happen. > > 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 difference between Semantic and tree-sitter is that Semantic is > comparatively slow, and written in Emacs Lisp, while the latter is > written in C, a much faster language with multiple higher quality > implementations. You see only the aspects that support your POV, and dismiss the rest. One aspect you ignore is the fact that Semantic is where it is today because people who developed it stopped its development. This is directly relevant to your proposal to develop parsing capabilities as part of Emacs -- the result in the long run will be the same, because no one stays in Emacs development forever. By contrast, using external implementations of technologies which are important to IDEs has a much higher chance of finding Free Software implementations that we can use, even if some of them become defunct. > CC Mode barely qualifies as "language parsing technology." Yes, and look at the problems with which it needs to struggle, and the resulting performance issues. > Not to mention that the scope of CC Mode is really much wider than that > of tree-sitter. i.e. tree-sitter does not provide style guessing > functionality. We will keep the parts that are independent of language parsing. > > 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?? > > What is actually demonstrated is that Emacs Lisp and the existing C > primitives are unsuitable for implementing language parsing technology. That, too. But it's the more general conclusions that matter in the long run.