From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#61369: Problem with keeping tree-sitter parse tree up-to-date Date: Sat, 18 Feb 2023 02:11:22 +0200 Message-ID: <52d15d7e-82e9-ca7b-be16-0ccf89d5053c@yandex.ru> References: <1AC63591-F4EF-411F-B554-7CD38B4B4888@gmail.com> <9c4e551b-42b3-8202-ccff-fb8170b616a6@yandex.ru> <7751EE35-F5FF-418B-AF28-F1FF5ECEF3AE@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37395"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Cc: Theodor Thornhill , 61369@debbugs.gnu.org To: Yuan Fu Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Feb 18 01:12:20 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 1pTApv-0009XT-Sz for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 18 Feb 2023 01:12:19 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pTAph-0007lg-9f; Fri, 17 Feb 2023 19:12: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 1pTApe-0007kG-O9 for bug-gnu-emacs@gnu.org; Fri, 17 Feb 2023 19:12: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 1pTApe-0000Rc-FG for bug-gnu-emacs@gnu.org; Fri, 17 Feb 2023 19:12:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pTApe-0007D9-1W for bug-gnu-emacs@gnu.org; Fri, 17 Feb 2023 19:12:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 18 Feb 2023 00:12:02 +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.167667909227677 (code B ref 61369); Sat, 18 Feb 2023 00:12:02 +0000 Original-Received: (at 61369) by debbugs.gnu.org; 18 Feb 2023 00:11:32 +0000 Original-Received: from localhost ([127.0.0.1]:41886 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pTApA-0007CL-AD for submit@debbugs.gnu.org; Fri, 17 Feb 2023 19:11:32 -0500 Original-Received: from mail-wr1-f48.google.com ([209.85.221.48]:41541) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pTAp8-0007C7-Aa for 61369@debbugs.gnu.org; Fri, 17 Feb 2023 19:11:30 -0500 Original-Received: by mail-wr1-f48.google.com with SMTP id i15so2408698wry.8 for <61369@debbugs.gnu.org>; Fri, 17 Feb 2023 16:11:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=VAuWSqJ0jWOUE/VurEJYQUAInvJmTyU6TSrwqBdoH4g=; b=LLhKHdrirC8y/8iEsAwyXNSTON8qgNL9tM3O5954DOMxZD8+FAVRshF/5M36guRzDA fLeUaP7yZ56nIn1w1iCop7uehemltkBlO/fNMKV3MRIxQnq8W2JtHtj5XiTl0a/nGNXB b/xkutB3Wvh1zW0rF6NwETzDFENd0vlqibKO57OxeNOhxW8wN0dvtp0tpyHfEagsT2Jp Qmtu9fLTJFIiz96B1QyUw+cAAelb6/7uC+ievTc6e3UqvShLKqANzmMP6zGJu2NkfmU6 hwLYhrzeon1uI2CK6UhmPD8JwskZe2ppLE9zTbuPZyNV0YvD2lHmHLl048sGB09cxcze nwEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=VAuWSqJ0jWOUE/VurEJYQUAInvJmTyU6TSrwqBdoH4g=; b=tRi0PiuAcno4YdV14JEGj4T7mTNCkwyAtmmX0J6ZgNFmB0LMyVpAEWANIwNU7egtE3 DBPle4DWekca0cJq0YP5vH4wSB7sl8oAJDCzOhexuD2PwUq+akrAUDSzE1Q8a6XGZSKI /FnKCBU2EDDwRwWizH4ApczosjEqrBOrj8tl83WxXKDdilE+sjjMAAtQO2/H8X3cr9dY RUuk7B/G0q3UcNwPDjlJJNwR4VLfOFxfy9ZQIyVKetgUNknxOYn1CeKh8l/V4IklfcCC 9k20yphfSQ/i+0KJg1FMuWXC99dDOdIbSLiTMK9S8GTQNlYLGBywiGqXp79HVWe2YOlx ucUg== X-Gm-Message-State: AO0yUKU+ClV9KyXc+c44S19MdENdFuHq4D16b5vZCLzmu/+XSUtSwAkf 1PEw+xE/InbK2nTgrnHjiQg= X-Google-Smtp-Source: AK7set8v8Rb59RNl/wvdvG6ooFekuyFHfO4xb7yGnPmhSZSljy+h1OamGHtbSNT+sb0FGCKHVh+6WQ== X-Received: by 2002:a5d:6a06:0:b0:2c5:4ffa:ba55 with SMTP id m6-20020a5d6a06000000b002c54ffaba55mr466617wru.69.1676679084349; Fri, 17 Feb 2023 16:11:24 -0800 (PST) Original-Received: from [192.168.0.2] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id r10-20020a5d694a000000b002c5539171d1sm5351475wrw.41.2023.02.17.16.11.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 17 Feb 2023 16:11:23 -0800 (PST) Content-Language: en-US In-Reply-To: <7751EE35-F5FF-418B-AF28-F1FF5ECEF3AE@gmail.com> 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:255914 Archived-At: 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 “tail” 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. It seems like the "repairing" sync used a different range, one that didn't include the character number 68 inserted from the beginning. 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. > I don’t 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. I figured it could be a problem if both old_end_byte and new_end_byte extend past the current restriction. 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. > I pushed this change. Thanks. Good to see it make it in.