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#61369: Problem with keeping tree-sitter parse tree up-to-date Date: Fri, 17 Feb 2023 17:14:22 -0800 Message-ID: References: <1AC63591-F4EF-411F-B554-7CD38B4B4888@gmail.com> <9c4e551b-42b3-8202-ccff-fb8170b616a6@yandex.ru> <7751EE35-F5FF-418B-AF28-F1FF5ECEF3AE@gmail.com> <52d15d7e-82e9-ca7b-be16-0ccf89d5053c@yandex.ru> Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.300.101.1.3\)) 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="23765"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Theodor Thornhill , 61369@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Feb 18 02:15:25 2023 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 1pTBoz-0005xV-6y for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 18 Feb 2023 02:15:25 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pTBod-0007Zk-J0; Fri, 17 Feb 2023 20:15: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 1pTBoc-0007ZX-Ef for bug-gnu-emacs@gnu.org; Fri, 17 Feb 2023 20:15: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 1pTBoc-0004sx-3w for bug-gnu-emacs@gnu.org; Fri, 17 Feb 2023 20:15:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pTBob-0000Om-Pr for bug-gnu-emacs@gnu.org; Fri, 17 Feb 2023 20:15:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Yuan Fu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 18 Feb 2023 01:15:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 61369 X-GNU-PR-Package: emacs Original-Received: via spool by 61369-submit@debbugs.gnu.org id=B61369.16766828831491 (code B ref 61369); Sat, 18 Feb 2023 01:15:01 +0000 Original-Received: (at 61369) by debbugs.gnu.org; 18 Feb 2023 01:14:43 +0000 Original-Received: from localhost ([127.0.0.1]:41973 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pTBoJ-0000Ny-5E for submit@debbugs.gnu.org; Fri, 17 Feb 2023 20:14:43 -0500 Original-Received: from mail-pl1-f169.google.com ([209.85.214.169]:45037) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pTBoH-0000Nl-Ck for 61369@debbugs.gnu.org; Fri, 17 Feb 2023 20:14:41 -0500 Original-Received: by mail-pl1-f169.google.com with SMTP id b6so3188315plg.11 for <61369@debbugs.gnu.org>; Fri, 17 Feb 2023 17:14:41 -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=xjBWnHpujWbJ3EaYlwqGOiipSJ57WN8m57ecJl7VHzQ=; b=UaV7ABoiN8OzhlMvhjsYMDvKcFjl8kw89ueJJDbTbskeerKW1jaVHt17rFTtzyzqeV VUz+eCr1uLWMVLe1X9HmDZMvihA1e3pxAMOrXrdyPna90pCG8iSBYEjjkgHc6Tw4bo0r SSJxZS/TFTj8WX/hfIxl4LJF9ggEoRKvjAG0bAXwkZ8mThObqZp5CZLT4tlH8aCyB7N0 LiJCKKZgAFK+OLUkgWq4RVP3gbzl9boaw5J4Qu+aEabjyK8g6/T/6l8BHDvZ+1fKJuBa 5Ie3ukcUl54CvBIN6TDfK9iwbKKKwJDkpM5AeifkybRqtmAh31sSupnh4a1RbcaGsTHp FG8A== 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=xjBWnHpujWbJ3EaYlwqGOiipSJ57WN8m57ecJl7VHzQ=; b=vZs4vetfK1BqAxDkEz353+U3lT5A634ogaPc9KgWS/Yj4ry+1Jk0LkQKGE/uHoqeIA hRGqoX9DK/KtUbV3402MA5LWDdiQEUMbU6/6+DF38iU1fp8VJ1EOuAjZ78Vn6yS+fNQ0 SsIrAF7tCt3K5LO3wzF0E1ChD/RcbJ25HfG2aLXHuzd29wQ0ZkUqhliL564l5kOUjzSL U4dXyr3apnQmI0NnTZQsXmFLbpusk1lp56wg7jqQbM1Ndg08yFGW3EnjcgJH8ha+S9di gx52oWdBSNOQwqMnUzWZEnO0ilyz6i5PhDt6xkTRIgvVJxhqJkxwQgwg+fDclMoCksMJ Wr/g== X-Gm-Message-State: AO0yUKX2MAAct5+jexoA7v032Au9oP5SD9Pfbkde4XLmVTqiJJ39jouY pZV/O4V+Pc8uLAaOWQopc7A= X-Google-Smtp-Source: AK7set9TkHS0YZrDH+quIt5md21yxR3XCwRgKy+YUYeWwMxmKkmz4dz45zeZAsGo4Aqql/4ANGb8uQ== X-Received: by 2002:a17:903:187:b0:19a:a6cd:35a8 with SMTP id z7-20020a170903018700b0019aa6cd35a8mr8445133plg.25.1676682875446; Fri, 17 Feb 2023 17:14:35 -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 v8-20020a170902b7c800b001994554099esm6048plz.173.2023.02.17.17.14.34 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Feb 2023 17:14:35 -0800 (PST) In-Reply-To: <52d15d7e-82e9-ca7b-be16-0ccf89d5053c@yandex.ru> X-Mailer: Apple Mail (2.3731.300.101.1.3) 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:255916 Archived-At: > On Feb 17, 2023, at 4:11 PM, Dmitry Gutov wrote: >=20 > On 18/02/2023 00:32, Yuan Fu wrote: >> Thank you very much! I thought that clipping the change into the = fixed visible range, and rely on treesit_sync_visible_region to add back = the clipped =E2=80=9Ctail=E2=80=9D when we extend the visible range = would be equivalent to not clipping, but I guess clipping and re-adding = affects how incremental parsing works inside tree-sitter. >=20 > It seems like the "repairing" sync used a different range, one that = didn't include the character number 68 inserted from the beginning. >=20 > It just synced the 1 or 2 characters at the end of the buffer, the = difference between the computed visible_end and the actual BUF_ZV_BYTE. That should be enough, no? Because other text didn=E2=80=99t change, = they just moved. And tree-sitter should know that they moved. Or maybe = I=E2=80=99m misunderstanding what you mean. >=20 >> I don=E2=80=99t think this change would have any adverse effect, = because if you think of it, inserting text in a narrowed region always = extends the region, rather than pushing text at the end out of the = narrowed region. So the right thing to do here is in fact not clipping = new_end_offset. >=20 > I figured it could be a problem if both old_end_byte and new_end_byte = extend past the current restriction. That should be fine (ie, technically correct), since when we widen, the = clipped text are reparsed by tree-sitter as new text. >=20 > But I'm not sure whether that could actually happen in practice. The = obvious attempts (undo a change outside of the narrowing, or revert the = buffer when narrowing is in effect) didn't play out, but I'm not sure = whether there is an actual hard limit on modifying the text outside of = the current restriction. It is my impression that Emacs in general enforces the narrowing = restriction strictly. And we are still correct when exceptions occur. Yuan=