From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Reliable after-change-functions (via: Using incremental parsing in Emacs) Date: Wed, 01 Apr 2020 19:03:47 +0300 Message-ID: <837dyzyyzg.fsf@gnu.org> References: <83imik1qbq.fsf@gnu.org> <835zek1kpv.fsf@gnu.org> <83v9mkz5oo.fsf@gnu.org> <83pncsym6l.fsf@gnu.org> <4a9d6bb2-458d-89b0-5389-d1f883ef24a1@yandex.ru> <20200401135237.GA6240@ACM> <83d08rz48f.fsf@gnu.org> <5d5e4fac-2f83-455e-d3e0-51b28c27bfb5@yandex.ru> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="38986"; mail-complaints-to="usenet@ciao.gmane.io" Cc: acm@muc.de, casouri@gmail.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca, akrl@sdf.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Apr 01 18:08:55 2020 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 1jJfvC-000A4J-Tm for ged-emacs-devel@m.gmane-mx.org; Wed, 01 Apr 2020 18:08:54 +0200 Original-Received: from localhost ([::1]:34210 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jJfvB-0003Mi-G9 for ged-emacs-devel@m.gmane-mx.org; Wed, 01 Apr 2020 12:08:53 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56405) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jJfqN-0006XU-W3 for emacs-devel@gnu.org; Wed, 01 Apr 2020 12:03:56 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:35390) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1jJfqN-0004CC-7Z; Wed, 01 Apr 2020 12:03:55 -0400 Original-Received: from [176.228.60.248] (port=3943 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jJfqM-0005ob-9S; Wed, 01 Apr 2020 12:03:55 -0400 In-Reply-To: <5d5e4fac-2f83-455e-d3e0-51b28c27bfb5@yandex.ru> (message from Dmitry Gutov on Wed, 1 Apr 2020 18:27:43 +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.io gmane.emacs.devel:246208 Archived-At: > Cc: akrl@sdf.org, casouri@gmail.com, monnier@iro.umontreal.ca, > emacs-devel@gnu.org > From: Dmitry Gutov > Date: Wed, 1 Apr 2020 18:27:43 +0300 > > On 01.04.2020 17:10, Eli Zaretskii wrote: > > But in any case, it should be trivially obvious that avoiding to parse > > the entire buffer will make redisplay faster. We should try doing > > that instead of giving up, even if we think the current fontification > > machinery is slow enough to make the parsing delay not so visible. > > I think it's pointless to argue against the current design of TreeSitter > here, where none of its developers can read it. If by TreeSitter you mean the parser (not the Emacs package which interfaces it), then what I proposed is not against their design, AFAIU. They provide an API through which we can let the parser access the buffer text directly, and they explicitly say that the parser is tolerant to invalid/incomplete syntax trees. And I don't see how it could be any different, since when you start writing code, it takes quite some time before it becomes syntactically complete and valid.