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#59630: 29.0.50; treesitter-buffer-root-node doesn't change when changing buffer restriction Date: Fri, 9 Dec 2022 14:13:12 -0800 Message-ID: References: <87zgcc1s1n.fsf@miha-pc> 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="15363"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 59630-done@debbugs.gnu.org, miha@kamnitnik.top To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Dec 09 23:14:16 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 1p3ldH-0003dM-4j for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 09 Dec 2022 23:14:15 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p3ld6-0008RI-R4; Fri, 09 Dec 2022 17:14:05 -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 1p3ld5-0008Qi-13 for bug-gnu-emacs@gnu.org; Fri, 09 Dec 2022 17:14:03 -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 1p3ld4-0007BW-Pr for bug-gnu-emacs@gnu.org; Fri, 09 Dec 2022 17:14:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1p3ld4-0006Xw-L5 for bug-gnu-emacs@gnu.org; Fri, 09 Dec 2022 17:14:02 -0500 In-Reply-To: <87zgcc1s1n.fsf@miha-pc> Resent-From: Yuan Fu Original-Sender: "Debbugs-submit" Resent-To: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Dec 2022 22:14:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: cc-closed 59630 X-GNU-PR-Package: emacs Mail-Followup-To: 59630@debbugs.gnu.org, casouri@gmail.com, miha@kamnitnik.top Original-Received: via spool by 59630-done@debbugs.gnu.org id=D59630.167062400125130 (code D ref 59630); Fri, 09 Dec 2022 22:14:02 +0000 Original-Received: (at 59630-done) by debbugs.gnu.org; 9 Dec 2022 22:13:21 +0000 Original-Received: from localhost ([127.0.0.1]:38828 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p3lcP-0006XG-6r for submit@debbugs.gnu.org; Fri, 09 Dec 2022 17:13:21 -0500 Original-Received: from mail-pl1-f176.google.com ([209.85.214.176]:46897) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p3lcN-0006X7-LQ for 59630-done@debbugs.gnu.org; Fri, 09 Dec 2022 17:13:20 -0500 Original-Received: by mail-pl1-f176.google.com with SMTP id jn7so6290262plb.13 for <59630-done@debbugs.gnu.org>; Fri, 09 Dec 2022 14:13:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:cc:date:message-id:subject:mime-version :content-transfer-encoding:from:from:to:cc:subject:date:message-id :reply-to; bh=OTj27eEBRnRuuJqGiEQRswdcDrUv1pT6vrgAZWTdcrU=; b=Zwv7LQ1D4613ssFbN6p9DvqTmE0JmVfvdFXjOebS6rKvfOtCLAwy0G/tH+o23dGTCf Oo0pCNsRUeyRSGGjaeWXqOscZJbjVhl/4y/9uet4G4BKM4MySBHFDNsaPLt/5PnW3bL6 +vBu6NPDYh/zgdVDCyob1YWwlM2f2BBgqIx7k7d6dGVlJpFzeHxa0DfGAs64PIa8S/62 x80xInHucrZw+DC35lko8zjr1tQk1GtDdnhGRBukCyAPHYFNfyKGFQqNoxO66oXD+qxJ WCrs8fGAKUGE9tcEKt8+IINOuIxNoaAe9dCqhY4B9Tbq9nAKbg18CRBtls5HHLS38AWn t3qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:cc:date:message-id:subject:mime-version :content-transfer-encoding:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=OTj27eEBRnRuuJqGiEQRswdcDrUv1pT6vrgAZWTdcrU=; b=rUGDDoAX67hy+6sgkd5+/V0JxTXF19jdZryDTEe+fMxGGxBITXISbCFvXygTKw9Khs HcJK2IsGxbpBnz1Nkw5YrIbck1gq8iZdFOOYvBYnh8hjR2QxHnjqbCYlOF6+xLkk9+hH 5LBJfopCnyQVpbT9I8Q33QD8nnQVXmG/yt5dgJLIBAqbUSzA32bIkImanxnP96WbxKDk AY2C7tYZXZz9f8ZM+1+6JfN2u03YtW+3e0YKBI4QrvTXc7xzmIISMr5yN+SA9ZIGJRNX yY+EU9QKiSbfHubcmtjNumVIarmLsDR+88gXdUM7xcAFZ8pcCN8LgXDWSNnWjlo91Nr8 bmyg== X-Gm-Message-State: ANoB5pnBPFCUeJ8thYTECaOAY7b53WA2u8P5SDUaWE+29/unbWRFubNX slEGyob2T9C/g8gGiuYQLAt8nVUx/t7yxw== X-Google-Smtp-Source: AA0mqf7m/vwNyJswaPJNaJ+4DvzB1aUq6VKoBBpeKkmad8kf80/B7Qea9FYr+uJy8so09lUUz1qD9Q== X-Received: by 2002:a17:902:b08b:b0:188:d405:63ce with SMTP id p11-20020a170902b08b00b00188d40563cemr6774077plr.24.1670623993944; Fri, 09 Dec 2022 14:13:13 -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 b13-20020a170902650d00b00186b549cdc2sm1770494plk.157.2022.12.09.14.13.13 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Dec 2022 14:13:13 -0800 (PST) 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:250472 Archived-At: Yuan Fu writes: > Eli Zaretskii writes: > >>> From: Yuan Fu >>> Date: Sun, 27 Nov 2022 14:40:41 -0800 >>> Cc: 59630@debbugs.gnu.org, >>> Eli Zaretskii >>>=20 >>> > ELISP> (widen) >>> > ELISP> (treesit-buffer-root-node 'bash) >>> > #>> > (program) >>> > in 1-4> ;; <---- This is not expected, the root node should span = 1-9 >>> >=20 >>> > ELISP> (buffer-string) >>> > "echo '123'" >>>=20 >>> Thanks. We didn=E2=80=99t edit the buffer after widening, so = tree-sitter >>> didn=E2=80=99t reparse and used the old tree, which sees the = narrowed >>> buffer. Eli, what would be a good and reliable way to know that >>> narrowing has changed? I see current_buffer->clip_changed set to 1 >>> in narrow-to-region and widen, but when are they set to 0? >> >> Not sure what exactly are you after. If you want to catch the moment = when >> we change the buffer restriction, you will have to add something to >> Fnarrow_to_region and Fwiden. However, why does tree-sitter need to = know >> about changes in the narrowing, unless it is asked to update = something or >> produce a tree? I thought we decided to update this stuff lazily, = only when >> actually needed? Being sensitive to these changes would require you = to have >> some logic, because a buffer can be narrowed and widened several = times in a >> sequence without any consequences for tree-sitter, and asking the = parser to >> update itself will just burn CPU cycles. So if this is really = needed, let's >> discuss for which purposes and under what conditions. >> >> I actually don't think why we should be worried by the above = scenario; can >> you explain? >> > > We still parse lazily, and narrow/widen wouldn=E2=80=99t affect the = parse tree, > until user requests for a node when the restriction is different from > last time we parsed the buffer. Basically: > > request-node <-- last time we parsed > narrow > widen > narrow > widen > request-node <-- no need to reparse (1) > > request-node <-- last time we parsed > edits-buffer > request-node <-- need to reparse (2) > > request-node <-- last time we parsed > narrow > request-node <-- need to reparse (3) > > Right now in case (3) we don=E2=80=99t reparse the buffer. I have a = reasonable > fix in f794263da20. Closing since I believe this is fixed. Yuan