From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Using incremental parsing in Emacs Date: Fri, 10 Jan 2020 09:41:54 +0200 Message-ID: <838smfahbx.fsf@gnu.org> References: <83blrkj1o1.fsf@gnu.org> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="67484"; mail-complaints-to="usenet@blaine.gmane.org" Cc: arthur.miller@live.com, emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jan 10 08:43:11 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1ipowK-0008cm-MR for ged-emacs-devel@m.gmane-mx.org; Fri, 10 Jan 2020 08:42:40 +0100 Original-Received: from localhost ([::1]:41868 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ipowI-00062D-BK for ged-emacs-devel@m.gmane-mx.org; Fri, 10 Jan 2020 02:42:38 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47129) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ipovf-0004o5-SF for emacs-devel@gnu.org; Fri, 10 Jan 2020 02:42:01 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:42633) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ipove-0006hE-1d; Fri, 10 Jan 2020 02:41:58 -0500 Original-Received: from [176.228.60.248] (port=3080 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ipovc-0000sg-Nu; Fri, 10 Jan 2020 02:41:57 -0500 In-reply-to: (message from Dmitry Gutov on Fri, 10 Jan 2020 00:56:38 +0300) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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.org gmane.emacs.devel:244168 Archived-At: > Cc: "emacs-devel@gnu.org" > From: Dmitry Gutov > Date: Fri, 10 Jan 2020 00:56:38 +0300 > > (**) Which means that if we try to use Tree-Sitter as-is, our current > practice of defining the language grammar in Lisp would go our of the > window. https://github.com/ubolonton/emacs-tree-sitter demonstrates this > as well: language grammars have to be compiled into a shared library (or > libraries). We would have lots of grammars supplied by the third party, > which is kind of good, but we would lose the ease of experimenting with > them that we have now, or being able to write support for a new > up-and-coming language very quickly. Which a certain fraction of our > users enjoys, AFAIK. If we provide infrastructure for using the likes of Tree-Sitter in core, how long do you think it will take until someone rewrites their JS generator of parse tables in Lisp? And we already have machinery in place for loading external shared objects; it can be extended if necessary to handle loading parse tables. Bottom line: this aspect doesn't sound like a problem to me in the long run. I was rather surprised that they didn't have ELisp parse tables out of the box. > My personal takeaway is that we could really benefit from a lispier > version of this technology, and Someone(tm) should start working on that. Agreed.