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: How to add pseudo vector types Date: Tue, 20 Jul 2021 19:45:21 +0300 Message-ID: <83czrd53z2.fsf@gnu.org> References: <83h7gw6pyj.fsf@gnu.org> <45EBF16A-C953-42C7-97D1-3A2BFEF7DD01@gmail.com> <83y2a764oy.fsf@gnu.org> <83v95b60fn.fsf@gnu.org> <00DD5BFE-D14E-449A-9319-E7B725DEBFB3@gmail.com> <83r1fz5xr9.fsf@gnu.org> <86mtqh54wo.fsf@stephe-leake.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12015"; mail-complaints-to="usenet@ciao.gmane.io" Cc: casouri@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Stephen Leake Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jul 20 18:46:20 2021 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 1m5ssu-0002t8-Qh for ged-emacs-devel@m.gmane-mx.org; Tue, 20 Jul 2021 18:46:20 +0200 Original-Received: from localhost ([::1]:50380 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m5sst-0003rT-SI for ged-emacs-devel@m.gmane-mx.org; Tue, 20 Jul 2021 12:46:19 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45574) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m5ss7-0003BV-1X for emacs-devel@gnu.org; Tue, 20 Jul 2021 12:45:32 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:51332) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m5ss5-0005oK-3K; Tue, 20 Jul 2021 12:45:30 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2119 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 1m5ss1-0000gu-1K; Tue, 20 Jul 2021 12:45:28 -0400 In-Reply-To: <86mtqh54wo.fsf@stephe-leake.org> (message from Stephen Leake on Tue, 20 Jul 2021 09:25:11 -0700) 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:271383 Archived-At: > From: Stephen Leake > Cc: Yuan Fu , monnier@iro.umontreal.ca, > emacs-devel@gnu.org > Date: Tue, 20 Jul 2021 09:25:11 -0700 > > > In addition, Emacs records (for redisplay purposes) two places in each > > buffer related to changes: the minimum buffer position before which no > > changes were done since last redisplay, and the maximum buffer > > position beyond which there were no changes. This can also be used to > > pass only a small part of the buffer to the parser, because the rest > > didn't change. > > Again, the input to tree-sitter is a list of changes, not a block of > text containing changes. I fail to see the significance of the difference. Surely, you could hand it a block of text with changes to mean that this block replaces the previous version of that block. It might take the parser more work to update the parse tree in this case, but if it's fast enough, that won't be the problem. Right? > If the parser is in an Emacs module, so it has direct access to the > buffer, then the hooks only need to record the buffer positions of the > insertions and deletions, not the new text. That should be very fast. (You are talking about the undo-list.) But even this is wasteful: it is quite customary to delete, then re-insert, then re-delete again, etc. several times. So collecting these operations will produce much more "changes" than strictly needed. That's why I'm trying to find a simpler, less wasteful strategies. Since TS is very fast, we can trade some of the speed for simpler, more scalable design of tracking changes.