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: Tree sitter support for C-like languages Date: Mon, 14 Nov 2022 22:10:06 +0200 Message-ID: <83zgcti9gh.fsf@gnu.org> References: <87tu36em9t.fsf@thornhill.no> <45FD2F78-F15B-488B-9348-A8E298D8AD35@gmail.com> <87v8nmyqqp.fsf@thornhill.no> <834jv4nz2g.fsf@gnu.org> <871qq8hsj1.fsf@thornhill.no> <83iljklzmo.fsf@gnu.org> <87v8nkgcqj.fsf@thornhill.no> <87sfiogcbm.fsf@thornhill.no> <83pmdrkyj7.fsf@gnu.org> <87v8njw5th.fsf@thornhill.no> <83leofkwjm.fsf@gnu.org> <9E9244D3-2EFB-4621-91E0-FC8B8C1C2D52@gmail.com> <186915C1-1C47-43DC-A386-B447A2E7528D@gmail.com> <83h6z1k6z8.fsf@gnu.org> <52D18BA8-C9A8-4E9A-9DDA-76E48744DDC9@gmail.com> <837czxjrxu.fsf@gnu.org> <8BEF109A-A5B3-4CF4-AE07-AEB9388B0A07@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21103"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, theo@thornhill.no, emacs-devel@gnu.org To: Yuan Fu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Nov 15 00:57:51 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 1oujKo-0005Aa-9u for ged-emacs-devel@m.gmane-mx.org; Tue, 15 Nov 2022 00:57:50 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ouihx-0001fb-Ml; Mon, 14 Nov 2022 18:17:42 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ouieL-000389-Ti for emacs-devel@gnu.org; Mon, 14 Nov 2022 18:13:58 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oufmF-0004gY-68; Mon, 14 Nov 2022 15:09:55 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=ml7JrwzyHRvY+05IfAt8mRPQ7FYuQUFYpxUthKk08r4=; b=Mo1Q8gya8SnRD+dKZKXC vzpc2Sd4ifV37mXOESTnIIIxk4bCq0wm+mDhKm6VV9W0mZL2k5UYg3+fvLvn9ImXoEEPqxktWNHb/ 989n5kYBGxwIY/OkdtBFca1hadNcruxIPecxk8BMvgC+NIlPnY+9d3pu64YATufnYdSF5WyvldUvs KXl77uYE+01bTXK8ii/PskgEwd0ExZaVQhSZr4hIeHW/5guViSTbfqLHgwaRveG3kevIdgMsLVYQi nQkUYXpqS+Q94lqK0Iu4Irb65ZDTFusmht6BHtFrpe4pX6sKtfJQh3WR8bqE7I1w9S5OXk25VfsaC qhyGLRkHqe8YGw==; Original-Received: from [87.69.77.57] (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 1oufmE-0007YA-LL; Mon, 14 Nov 2022 15:09:54 -0500 In-Reply-To: <8BEF109A-A5B3-4CF4-AE07-AEB9388B0A07@gmail.com> (message from Yuan Fu on Mon, 14 Nov 2022 11:51:59 -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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:299781 Archived-At: > From: Yuan Fu > Date: Mon, 14 Nov 2022 11:51:59 -0800 > Cc: monnier@iro.umontreal.ca, > theo@thornhill.no, > emacs-devel@gnu.org > > >> Well we update the parse tree and re-parse, but we currently don’t update the nodes created from the old tree. Keeping all nodes updated requires us to track all live nodes and update them whenever the buffer is edited. > > > > I guess I still don't understand what exactly do you mean by "update > > the node". Can you explain that in more detail? > > My bad. So when buffer changes (insert in X, delete from X to Y), we inform tree-sitter of this change by “updating” the tree: > > const TSInputEdit edit = > treesit_prepare_input_edit (start_byte, old_end_byte, new_end_byte); > > ts_tree_edit (tree, &edit); > > Then when we re-parse, tree-sitter knows which part of the buffer has changed and needs to be re-parsed, and only parses those, hence “incremental parsing”. > > Tree-sitter nodes needs similar updates, so that it is in sync with the buffer text. Doesn't the call to ts_tree_edit update those nodes? That is, aren't those nodes a part of the tree that gets updated by the ts_tree_edit call?