From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Yuan Fu Newsgroups: gmane.emacs.bugs Subject: bug#59693: 29.0.50; treesitter in base buffer doesn't respond to modifications in indirect buffer correctly Date: Sun, 4 Dec 2022 15:21:10 -0800 Message-ID: References: <87r0xlbjg6.fsf@miha-pc> <5F7AE71F-0327-409E-BCE9-310E1980C17A@gmail.com> <8335a0lept.fsf@gnu.org> <83y1rqfbms.fsf@gnu.org> <5AEFFFF0-9788-4006-87A6-89AF741A33C4@gmail.com> <83sfhvbohm.fsf@gnu.org> Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15413"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 59693@debbugs.gnu.org, Stefan Monnier , miha@kamnitnik.top To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Dec 05 00:22:15 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1p1yJL-0003qN-HQ for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 05 Dec 2022 00:22:15 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p1yJ9-0006Li-EG; Sun, 04 Dec 2022 18:22:03 -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 1p1yJ8-0006LN-Dv for bug-gnu-emacs@gnu.org; Sun, 04 Dec 2022 18:22:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1p1yJ8-0003ac-6F for bug-gnu-emacs@gnu.org; Sun, 04 Dec 2022 18:22:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1p1yJ8-0004HV-1o for bug-gnu-emacs@gnu.org; Sun, 04 Dec 2022 18:22:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Yuan Fu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 04 Dec 2022 23:22:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 59693 X-GNU-PR-Package: emacs Original-Received: via spool by 59693-submit@debbugs.gnu.org id=B59693.167019608216442 (code B ref 59693); Sun, 04 Dec 2022 23:22:02 +0000 Original-Received: (at 59693) by debbugs.gnu.org; 4 Dec 2022 23:21:22 +0000 Original-Received: from localhost ([127.0.0.1]:60399 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p1yIU-0004H8-CA for submit@debbugs.gnu.org; Sun, 04 Dec 2022 18:21:22 -0500 Original-Received: from mail-pg1-f174.google.com ([209.85.215.174]:45760) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p1yIS-0004H0-8N for 59693@debbugs.gnu.org; Sun, 04 Dec 2022 18:21:21 -0500 Original-Received: by mail-pg1-f174.google.com with SMTP id r18so8961623pgr.12 for <59693@debbugs.gnu.org>; Sun, 04 Dec 2022 15:21:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=/yMhdGqJ0w+ghRIIBrprC4SpKVPpjs4cQVMENhe6byY=; b=J2qks3YChJU1j6ydiLuWM+qjryPzoZfNyUoiQT5Dzpb9kcjrSffgdNbNYCoG2dUQtr iis0gP1dXtZhNvnuAuZWbrp+72qnyVPR5HoO6hcsoxlRuS1DIuwdB+GHqAs8wt70HkyN ywMIJbNLM8eQjAJ1ObUtCB9LAeRtUKGUVrrCckQZCn/kJbHb2OHzkW03F/+NnIiHFTIk dokd5/H6ZeQnLXGU2xjyLZ9pKrHad4YidzZlakQJaS5EYbrenRdZXvywvRDTi8KavsLl UyQuhqDlDMwbgrJJo8hxeYPtgew/FTJlEHaezaOJvh5Ts85eYug/BAG9OMdvQQ2M6HPp ggXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=/yMhdGqJ0w+ghRIIBrprC4SpKVPpjs4cQVMENhe6byY=; b=qJ7YORZCeKs3eoWy6XJvb5SR2rSreIs2K+STuZBDsqRcF8S4oVxRRM4O7EkU5uLv/h BAuqE4xFynHuUFqHAop3cvzdVFso7hWeXyrUNWRwi3FT4FbfZBWQ18wsIrub35A8fwsd PVhiR7yZirFHKtQAaN6A8gGtlTS2zWZxitwVi94oS3gMrdJFAF+sFK2vCQ5GexjJmkFj ThHO8pNp4VP+Rw04Hzgr+HRIMfxjk0AuNzYDe6JppP3P690lO2iMmA0W1z+0ZDUMdg/R EidBoTFJnxyN6iqQXziSaB+u+I6cZ0cZMlP+5K6odM3tLriUQJZwyuBdIQlIX2AcoONR X8jw== X-Gm-Message-State: ANoB5pnfVOVQrLKsVHJhT1108MnzSXr0UfF4LQsSIMTb7BbVSfFJ+eOA +L+Fay1Xj3BPBN4Pw4+HnyQ= X-Google-Smtp-Source: AA0mqf6ylz5GXc/zdwc664QbXRjRbd42NaB7GSccRsrHLIw+GwNxsZrk5EeDAGNrAhh6pAteQBOHyA== X-Received: by 2002:a63:e008:0:b0:46f:5979:8889 with SMTP id e8-20020a63e008000000b0046f59798889mr55255554pgh.119.1670196074068; Sun, 04 Dec 2022 15:21:14 -0800 (PST) Original-Received: from smtpclient.apple (cpe-172-117-161-177.socal.res.rr.com. [172.117.161.177]) by smtp.gmail.com with ESMTPSA id nn7-20020a17090b38c700b001df264610c4sm13229235pjb.0.2022.12.04.15.21.12 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 04 Dec 2022 15:21:13 -0800 (PST) In-Reply-To: <83sfhvbohm.fsf@gnu.org> X-Mailer: Apple Mail (2.3696.120.41.1.1) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:249974 Archived-At: > On Dec 3, 2022, at 11:46 PM, Eli Zaretskii wrote: >=20 >> From: Yuan Fu >> Date: Sat, 3 Dec 2022 23:20:59 -0800 >> Cc: miha@kamnitnik.top, >> 59693@debbugs.gnu.org >>=20 >>>>> We don=E2=80=99t want indirect buffer and base buffers to share = parsers, since they can have different narrowing, and semantically = indirect buffers should share anything but the text with the base = buffer. >>>>=20 >>>> Yes, the parsers should not be shared. >>>>=20 >>>>> How about this: we change current_buffer->parser_list from a plain = list of parsers to a cons (PARSER-LIST . INDIRECT-PARSER-LIST), where = PARSER-LIST is as before. But for base buffers, INDIRECT-PARSER-LIST = includes all the parsers of its indirect buffers; and for indirect = buffers, INDIRECT-PARSER-LIST is nil. >>>>=20 >>>> You can maybe have the indirect buffers in the list, not their = parsers. >>>> That could make it easier to access other treesit-related = information of the >>>> indirect buffers, if needed. >>>=20 >>> Good idea, it=E2=80=99s easier to know when to remove the reference = with buffers, aka when buffer is killed. >>=20 >> I now have a patch that fixes this problem. WDYT? I added a new = buffer field since it=E2=80=99s cleaner than turning ts_parser_list into = a cons, hopefully that=E2=80=99s not frowned upon.=20 >=20 > Thanks. >=20 > If we are adding to the buffer object a field that holds the list of > indirect buffers, then: >=20 > . the name of the field should not include "treesit" in it, and it > shouldn't be conditioned on HAVE_TREE_SITTER I made it tree-sitter specific and stated that it doesn=E2=80=99t = necessarily contain all indirect buffers to simply the implementation. = Right now new indirect buffer are added to the list only when a parser = is created in an indirect buffer. And dead indirect buffers are = discarded only when treesit_record_change runs. Do we really need a = proper indirect buffer list? After all, no one complained about its = absence ever since indirect buffer were added. > . I wonder if a flat list is a good idea, i.e. scalable enough? also, > treesit_reap_indirect_buffers conses a lot as result AFAIK in most cases only a handful of indirect buffer are created, so I = didn=E2=80=99t worry about that. For tree-sitter=E2=80=99s case, we need = to iterate through every indirect buffer anyway so that=E2=80=99s always = O(n). Adding and removing a buffer from the list is O(n) but they are = done infrequently. The add operation is called every time a parser is = created, and the remove operation is called once when an indirect buffer = is killed.=20 We could use a hash table, but I doubt if that=E2=80=99s necessary, at = least while the indirect buffer list is only used for tree-sitter. For = tree-sitter, the common path is when we update each parser of buffer = changes, which is always O(n) regardless of the data structure.=20 > . I vaguely remember that adding built-in fields to the buffer object = had > some caveats, but I don't recall the details (did you bootstrap?) I built from git clean, so yeah. >=20 > Stefan, any comments on this? Are there better ideas of how to track = buffer > text changes in indirect buffers? Specifically, when any one of the base and indirect buffers change, we = want all parsers in all base and indirect buffers to be updated. Yuan=