From unknown Thu Jun 19 14:13:17 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#59693 <59693@debbugs.gnu.org> To: bug#59693 <59693@debbugs.gnu.org> Subject: Status: 29.0.50; treesitter in base buffer doesn't respond to modifications in indirect buffer correctly Reply-To: bug#59693 <59693@debbugs.gnu.org> Date: Thu, 19 Jun 2025 21:13:17 +0000 retitle 59693 29.0.50; treesitter in base buffer doesn't respond to modific= ations in indirect buffer correctly reassign 59693 emacs submitter 59693 miha@kamnitnik.top severity 59693 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 29 15:20:38 2022 Received: (at submit) by debbugs.gnu.org; 29 Nov 2022 20:20:38 +0000 Received: from localhost ([127.0.0.1]:56095 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p075q-0006PX-HJ for submit@debbugs.gnu.org; Tue, 29 Nov 2022 15:20:38 -0500 Received: from lists.gnu.org ([209.51.188.17]:44776) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p075n-0006PQ-PW for submit@debbugs.gnu.org; Tue, 29 Nov 2022 15:20:37 -0500 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 1p075n-0002Sr-KN for bug-gnu-emacs@gnu.org; Tue, 29 Nov 2022 15:20:35 -0500 Received: from kamnitnik.top ([209.250.245.214]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p075k-0004at-8Y for bug-gnu-emacs@gnu.org; Tue, 29 Nov 2022 15:20:35 -0500 From: miha@kamnitnik.top DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kamnitnik.top; s=mail; t=1669753207; bh=QISvWdE432CX0ZjMJ/Sa6FSKEoyZ9TwYHRPZrsjzB8s=; h=From:To:Subject:Date:From; b=lYxGZ8rSKEo6QBUEsCJ9EuWv9S2VaEyh0J8Nkg1NCZ1vcQtKrC8gi06q02lpFWR7B CxKjnHUQQ5d0eQPYQw4vNcr5qE771mc+cVc+ww1mWUlPjZ4Mw/gGyWATYi+DmgLqxn TfwIBjaEgg6tLwIgBrzMGwAW1bXnT6rm6lPCoQMfIGeVeGKaZprN8wDO6MjC0jQuMu ocnZG+BwcB8VQcsAtj8elRpdAr5nm5azcNQsYd3sNAqOWeEqnwg1UqwIDdrSo0rsVo g6xyQ4nfQmNpQiywZUkBa+9mkDRob8H8zfoYTNQQ1RfqW7sXtDhIJwF217+5am6EDx 2uvuZRmu8onhg== To: bug-gnu-emacs@gnu.org Subject: 29.0.50; treesitter in base buffer doesn't respond to modifications in indirect buffer correctly Date: Tue, 29 Nov 2022 21:21:29 +0100 Message-ID: <87r0xlbjg6.fsf@miha-pc> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Received-SPF: pass client-ip=209.250.245.214; envelope-from=miha@kamnitnik.top; helo=kamnitnik.top X-Spam_score_int: 4 X-Spam_score: 0.4 X-Spam_bar: / X-Spam_report: (0.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_SUSPICIOUS_NTLD=0.499, FROM_SUSPICIOUS_NTLD_FP=1.999, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_PDS_OTHER_BAD_TLD=0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-Spam-Score: 2.6 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: *** Welcome to IELM *** Type (describe-mode) or press C-h m for help. ELISP> (set-buffer (get-buffer-create "a")) ELISP> (insert "int main();") ELISP> (require 'treesit) ELISP> (treesit-node-children [...] Content analysis details: (2.6 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 2.0 PDS_OTHER_BAD_TLD Untrustworthy TLDs [URI: kamnitnik.top (top)] -0.0 SPF_HELO_PASS SPF: HELO matches SPF record 0.9 SPF_FAIL SPF: sender does not match SPF record (fail) [SPF failed: Please see http://www.openspf.org/Why?s=mfrom; id=miha%40kamnitnik.top; ip=209.51.188.17; r=debbugs.gnu.org] -2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at https://www.dnswl.org/, medium trust [209.51.188.17 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.51.188.17 listed in wl.mailspike.net] 2.0 FROM_SUSPICIOUS_NTLD_FP From abused NTLD 0.0 FROM_SUSPICIOUS_NTLD From abused NTLD X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.4 (/) --=-=-= Content-Type: text/plain *** Welcome to IELM *** Type (describe-mode) or press C-h m for help. ELISP> (set-buffer (get-buffer-create "a")) ELISP> (insert "int main();") ELISP> (require 'treesit) ELISP> (treesit-node-children (treesit-node-child (treesit-buffer-root-node 'c) 0)) (# # #) This is expected ELISP> (set-buffer (make-indirect-buffer "a" "b")) ELISP> (goto-char (point-min)) ELISP> (insert " ") ELISP> (set-buffer "a") ELISP> (buffer-string) " int main();" ELISP> (treesit-node-children (treesit-node-child (treesit-buffer-root-node 'c) 0)) (# # # #) This is unexpected. If we had called '(insert " ")' in the base buffer "a", we would have got (# # #) Thanks for your hard work. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJHBAEBCAAxFiEEmxVnesoT5rQXvVXnswkaGpIVmT8FAmOGackTHG1paGFAa2Ft bml0bmlrLnRvcAAKCRCzCRoakhWZP/Y5D/932BaBekUnSMzRRWxac9lHO2ioqKOu 071R3kb0PFtLKbSKgFjWMgH9bpwcQnnrohGwlIS5EhY/gXY+QtAjjhewm8DEfFWH RsavOEsqTzlkzLBQvEQ7Uk9MXCgtYJUoapUW6G1ES5MO7gI16IQZJLNVmR4XeV/A ABAmp9KX5wzXFrB4qt1zDUz3vOPDBDJxKI3FllViURBxYEYGYeC/AugMYWqqn+5n Llc5oQqwZM+Benndrsrar2Uq1mBhuArSNdsbC4PgbY0UMWUgkdL/S1nVGP+TGK/2 TxlgUWcfyLy6E9CXQdop5cY7WdEI4F5pjbUcpfGm9domQ0ZruJBl5mYEOrq0mUxA lYbDVNbjwx6gbAeL3/RJfSsilhX4I+mDJ7KjYJApfXZ+6UXKwHY+b3LUUgLKKeQ2 r1p4yqdJjECMg/1WPbTnSm++RH6IuoMlckTSK0CsUBdECxhOz4P+UE+Q3RVTA8ZI M/8vmuP1gEB6rHodX5VvtJmA81rG89xPVZxMrUSW9qITEE7JedImKs9dDjAvv0WN SP0F88q3qrp7Z7xKF08O4rT4e+8mkt9mJ3U6VROOiFTSirG1nA3C8dJXAKDxxFqC A2i1Ukkl+ALlmeSS8daY45gib3KfMpABczfDlrt9YSdqRnze/KGJxHFXNaeo5eQk oeUgsWb12Mmp/g== =BDW5 -----END PGP SIGNATURE----- --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 30 05:17:23 2022 Received: (at 59693) by debbugs.gnu.org; 30 Nov 2022 10:17:23 +0000 Received: from localhost ([127.0.0.1]:60030 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p0K9b-0006yN-5N for submit@debbugs.gnu.org; Wed, 30 Nov 2022 05:17:23 -0500 Received: from mail-pf1-f171.google.com ([209.85.210.171]:42860) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p0K9Z-0006yA-Gh for 59693@debbugs.gnu.org; Wed, 30 Nov 2022 05:17:21 -0500 Received: by mail-pf1-f171.google.com with SMTP id h28so2806675pfq.9 for <59693@debbugs.gnu.org>; Wed, 30 Nov 2022 02:17:21 -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=wols9GYvjglNC34nNLKJt70imeV2QNrH/+hhiE9bq0k=; b=n+sUm/BTW6GsU1e58QvuAjpRU0LhZ4+1G3nCl14VZa34SxqlmZAxYZxZJzNmAmrZfu vkh6VYucDQzq28S6zs1eywDYfZYNYtawaB+cmVLENHnslc/bs/jk3sKbbDS46iF/Gv7e SK9WQ0mdBeCG7YvkeppZxrl0WvGLMBHHl0rS/vvl+Z6JD3uoTObkFUGuOVcTUqZ9Ogi2 aNhqmRhEVw8a0YL/jT/h+sF6jUWuVQdbdLRxms0N34/NfVF2r56vM2X3TGXJgfS5klDw mTSverdJjRolIk6FAp7U/SuedGlxvG7HTbREkcQAzSgsm+mOZdDgzbY6lRRo5bPG/R+L FlIQ== 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=wols9GYvjglNC34nNLKJt70imeV2QNrH/+hhiE9bq0k=; b=HWgHAAAeZYzfRYyGoqQVka2PI78d7GDsxwS5uikz/Jq9GSW0drxMGlOXo5d5drc3Fq o2sDKEa0ny6cgh3o/DO6y1yWZVSD6zeIlwkWeoJX64PATxhUYkTcFABHKavwL3dKdT8U bcVFVk4D3itPSsBNCc3nCRF/QWHtPpk++5zXJ4XDvUSHOkyrTBwbBDMgvhpnn3SeaOGX TfLSbgieHv/RZ8XasO0MilhYtsYZO0dN9HDG3/9Dwcy8fyr3qjml769rU/tUfnwYVvgI LEIYX6GJ4fcKmWn1+0tnatBRI6XalXuZLGRha7MaL4ANFWri1D1yZguYNgnNXWb/Oo2c IFlA== X-Gm-Message-State: ANoB5pmvVARcavX2wjsLDQZohAsn0TUID5i0gtdjKS1SmLAn2xFzY3d8 Y/tt94cy9Ttqat3WWie0NhsAGaXTD6U= X-Google-Smtp-Source: AA0mqf6siZ9vNOnRcQL5CW8OWhlnnxYrMdgOy6wXSSZwSyg3bd3C2CK/RAap46WF44cbxBgmRltdWg== X-Received: by 2002:a63:f850:0:b0:477:f9fa:80cb with SMTP id v16-20020a63f850000000b00477f9fa80cbmr18538357pgj.118.1669803435780; Wed, 30 Nov 2022 02:17:15 -0800 (PST) Received: from smtpclient.apple (cpe-172-117-161-177.socal.res.rr.com. [172.117.161.177]) by smtp.gmail.com with ESMTPSA id pa3-20020a17090b264300b0021870b2c7absm908697pjb.42.2022.11.30.02.17.15 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Nov 2022 02:17:15 -0800 (PST) From: Yuan Fu Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: bug#59693: 29.0.50; treesitter in base buffer doesn't respond to modifications in indirect buffer correctly Message-Id: <5F7AE71F-0327-409E-BCE9-310E1980C17A@gmail.com> Date: Wed, 30 Nov 2022 02:17:14 -0800 To: miha@kamnitnik.top X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Spam-Score: 2.0 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > *** Welcome to IELM *** Type (describe-mode) or press C-h m for help. > ELISP> (set-buffer (get-buffer-create "a")) > ELISP> (insert "int main();") > ELISP> (require 'treesit) > ELISP> (treesit-node [...] Content analysis details: (2.0 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 2.0 PDS_OTHER_BAD_TLD Untrustworthy TLDs [URI: kamnitnik.top (top)] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (casouri[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.210.171 listed in wl.mailspike.net] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.210.171 listed in list.dnswl.org] X-Debbugs-Envelope-To: 59693 Cc: 59693@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) miha@kamnitnik.top writes: > *** Welcome to IELM *** Type (describe-mode) or press C-h m for = help. > ELISP> (set-buffer (get-buffer-create "a")) > ELISP> (insert "int main();") > ELISP> (require 'treesit) > ELISP> (treesit-node-children (treesit-node-child = (treesit-buffer-root-node 'c) 0)) > (# (primitive_type) > in 1-4> # (function_declarator) > in 5-11> #) > > This is expected > > ELISP> (set-buffer (make-indirect-buffer "a" "b")) > ELISP> (goto-char (point-min)) > ELISP> (insert " ") > ELISP> (set-buffer "a") > ELISP> (buffer-string) > " int main();" > > ELISP> (treesit-node-children (treesit-node-child = (treesit-buffer-root-node 'c) 0)) > (# (primitive_type) > in 1-4> # (function_declarator) > in 5-11> # (ERROR) > in 11-12> #) > > This is unexpected. If we had called '(insert " ")' in the base buffer > "a", we would have got > > (# (primitive_type) > in 2-5> # (function_declarator) > in 6-12> #) > > Thanks for your hard work. Thanks! I forgot about indirect buffers... We=E2=80=99ll need to make = sure to use the parsers in the original buffer when user edits the indirect buffer, or something like that. I need to look into how does indirect buffer works. Yuan From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 30 09:06:28 2022 Received: (at 59693) by debbugs.gnu.org; 30 Nov 2022 14:06:28 +0000 Received: from localhost ([127.0.0.1]:32992 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p0NjH-0005bi-Pm for submit@debbugs.gnu.org; Wed, 30 Nov 2022 09:06:28 -0500 Received: from eggs.gnu.org ([209.51.188.92]:38370) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p0NjG-0005bc-VN for 59693@debbugs.gnu.org; Wed, 30 Nov 2022 09:06:27 -0500 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 1p0NjA-0006ML-Aw; Wed, 30 Nov 2022 09:06:20 -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=od9SLiTsmbF/WV5xwaLm9uVOJcWWbi0xGnGHGSWAXqM=; b=WQmRGZQbqj4njKn7ynzZ 3/Yq17MJHqxxWgykOVxdBkPsXGMCEB5vrIq0GkFwjQ/duqo9PN6fwdgGQjX+ggCkweGgef1GFGAaO fSA/RX6ROaNCYDrGRz6abLOi7Qc0NzDmkvycGwdvwIgDAUF7GhUKzsZBS6V0LnC3tcUJDfEZxAP6q r+gKbcYwuTH5vW9CaaRrwSxeTM4dDvxouDWmf2xgJPhRZt1gagFLtEZaef1MB523LGlsMRfkflRPo ERHlRzIlWOe3zpSs7wlvFHMzaTwgtA8j/CK7WFxAx2eN+YOeHLS3r0A3bBPulYq/NUP3vKJ6GggV+ Q89C8sfJgjQiTQ==; 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 1p0Nj9-0000FK-G8; Wed, 30 Nov 2022 09:06:19 -0500 Date: Wed, 30 Nov 2022 16:05:50 +0200 Message-Id: <8335a0lept.fsf@gnu.org> From: Eli Zaretskii To: Yuan Fu In-Reply-To: <5F7AE71F-0327-409E-BCE9-310E1980C17A@gmail.com> (message from Yuan Fu on Wed, 30 Nov 2022 02:17:14 -0800) Subject: Re: bug#59693: 29.0.50; treesitter in base buffer doesn't respond to modifications in indirect buffer correctly References: <87r0xlbjg6.fsf@miha-pc> <5F7AE71F-0327-409E-BCE9-310E1980C17A@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 59693 Cc: 59693@debbugs.gnu.org, miha@kamnitnik.top X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 59693@debbugs.gnu.org > From: Yuan Fu > Date: Wed, 30 Nov 2022 02:17:14 -0800 > > Thanks! I forgot about indirect buffers... We’ll need to make sure to > use the parsers in the original buffer when user edits the indirect > buffer, or something like that. I need to look into how does indirect > buffer works. In the insdel.c hooks where you record changes to buffer text, you should see if the buffer has a base_buffer, and if so, update any parsers of the base buffer as well. From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 02 00:05:58 2022 Received: (at 59693) by debbugs.gnu.org; 2 Dec 2022 05:05:58 +0000 Received: from localhost ([127.0.0.1]:44086 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p0yFG-0007Qz-BU for submit@debbugs.gnu.org; Fri, 02 Dec 2022 00:05:58 -0500 Received: from mail-pg1-f170.google.com ([209.85.215.170]:37863) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p0yFD-0007Qt-Tk for 59693@debbugs.gnu.org; Fri, 02 Dec 2022 00:05:52 -0500 Received: by mail-pg1-f170.google.com with SMTP id v3so3503222pgh.4 for <59693@debbugs.gnu.org>; Thu, 01 Dec 2022 21:05:51 -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=V+ZxkoyDzG3sCIwnQFPSNn3vW4+lnA3ZThborgx4+P0=; b=gbhV29kKBZBNy+WySHABZ6vihca5SiA/86B3cO2ZdbMwzftvF6aYe9rvhzG7h0zAY3 M1+gaZCUIPt4MOjhZELo8wpfD0pITLewcQOHROiUIjlb5KTWTHZwccgh90cEcW5bAHoF 11ZSvr9w8MkDaekZt71cB/rQ/+Ir94QIbpzFlbbonj7MvAJmxUorhrc3gqXXYf+fhGq5 cyhN30E+FGKGmzxQma+4kLd2MXQopZHgC7fANLQCu40LpghdZs7TyYQIGsfAMS4qHBs6 5hMxTJt23IWg7P2nT+UgJapdZFVDpUKVQw9pPV0PxrCsDFvD/fd/IdZZeR/Q8neDRmHW GXpg== 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=V+ZxkoyDzG3sCIwnQFPSNn3vW4+lnA3ZThborgx4+P0=; b=kmlIHyhO2gGCOxF5GrvcGXVfLaarA7g4dHCQ8uKRDqO5UP7W8K82DTVPtMIVfAI656 onO9M/p6jQUIAbSV5xtsPqn7D1dJid6+7FsxERiBsOX/m9L9+AYBLKEoXWo8hsf6AmPo f4XgRlo9O6qr/e7/a12eHIlEMbxjO+I0niQcF/iSm4IDZFoumHPdaRw/fx4rVtY91Ywp KbrJ6/Vb0wD2DFC3tQBM6dwTF8kEQ6MgFvyYA5X7xidTdVikU6Of2SrJq+XQs+fSws71 oaF5BSn162FJgwUl9tKXi+TwBf3tFgOYfWq41t3UE7idiEM9Q5z6kmgyeUwjMKYLq1uc yadQ== X-Gm-Message-State: ANoB5pkW1d8iMPKAqBOQB/crFG0mfi+FaxQsAYPTCqo3s8DT2SJMn+HD ZBME5DjAgFmQOrvfAlhONXIdtc2UthA= X-Google-Smtp-Source: AA0mqf51IPZgS4pZu+RrjugeXfodUeBtk/d2xF7AC61rcMKRtanKb1gaS/P/GfAyEAq3Oh/3sOgr5A== X-Received: by 2002:a63:f545:0:b0:477:e3ce:739c with SMTP id e5-20020a63f545000000b00477e3ce739cmr30213577pgk.363.1669957545710; Thu, 01 Dec 2022 21:05:45 -0800 (PST) Received: from smtpclient.apple (cpe-172-117-161-177.socal.res.rr.com. [172.117.161.177]) by smtp.gmail.com with ESMTPSA id x65-20020a623144000000b0056bfebfa6e4sm4083047pfx.190.2022.12.01.21.05.44 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Dec 2022 21:05:45 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: bug#59693: 29.0.50; treesitter in base buffer doesn't respond to modifications in indirect buffer correctly From: Yuan Fu In-Reply-To: <8335a0lept.fsf@gnu.org> Date: Thu, 1 Dec 2022 21:05:43 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87r0xlbjg6.fsf@miha-pc> <5F7AE71F-0327-409E-BCE9-310E1980C17A@gmail.com> <8335a0lept.fsf@gnu.org> To: Eli Zaretskii X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 59693 Cc: 59693@debbugs.gnu.org, miha@kamnitnik.top X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > On Nov 30, 2022, at 6:05 AM, Eli Zaretskii wrote: >=20 >> Cc: 59693@debbugs.gnu.org >> From: Yuan Fu >> Date: Wed, 30 Nov 2022 02:17:14 -0800 >>=20 >> Thanks! I forgot about indirect buffers... We=E2=80=99ll need to make = sure to >> use the parsers in the original buffer when user edits the indirect >> buffer, or something like that. I need to look into how does indirect >> buffer works. >=20 > In the insdel.c hooks where you record changes to buffer text, you = should > see if the buffer has a base_buffer, and if so, update any parsers of = the > base buffer as well. Actually there=E2=80=99s a little bit of problem. When we edit the base = buffer, we would want to update the parsers in all of its indirect = buffers as well, and AFAICT there is no pointer from base buffer to the = indirect buffer, only the other way around.=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. 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. Then base buffer can update all indirect buffers=E2=80=99 parsers, and = indirect buffer can find its base buffer and update all the parsers, = including the base buffer=E2=80=99s parsers and other indirect = buffers=E2=80=99 parsers. Of course, treesit-parser-create and treesit-parser-delete needs to do = some extra work, but nothing complicated. Yuan= From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 02 03:34:17 2022 Received: (at 59693) by debbugs.gnu.org; 2 Dec 2022 08:34:17 +0000 Received: from localhost ([127.0.0.1]:45333 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p11Uv-0003mK-8e for submit@debbugs.gnu.org; Fri, 02 Dec 2022 03:34:17 -0500 Received: from eggs.gnu.org ([209.51.188.92]:43584) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p11Up-0003mE-Sl for 59693@debbugs.gnu.org; Fri, 02 Dec 2022 03:34:15 -0500 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 1p11Uj-0004ja-0s; Fri, 02 Dec 2022 03:34:05 -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=1KjNOaG5rcLSh1Trp6NVK1E4IWTOmXCGXJnFbyopw44=; b=ZartiHCbRTQDWw4Ncnjh LdMHf6Rzb0Z41PYltNf1K1IE/G05pgNl17seul4cYMDk53mCyZltbWjVR3HwiHdtlAyZTCiCethM+ ym+hc6UL3TwE/zDuPzUknfkanMLAT4EIpwgQkQkJcC+7h81O8vqFt6EqcGnSAWTRbKzKiaLXQU2ic gwpbK5AYRSp3jbcITC9EoftdHa2eq6xD35QNRf9zkTjgdu47b+NXyip6jhbXtyh3FlxCnIjvmatgV vPTgf7G8mnrIFo652MRcxjPXNByCduWFxsQ/dsAy1LhEqyh+5Pq9WS4VwZK13DgrsLj4dT2GUDZE7 X+X6NucnUPLlBQ==; 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 1p11Ua-0001ZV-I4; Fri, 02 Dec 2022 03:34:04 -0500 Date: Fri, 02 Dec 2022 10:33:31 +0200 Message-Id: <83y1rqfbms.fsf@gnu.org> From: Eli Zaretskii To: Yuan Fu In-Reply-To: (message from Yuan Fu on Thu, 1 Dec 2022 21:05:43 -0800) Subject: Re: bug#59693: 29.0.50; treesitter in base buffer doesn't respond to modifications in indirect buffer correctly References: <87r0xlbjg6.fsf@miha-pc> <5F7AE71F-0327-409E-BCE9-310E1980C17A@gmail.com> <8335a0lept.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -0.3 (/) X-Debbugs-Envelope-To: 59693 Cc: 59693@debbugs.gnu.org, miha@kamnitnik.top X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.3 (-) > From: Yuan Fu > Date: Thu, 1 Dec 2022 21:05:43 -0800 > Cc: miha@kamnitnik.top, > 59693@debbugs.gnu.org > > > In the insdel.c hooks where you record changes to buffer text, you should > > see if the buffer has a base_buffer, and if so, update any parsers of the > > base buffer as well. > > Actually there’s a little bit of problem. When we edit the base buffer, we would want to update the parsers in all of its indirect buffers as well, and AFAICT there is no pointer from base buffer to the indirect buffer, only the other way around. That's not the problem presented by the OP, though. > We don’t 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. Yes, the parsers should not be shared. > 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. 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. From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 02 20:01:46 2022 Received: (at 59693) by debbugs.gnu.org; 3 Dec 2022 01:01:46 +0000 Received: from localhost ([127.0.0.1]:49947 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p1GuY-0008HW-8j for submit@debbugs.gnu.org; Fri, 02 Dec 2022 20:01:46 -0500 Received: from mail-pj1-f54.google.com ([209.85.216.54]:55260) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p1GuW-0008HQ-C9 for 59693@debbugs.gnu.org; Fri, 02 Dec 2022 20:01:45 -0500 Received: by mail-pj1-f54.google.com with SMTP id o12so6409004pjo.4 for <59693@debbugs.gnu.org>; Fri, 02 Dec 2022 17:01:44 -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=ScyDjlOUcXgR0SuyxL6JwXaxS2PQzmmEAL7yesghtb8=; b=JNaT5NLvQVBN8IldRr/OYF1EWyQOUtCBvjdO+eKed80pIEpyCNRrFznrmPDgN2A8DC z6aMVGw7gIAjB3UlZFJwR2/n+CAzi4kWQ1sf1TlJvZdkKr0FTXr/9o3NclXjQUI8AwQB f/hGjk/84bgtlGqqA9vs4+RwsHiZkD3Z5h/VYvPifw13JVQKrhnbyUknaI9HB0T11i/F roGCmsHe+QOylGYJahR+qo85yFUErcHDv9KPQBaeTIZ84GRtIGddwDD1+fq+/1cjkPgy FCcWVL0plb4V+WsctgijINiocJQ5PwEPADuvoGE5yQvobIjKUZoxoBJz8w7PDd4rsbFO TOGA== 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=ScyDjlOUcXgR0SuyxL6JwXaxS2PQzmmEAL7yesghtb8=; b=vZo8UdWiA7wT6kfTmmDanwD3hBl6EwWz0a3UcN+pBaVUHS/apSaIDoNIUgveTpy/VD oId/Xw5+q6zZPlS61fY4p++55OT5sBTrHg1dU37sCUETKwz9mqDsv2NwFuWjREm1gHsR 1asU7k3sHCuYof4zBWL+/tysL5p8w/qU/5zHZhSOSNgjC9YQul+APD5UnnNldfFEX1Ho T4NOrAY+TXWx6aiExOWGrN0TAEcHtQZu9tdG37VZaqFxotr37DczlxAIfMPLR8a2oLRk kEvsWxiLJ8ERKkf5TxvN/hpsCJ8xfBkH5Pds/kqYRp6wIJcdcj80ww5kZpsynfZT42Oe dCbw== X-Gm-Message-State: ANoB5plftIiMjlplfcdFbZeFN0HsqerqAugno6uHJbhZY66U/nqMi2CD ZqULQGXRwcKqL9Rul/MpupE= X-Google-Smtp-Source: AA0mqf4zWYxEeim9nTOubpjpTAJbmwNspxUBqkfqrxezeLnwhjmz70QXqhwOq+wR8d/KmD43sgTAmQ== X-Received: by 2002:a17:90a:de90:b0:219:44f2:8618 with SMTP id n16-20020a17090ade9000b0021944f28618mr25464045pjv.79.1670029298539; Fri, 02 Dec 2022 17:01:38 -0800 (PST) Received: from smtpclient.apple (108-241-83-33.lightspeed.irvnca.sbcglobal.net. [108.241.83.33]) by smtp.gmail.com with ESMTPSA id a14-20020a170902ecce00b00186bc66d2cbsm6203587plh.73.2022.12.02.17.01.37 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Dec 2022 17:01:37 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: bug#59693: 29.0.50; treesitter in base buffer doesn't respond to modifications in indirect buffer correctly From: Yuan Fu In-Reply-To: <83y1rqfbms.fsf@gnu.org> Date: Fri, 2 Dec 2022 17:01:36 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <5AEFFFF0-9788-4006-87A6-89AF741A33C4@gmail.com> References: <87r0xlbjg6.fsf@miha-pc> <5F7AE71F-0327-409E-BCE9-310E1980C17A@gmail.com> <8335a0lept.fsf@gnu.org> <83y1rqfbms.fsf@gnu.org> To: Eli Zaretskii X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Spam-Score: 2.0 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > On Dec 2, 2022, at 12:33 AM, Eli Zaretskii wrote: > >> From: Yuan Fu >> Date: Thu, 1 Dec 2022 21:05:43 -0800 >> Cc: miha@kamnitnik.top, >> 59693@debbugs.gnu.org >> >>> In the insdel.c hooks wher [...] Content analysis details: (2.0 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.216.54 listed in list.dnswl.org] 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 2.0 PDS_OTHER_BAD_TLD Untrustworthy TLDs [URI: kamnitnik.top (top)] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (casouri[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [209.85.216.54 listed in wl.mailspike.net] -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders X-Debbugs-Envelope-To: 59693 Cc: 59693@debbugs.gnu.org, miha@kamnitnik.top X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > On Dec 2, 2022, at 12:33 AM, Eli Zaretskii wrote: >=20 >> From: Yuan Fu >> Date: Thu, 1 Dec 2022 21:05:43 -0800 >> Cc: miha@kamnitnik.top, >> 59693@debbugs.gnu.org >>=20 >>> In the insdel.c hooks where you record changes to buffer text, you = should >>> see if the buffer has a base_buffer, and if so, update any parsers = of the >>> base buffer as well. >>=20 >> Actually there=E2=80=99s a little bit of problem. When we edit the = base buffer, we would want to update the parsers in all of its indirect = buffers as well, and AFAICT there is no pointer from base buffer to the = indirect buffer, only the other way around.=20 >=20 > That's not the problem presented by the OP, though. Yeah, but they are the same problem in spirit, ie, parser not updated = when base/indirect buffer receive changes. >=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. Good idea, it=E2=80=99s easier to know when to remove the reference with = buffers, aka when buffer is killed. Yuan= From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 04 02:21:14 2022 Received: (at 59693) by debbugs.gnu.org; 4 Dec 2022 07:21:14 +0000 Received: from localhost ([127.0.0.1]:55884 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p1jJJ-00081y-Hh for submit@debbugs.gnu.org; Sun, 04 Dec 2022 02:21:13 -0500 Received: from mail-pl1-f179.google.com ([209.85.214.179]:37610) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p1jJH-00081s-GW for 59693@debbugs.gnu.org; Sun, 04 Dec 2022 02:21:12 -0500 Received: by mail-pl1-f179.google.com with SMTP id m4so1269485pls.4 for <59693@debbugs.gnu.org>; Sat, 03 Dec 2022 23:21:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=yZdGWkeMsFAWmcXe4ZS+G4s8weUS4r2oa9Pq7YaWRoc=; b=g8ovlHpTX1Z05Id0v37zYJeAbdkfN7PzMMOPLiWOylWYIvEDPn846BOWfOacKje+gi +h7HojyT1zZaYuszjdRTUzSe2LtQAAlWH2Iyv9K3gKlh7a4UD9YQWGdbSqvzsPXh+jFM epkDr+J3pk0iY8GS/LmQTwMPvubH7NsShQ6cnUurOrmEH02OMH8i7LkWIRyRsD1W2n2c 7Hvf0Lvh2KlQTgPFgrJC/YRH4oS2opVN7ChvWoRhOStgDlIWkAaUSRZECzP1kzJGSOVW 8wckTe8VUUH/TUlLe+dNdKnxALblJe7dR4LMuKkr0DqRVO5u3qYLMf/ynFfGPpHkY6fT +VBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=yZdGWkeMsFAWmcXe4ZS+G4s8weUS4r2oa9Pq7YaWRoc=; b=VIaW2wmHwkewWMhLdIXyCCaclcadOL719hdbTGacYp3LfL7jJ1lhWhADR9d7bFYqow TSfAfx5yoACEhFHyyhzvUAlEvLXRH8NvZdwTlXEnhaxJgt2sGNb4A2/X3qrZ+TVLBf5m KJvrpBCmQED/hapFmZouh2Lzc+HPHi5Voyn9FYvmfxFgQDmtmJnvkOE9vScHL8X0CKfR 80G4jl55/PBnGkAW+km9Ozfh6mmJBGmW+mqfftks2eByTdy+/GFiqvP5KaG+LY4+i7mL dZog5Df427LqGXmi9/6qrIF421P/zJEVxyd06CjtesDA6hdNTLMy/+BncxYVVZV42fZR 8eyQ== X-Gm-Message-State: ANoB5pnkeJMDME4EQfVWfwx3nLjEy5Dpx0LV88GJcCrl8gBw78wMtjJh 7/dZZz6KzpkZdVw/iDJg/LxwqRatVNY= X-Google-Smtp-Source: AA0mqf6kUbgNoCfT++rLoHdk0YQPdlztRBxOWgftpagWilOvy/PWaTnxAEieBdslCDDP0GIdOowUbA== X-Received: by 2002:a17:902:8e85:b0:189:8ec5:93fb with SMTP id bg5-20020a1709028e8500b001898ec593fbmr31155170plb.154.1670138465369; Sat, 03 Dec 2022 23:21:05 -0800 (PST) Received: from smtpclient.apple (cpe-172-117-161-177.socal.res.rr.com. [172.117.161.177]) by smtp.gmail.com with ESMTPSA id d6-20020a170902654600b00188ef3ea2b6sm8225972pln.262.2022.12.03.23.21.03 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 03 Dec 2022 23:21:04 -0800 (PST) From: Yuan Fu Message-Id: Content-Type: multipart/mixed; boundary="Apple-Mail=_BC4D0109-2183-4F34-B0A6-745C75C74423" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: bug#59693: 29.0.50; treesitter in base buffer doesn't respond to modifications in indirect buffer correctly Date: Sat, 3 Dec 2022 23:20:59 -0800 In-Reply-To: <5AEFFFF0-9788-4006-87A6-89AF741A33C4@gmail.com> To: Eli Zaretskii 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> X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Spam-Score: 2.0 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > On Dec 2, 2022, at 5:01 PM, Yuan Fu wrote: > > > >> On Dec 2, 2022, at 12:33 AM, Eli Zaretskii wrote: >> >>> From: Yuan Fu >>> Date: Thu, 1 Dec 2022 21:05:43 -0800 >>> Cc: miha@kamnitnik.top, [...] Content analysis details: (2.0 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 2.0 PDS_OTHER_BAD_TLD Untrustworthy TLDs [URI: kamnitnik.top (top)] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (casouri[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.214.179 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [209.85.214.179 listed in wl.mailspike.net] -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders X-Debbugs-Envelope-To: 59693 Cc: 59693@debbugs.gnu.org, miha@kamnitnik.top X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) --Apple-Mail=_BC4D0109-2183-4F34-B0A6-745C75C74423 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Dec 2, 2022, at 5:01 PM, Yuan Fu wrote: >=20 >=20 >=20 >> On Dec 2, 2022, at 12:33 AM, Eli Zaretskii wrote: >>=20 >>> From: Yuan Fu >>> Date: Thu, 1 Dec 2022 21:05:43 -0800 >>> Cc: miha@kamnitnik.top, >>> 59693@debbugs.gnu.org >>>=20 >>>> In the insdel.c hooks where you record changes to buffer text, you = should >>>> see if the buffer has a base_buffer, and if so, update any parsers = of the >>>> base buffer as well. >>>=20 >>> Actually there=E2=80=99s a little bit of problem. When we edit the = base buffer, we would want to update the parsers in all of its indirect = buffers as well, and AFAICT there is no pointer from base buffer to the = indirect buffer, only the other way around.=20 >>=20 >> That's not the problem presented by the OP, though. >=20 > Yeah, but they are the same problem in spirit, ie, parser not updated = when base/indirect buffer receive changes. >=20 >>=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. 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 Yuan --Apple-Mail=_BC4D0109-2183-4F34-B0A6-745C75C74423 Content-Disposition: attachment; filename=indirect.patch Content-Type: application/octet-stream; x-unix-mode=0644; name="indirect.patch" Content-Transfer-Encoding: quoted-printable =46rom=20cf8b52f5053cc42fac0ddcefc1b2771c5838cb0d=20Mon=20Sep=2017=20= 00:00:00=202001=0AFrom:=20Yuan=20Fu=20=0ADate:=20Sat,=20= 3=20Dec=202022=2021:18:31=20-0800=0ASubject:=20[PATCH=201/3]=20Refactor=20= treesit_record_change=0A=0AThis=20is=20part=20of=20the=20multi-commit=20= change=20to=20support=20indirect=0Abuffers=20(bug#59693).=0A=0ABesides=20= moving=20the=20code=20to=20a=20new=20function,=20I=20also=20removed=20= two=20lines:=0A=0A-=20=20=20=20=20=20CHECK_CONS=20(parser_list);=0A-=20=20= =20=20=20=20treesit_check_parser=20(lisp_parser);=0A=0Abecause=20they=20= could=20signal,=20and=20don't=20really=20make=20sense=20in=20a=20= internal=0Afunction.=20=20If=20we=20really=20want=20the=20checks,=20we=20= could=20add=20easserts.=0A=0A*=20src/treesit.c=20= (treesit_record_change_1):=20New=20function.=0A(treesit_record_change):=20= Move=20bulk=20of=20code=20to=20the=20new=20function.=0A---=0A=20= src/treesit.c=20|=20139=20= ++++++++++++++++++++++++++------------------------=0A=201=20file=20= changed,=2072=20insertions(+),=2067=20deletions(-)=0A=0Adiff=20--git=20= a/src/treesit.c=20b/src/treesit.c=0Aindex=204b150059fac..2ed9c2eafbe=20= 100644=0A---=20a/src/treesit.c=0A+++=20b/src/treesit.c=0A@@=20-690,6=20= +690,75=20@@=20treesit_tree_edit_1=20(TSTree=20*tree,=20ptrdiff_t=20= start_byte,=0A=20=20=20ts_tree_edit=20(tree,=20&edit);=0A=20}=0A=20=0A= +/*=20Update=20each=20parser=20in=20PARSER_LIST.=20=20*/=0A+static=20= inline=20void=0A+treesit_record_change_1=20(Lisp_Object=20parser_list,=20= ptrdiff_t=20start_byte,=0A+=09=09=09=20ptrdiff_t=20old_end_byte,=20= ptrdiff_t=20new_end_byte)=0A+{=0A+=20=20FOR_EACH_TAIL_SAFE=20= (parser_list)=0A+=20=20{=0A+=20=20=20=20Lisp_Object=20lisp_parser=20=3D=20= XCAR=20(parser_list);=0A+=20=20=20=20TSTree=20*tree=20=3D=20XTS_PARSER=20= (lisp_parser)->tree;=0A+=20=20=20=20/*=20See=20comment=20= (ref:visible-beg-null)=20if=20you=20wonder=20why=20we=20don't=0A+=20=20=20= =20=20=20=20update=20visible_beg/end=20when=20tree=20is=20NULL.=20=20*/=0A= +=20=20=20=20if=20(tree=20!=3D=20NULL)=0A+=20=20=20=20=20=20{=0A+=09= eassert=20(start_byte=20<=3D=20old_end_byte);=0A+=09eassert=20= (start_byte=20<=3D=20new_end_byte);=0A+=09/*=20Think=20the=20recorded=20= change=20as=20a=20delete=20followed=20by=20an=0A+=09=20=20=20insert,=20= and=20think=20of=20them=20as=20moving=20unchanged=20text=20back=0A+=09=20= =20=20and=20forth.=20=20After=20all,=20the=20whole=20point=20of=20= updating=20the=0A+=09=20=20=20tree=20is=20to=20update=20the=20position=20= of=20unchanged=20text.=20=20*/=0A+=09ptrdiff_t=20visible_beg=20=3D=20= XTS_PARSER=20(lisp_parser)->visible_beg;=0A+=09ptrdiff_t=20visible_end=20= =3D=20XTS_PARSER=20(lisp_parser)->visible_end;=0A+=09eassert=20= (visible_beg=20>=3D=200);=0A+=09eassert=20(visible_beg=20<=3D=20= visible_end);=0A+=0A+=09/*=20AFFECTED_START/OLD_END/NEW_END=20are=20= (0-based)=20offsets=20from=0A+=09=20=20=20VISIBLE_BEG.=20=20= min(visi_end,=20max(visi_beg,=20value))=20clips=0A+=09=20=20=20value=20= into=20[visi_beg,=20visi_end],=20and=20subtracting=20visi_beg=0A+=09=20=20= =20gives=20the=20offset=20from=20visi_beg.=20=20*/=0A+=09ptrdiff_t=20= start_offset=20=3D=20(min=20(visible_end,=0A+=09=09=09=09=20=20=20=20=20=20= =20max=20(visible_beg,=20start_byte))=0A+=09=09=09=09=20=20-=20= visible_beg);=0A+=09ptrdiff_t=20old_end_offset=20=3D=20(min=20= (visible_end,=0A+=09=09=09=09=09=20max=20(visible_beg,=20old_end_byte))=0A= +=09=09=09=09=20=20=20=20-=20visible_beg);=0A+=09ptrdiff_t=20= new_end_offset=20=3D=20(min=20(visible_end,=0A+=09=09=09=09=09=20max=20= (visible_beg,=20new_end_byte))=0A+=09=09=09=09=20=20=20=20-=20= visible_beg);=0A+=09eassert=20(start_offset=20<=3D=20old_end_offset);=0A= +=09eassert=20(start_offset=20<=3D=20new_end_offset);=0A+=0A+=09= treesit_tree_edit_1=20(tree,=20start_offset,=20old_end_offset,=0A+=09=09=09= =20=20=20=20=20new_end_offset);=0A+=09XTS_PARSER=20= (lisp_parser)->need_reparse=20=3D=20true;=0A+=09XTS_PARSER=20= (lisp_parser)->timestamp++;=0A+=0A+=09/*=20VISIBLE_BEG/END=20records=20= tree-sitter's=20range=20of=20view=20in=0A+=09=20=20=20the=20buffer.=20=20= We=20need=20to=20adjust=20them=20when=20tree-sitter's=0A+=09=20=20=20= view=20changes.=20=20*/=0A+=09ptrdiff_t=20visi_beg_delta;=0A+=09if=20= (old_end_byte=20>=20new_end_byte)=0A+=09=20=20/*=20Move=20backward.=20=20= */=0A+=09=20=20visi_beg_delta=20=3D=20(min=20(visible_beg,=20= new_end_byte)=0A+=09=09=09=20=20=20=20-=20min=20(visible_beg,=20= old_end_byte));=0A+=09else=0A+=09=20=20/*=20Move=20forward.=20=20*/=0A+=09= =20=20visi_beg_delta=20=3D=20(old_end_byte=20<=20visible_beg=0A+=09=09=09= =20=20=20=20?=20new_end_byte=20-=20old_end_byte=20:=200);=0A+=09= XTS_PARSER=20(lisp_parser)->visible_beg=20=3D=20visible_beg=20+=20= visi_beg_delta;=0A+=09XTS_PARSER=20(lisp_parser)->visible_end=20=3D=20= (visible_end=0A+=09=09=09=09=09=09=20+=20visi_beg_delta=0A+=09=09=09=09=09= =09=20+=20(new_end_offset=0A+=09=09=09=09=09=09=20=20=20=20-=20= old_end_offset));=0A+=09eassert=20(XTS_PARSER=20= (lisp_parser)->visible_beg=20>=3D=200);=0A+=09eassert=20(XTS_PARSER=20= (lisp_parser)->visible_beg=0A+=09=09=20<=3D=20XTS_PARSER=20= (lisp_parser)->visible_end);=0A+=20=20=20=20=20=20}=0A+=20=20}=0A+}=0A+=0A= =20/*=20Update=20each=20parser's=20tree=20after=20the=20user=20made=20an=20= edit.=20=20This=0A=20=20=20=20function=20does=20not=20parse=20the=20= buffer=20and=20only=20updates=20the=20tree,=20so=20it=0A=20=20=20=20= should=20be=20very=20fast.=20=20*/=0A@@=20-697,74=20+766,10=20@@=20= treesit_tree_edit_1=20(TSTree=20*tree,=20ptrdiff_t=20start_byte,=0A=20= treesit_record_change=20(ptrdiff_t=20start_byte,=20ptrdiff_t=20= old_end_byte,=0A=20=09=09=20=20=20=20=20=20=20ptrdiff_t=20new_end_byte)=0A= =20{=0A-=20=20Lisp_Object=20parser_list;=0A+=20=20Lisp_Object=20= parser_list=20=3D=20BVAR=20(current_buffer,=20ts_parser_list);=0A+=20=20= treesit_record_change_1=20(parser_list,=20start_byte,=0A+=09=09=09=20=20=20= old_end_byte,=20new_end_byte);=0A=20=0A-=20=20parser_list=20=3D=20BVAR=20= (current_buffer,=20ts_parser_list);=0A-=0A-=20=20FOR_EACH_TAIL_SAFE=20= (parser_list)=0A-=20=20=20=20{=0A-=20=20=20=20=20=20CHECK_CONS=20= (parser_list);=0A-=20=20=20=20=20=20Lisp_Object=20lisp_parser=20=3D=20= XCAR=20(parser_list);=0A-=20=20=20=20=20=20treesit_check_parser=20= (lisp_parser);=0A-=20=20=20=20=20=20TSTree=20*tree=20=3D=20XTS_PARSER=20= (lisp_parser)->tree;=0A-=20=20=20=20=20=20/*=20See=20comment=20= (ref:visible-beg-null)=20if=20you=20wonder=20why=20we=20don't=0A-=20=20=20= =20=20=20update=20visible_beg/end=20when=20tree=20is=20NULL.=20=20*/=0A-=20= =20=20=20=20=20if=20(tree=20!=3D=20NULL)=0A-=09{=0A-=09=20=20eassert=20= (start_byte=20<=3D=20old_end_byte);=0A-=09=20=20eassert=20(start_byte=20= <=3D=20new_end_byte);=0A-=09=20=20/*=20Think=20the=20recorded=20change=20= as=20a=20delete=20followed=20by=20an=0A-=09=20=20=20=20=20insert,=20and=20= think=20of=20them=20as=20moving=20unchanged=20text=20back=0A-=09=20=20=20= =20=20and=20forth.=20=20After=20all,=20the=20whole=20point=20of=20= updating=20the=0A-=09=20=20=20=20=20tree=20is=20to=20update=20the=20= position=20of=20unchanged=20text.=20=20*/=0A-=09=20=20ptrdiff_t=20= visible_beg=20=3D=20XTS_PARSER=20(lisp_parser)->visible_beg;=0A-=09=20=20= ptrdiff_t=20visible_end=20=3D=20XTS_PARSER=20(lisp_parser)->visible_end;=0A= -=09=20=20eassert=20(visible_beg=20>=3D=200);=0A-=09=20=20eassert=20= (visible_beg=20<=3D=20visible_end);=0A-=0A-=09=20=20/*=20= AFFECTED_START/OLD_END/NEW_END=20are=20(0-based)=20offsets=20from=0A-=09=20= =20=20=20=20VISIBLE_BEG.=20=20min(visi_end,=20max(visi_beg,=20value))=20= clips=0A-=09=20=20=20=20=20value=20into=20[visi_beg,=20visi_end],=20and=20= subtracting=20visi_beg=0A-=09=20=20=20=20=20gives=20the=20offset=20from=20= visi_beg.=20=20*/=0A-=09=20=20ptrdiff_t=20start_offset=20=3D=20(min=20= (visible_end,=0A-=09=09=09=09=09=20max=20(visible_beg,=20start_byte))=0A= -=09=09=09=09=20=20=20=20-=20visible_beg);=0A-=09=20=20ptrdiff_t=20= old_end_offset=20=3D=20(min=20(visible_end,=0A-=09=09=09=09=09=20=20=20= max=20(visible_beg,=20old_end_byte))=0A-=09=09=09=09=20=20=20=20=20=20-=20= visible_beg);=0A-=09=20=20ptrdiff_t=20new_end_offset=20=3D=20(min=20= (visible_end,=0A-=09=09=09=09=09=20=20=20max=20(visible_beg,=20= new_end_byte))=0A-=09=09=09=09=20=20=20=20=20=20-=20visible_beg);=0A-=09=20= =20eassert=20(start_offset=20<=3D=20old_end_offset);=0A-=09=20=20eassert=20= (start_offset=20<=3D=20new_end_offset);=0A-=0A-=09=20=20= treesit_tree_edit_1=20(tree,=20start_offset,=20old_end_offset,=0A-=09=09=09= =20=20=20=20=20=20=20new_end_offset);=0A-=09=20=20XTS_PARSER=20= (lisp_parser)->need_reparse=20=3D=20true;=0A-=09=20=20XTS_PARSER=20= (lisp_parser)->timestamp++;=0A-=0A-=09=20=20/*=20VISIBLE_BEG/END=20= records=20tree-sitter's=20range=20of=20view=20in=0A-=09=20=20=20=20=20= the=20buffer.=20=20We=20need=20to=20adjust=20them=20when=20tree-sitter's=0A= -=09=20=20=20=20=20view=20changes.=20=20*/=0A-=09=20=20ptrdiff_t=20= visi_beg_delta;=0A-=09=20=20if=20(old_end_byte=20>=20new_end_byte)=0A-=09= =20=20=20=20/*=20Move=20backward.=20=20*/=0A-=09=20=20=20=20= visi_beg_delta=20=3D=20(min=20(visible_beg,=20new_end_byte)=0A-=09=09=09=20= =20=20=20=20=20-=20min=20(visible_beg,=20old_end_byte));=0A-=09=20=20= else=0A-=09=20=20=20=20/*=20Move=20forward.=20=20*/=0A-=09=20=20=20=20= visi_beg_delta=20=3D=20(old_end_byte=20<=20visible_beg=0A-=09=09=09=20=20= =20=20=20=20?=20new_end_byte=20-=20old_end_byte=20:=200);=0A-=09=20=20= XTS_PARSER=20(lisp_parser)->visible_beg=20=3D=20visible_beg=20+=20= visi_beg_delta;=0A-=09=20=20XTS_PARSER=20(lisp_parser)->visible_end=20=3D=20= (visible_end=0A-=09=09=09=09=09=09=20=20=20+=20visi_beg_delta=0A-=09=09=09= =09=09=09=20=20=20+=20(new_end_offset=0A-=09=09=09=09=09=09=20=20=20=20=20= =20-=20old_end_offset));=0A-=09=20=20eassert=20(XTS_PARSER=20= (lisp_parser)->visible_beg=20>=3D=200);=0A-=09=20=20eassert=20= (XTS_PARSER=20(lisp_parser)->visible_beg=0A-=09=09=20=20=20<=3D=20= XTS_PARSER=20(lisp_parser)->visible_end);=0A-=09}=0A-=20=20=20=20}=0A=20= }=0A=20=0A=20/*=20Comment=20(ref:visible-beg-null)=20The=20purpose=20of=20= visible_beg/end=20is=20to=0A--=20=0A2.33.1=0A=0A=0A=46rom=20= 98623c2a5fa6776d63d341c9975f066d6849fff0=20Mon=20Sep=2017=2000:00:00=20= 2001=0AFrom:=20Yuan=20Fu=20=0ADate:=20Sat,=203=20Dec=20= 2022=2021:28:08=20-0800=0ASubject:=20[PATCH=202/3]=20Rename=20= ts_parser_list=20and=20add=20treesit_indirect_list=0A=0AThis=20is=20part=20= of=20the=20multi-commit=20change=20to=20support=20indirect=20buffers=20= in=0Atree-sitter=20(bug#59693).=0A=0Ats_parser_list=20dodged=20the=20= prefix=20rename=20from=20ts_=20to=20treesit_,=20so=20I=0Atook=20the=20= opportunity=20to=20bring=20it=20to=20justice.=0A=0A*=20src/buffer.c=20= (bset_ts_parser_list):=20Rename.=0A(bset_treesit_indirect_list):=20New=20= function.=0A(reset_buffer,=20init_buffer_once):=20Initialize=20= treesit_indirect_list.=0ARename=20ts_parser_list.=0A=0A*=20src/buffer.h=20= (struct=20buffer):=20Add=20treesit_indirect_list.=20=20Rename=0A= ts_parser_list.=0A=0A*=20src/treesit.c=20(treesit_record_change_1)=0A= (Ftreesit_parser_create)=0A(Ftreesit_parser_delete)=0A= (Ftreesit_parser_list):=20Rename=20ts_parser_list.=0A---=0A=20= src/buffer.c=20=20|=2018=20+++++++++++++-----=0A=20src/buffer.h=20=20|=20= =207=20++++++-=0A=20src/treesit.c=20|=2013=20+++++++------=0A=203=20= files=20changed,=2026=20insertions(+),=2012=20deletions(-)=0A=0Adiff=20= --git=20a/src/buffer.c=20b/src/buffer.c=0Aindex=20= 71be7ed9e13..d7dd2c3a2d8=20100644=0A---=20a/src/buffer.c=0A+++=20= b/src/buffer.c=0A@@=20-233,9=20+233,14=20@@=20bset_extra_line_spacing=20= (struct=20buffer=20*b,=20Lisp_Object=20val)=0A=20}=0A=20#ifdef=20= HAVE_TREE_SITTER=0A=20static=20void=0A-bset_ts_parser_list=20(struct=20= buffer=20*b,=20Lisp_Object=20val)=0A+bset_treesit_parser_list=20(struct=20= buffer=20*b,=20Lisp_Object=20val)=0A=20{=0A-=20=20b->ts_parser_list_=20=3D= =20val;=0A+=20=20b->treesit_parser_list_=20=3D=20val;=0A+}=0A+static=20= void=0A+bset_treesit_indirect_list=20(struct=20buffer=20*b,=20= Lisp_Object=20val)=0A+{=0A+=20=20b->treesit_indirect_list_=20=3D=20val;=0A= =20}=0A=20#endif=0A=20static=20void=0A@@=20-1066,7=20+1071,8=20@@=20= reset_buffer=20(register=20struct=20buffer=20*b)=0A=20=20=20= bset_cursor_type=20(b,=20BVAR=20(&buffer_defaults,=20cursor_type));=0A=20= =20=20bset_extra_line_spacing=20(b,=20BVAR=20(&buffer_defaults,=20= extra_line_spacing));=0A=20#ifdef=20HAVE_TREE_SITTER=0A-=20=20= bset_ts_parser_list=20(b,=20Qnil);=0A+=20=20bset_treesit_parser_list=20= (b,=20Qnil);=0A+=20=20bset_treesit_indirect_list=20(b,=20Qnil);=0A=20= #endif=0A=20=0A=20=20=20b->display_error_modiff=20=3D=200;=0A@@=20= -4692,7=20+4698,8=20@@=20init_buffer_once=20(void)=0A=20=20=20= XSETFASTINT=20(BVAR=20(&buffer_local_flags,=20cursor_type),=20idx);=20= ++idx;=0A=20=20=20XSETFASTINT=20(BVAR=20(&buffer_local_flags,=20= extra_line_spacing),=20idx);=20++idx;=0A=20#ifdef=20HAVE_TREE_SITTER=0A-=20= =20XSETFASTINT=20(BVAR=20(&buffer_local_flags,=20ts_parser_list),=20= idx);=20++idx;=0A+=20=20XSETFASTINT=20(BVAR=20(&buffer_local_flags,=20= treesit_parser_list),=20idx);=20++idx;=0A+=20=20XSETFASTINT=20(BVAR=20= (&buffer_local_flags,=20treesit_indirect_list),=20idx);=20++idx;=0A=20= #endif=0A=20=20=20XSETFASTINT=20(BVAR=20(&buffer_local_flags,=20= cursor_in_non_selected_windows),=20idx);=20++idx;=0A=20=0A@@=20-4763,7=20= +4770,8=20@@=20init_buffer_once=20(void)=0A=20=20=20bset_cursor_type=20= (&buffer_defaults,=20Qt);=0A=20=20=20bset_extra_line_spacing=20= (&buffer_defaults,=20Qnil);=0A=20#ifdef=20HAVE_TREE_SITTER=0A-=20=20= bset_ts_parser_list=20(&buffer_defaults,=20Qnil);=0A+=20=20= bset_treesit_parser_list=20(&buffer_defaults,=20Qnil);=0A+=20=20= bset_treesit_indirect_list=20(&buffer_defaults,=20Qnil);=0A=20#endif=0A=20= =20=20bset_cursor_in_non_selected_windows=20(&buffer_defaults,=20Qt);=0A=20= =0Adiff=20--git=20a/src/buffer.h=20b/src/buffer.h=0Aindex=20= dded0cd98c1..984c5ee4437=20100644=0A---=20a/src/buffer.h=0A+++=20= b/src/buffer.h=0A@@=20-575,7=20+575,12=20@@=20#define=20BVAR(buf,=20= field)=20((buf)->field=20##=20_)=0A=20=0A=20#ifdef=20HAVE_TREE_SITTER=0A=20= =20=20/*=20A=20list=20of=20tree-sitter=20parsers=20for=20this=20buffer.=20= =20*/=0A-=20=20Lisp_Object=20ts_parser_list_;=0A+=20=20Lisp_Object=20= treesit_parser_list_;=0A+=20=20/*=20A=20list=20of=20indirect=20buffers=20= of=20this=20buffer=20whose=20tree-sitter=0A+=20=20=20=20=20parsers=20= wants=20to=20be=20updated=20with=20buffer=20content=20changes.=20=20This=0A= +=20=20=20=20=20list=20does=20not=20necessarily=20include=20all=20= indirect=20buffers=20of=20this=0A+=20=20=20=20=20buffer,=20and=20buffers=20= in=20this=20list=20are=20not=20necessarily=20alive.=20=20*/=0A+=20=20= Lisp_Object=20treesit_indirect_list_;=0A=20#endif=0A=20=20=20/*=20Cursor=20= type=20to=20display=20in=20non-selected=20windows.=0A=20=20=20=20=20=20t=20= means=20to=20use=20hollow=20box=20cursor.=0Adiff=20--git=20= a/src/treesit.c=20b/src/treesit.c=0Aindex=202ed9c2eafbe..9a076be67c5=20= 100644=0A---=20a/src/treesit.c=0A+++=20b/src/treesit.c=0A@@=20-766,7=20= +766,7=20@@=20treesit_record_change_1=20(Lisp_Object=20parser_list,=20= ptrdiff_t=20start_byte,=0A=20treesit_record_change=20(ptrdiff_t=20= start_byte,=20ptrdiff_t=20old_end_byte,=0A=20=09=09=20=20=20=20=20=20=20= ptrdiff_t=20new_end_byte)=0A=20{=0A-=20=20Lisp_Object=20parser_list=20=3D=20= BVAR=20(current_buffer,=20ts_parser_list);=0A+=20=20Lisp_Object=20= parser_list=20=3D=20BVAR=20(current_buffer,=20treesit_parser_list);=0A=20= =20=20treesit_record_change_1=20(parser_list,=20start_byte,=0A=20=09=09=09= =20=20=20old_end_byte,=20new_end_byte);=0A=20=0A@@=20-1279,7=20+1279,7=20= @@=20DEFUN=20("treesit-parser-create",=0A=20=20=20= treesit_check_buffer_size=20(buf);=0A=20=0A=20=20=20/*=20See=20if=20we=20= can=20reuse=20a=20parser.=20=20*/=0A-=20=20for=20(Lisp_Object=20tail=20=3D= =20BVAR=20(buf,=20ts_parser_list);=0A+=20=20for=20(Lisp_Object=20tail=20= =3D=20BVAR=20(buf,=20treesit_parser_list);=0A=20=20=20=20=20=20=20=20= NILP=20(no_reuse)=20&&=20!NILP=20(tail);=0A=20=20=20=20=20=20=20=20tail=20= =3D=20XCDR=20(tail))=0A=20=20=20=20=20{=0A@@=20-1306,7=20+1306,8=20@@=20= DEFUN=20("treesit-parser-create",=0A=20=09=09=09=09=09=09=20language);=0A= =20=0A=20=20=20/*=20Update=20parser-list.=20=20*/=0A-=20=20BVAR=20(buf,=20= ts_parser_list)=20=3D=20Fcons=20(lisp_parser,=20BVAR=20(buf,=20= ts_parser_list));=0A+=20=20Lisp_Object=20buffer_list=20=3D=20BVAR=20= (buf,=20treesit_parser_list);=0A+=20=20BVAR=20(buf,=20= treesit_parser_list)=20=3D=20Fcons=20(lisp_parser,=20buffer_list);=0A=20=0A= =20=20=20return=20lisp_parser;=0A=20}=0A@@=20-1323,8=20+1324,8=20@@=20= DEFUN=20("treesit-parser-delete",=0A=20=20=20Lisp_Object=20buffer=20=3D=20= XTS_PARSER=20(parser)->buffer;=0A=20=20=20struct=20buffer=20*buf=20=3D=20= XBUFFER=20(buffer);=0A=20=0A-=20=20BVAR=20(buf,=20ts_parser_list)=0A-=20=20= =20=20=3D=20Fdelete=20(parser,=20BVAR=20(buf,=20ts_parser_list));=0A+=20=20= BVAR=20(buf,=20treesit_parser_list)=0A+=20=20=20=20=3D=20Fdelete=20= (parser,=20BVAR=20(buf,=20treesit_parser_list));=0A=20=0A=20=20=20= XTS_PARSER=20(parser)->deleted=20=3D=20true;=0A=20=20=20return=20Qnil;=0A= @@=20-1350,7=20+1351,7=20@@=20DEFUN=20("treesit-parser-list",=0A=20=20=20= Lisp_Object=20return_list=20=3D=20Qnil;=0A=20=20=20Lisp_Object=20tail;=0A= =20=0A-=20=20tail=20=3D=20BVAR=20(buf,=20ts_parser_list);=0A+=20=20tail=20= =3D=20BVAR=20(buf,=20treesit_parser_list);=0A=20=0A=20=20=20= FOR_EACH_TAIL=20(tail)=0A=20=20=20=20=20return_list=20=3D=20Fcons=20= (XCAR=20(tail),=20return_list);=0A--=20=0A2.33.1=0A=0A=0A=46rom=20= 6f338f347f737531af8b29776f3745e653710f12=20Mon=20Sep=2017=2000:00:00=20= 2001=0AFrom:=20Yuan=20Fu=20=0ADate:=20Sat,=203=20Dec=20= 2022=2022:55:22=20-0800=0ASubject:=20[PATCH=203/3]=20Update=20= tree-sitter=20parser=20on=20both=20base=20and=20indirect=0A=20buffers=0A=0A= This=20is=20part=20of=20the=20multi-commit=20change=20to=20support=20= indirect=20buffers=20in=0Atree-sitter=20(bug#59693).=0A=0AIn=20this=20= commit=20we=20finally=20share=20the=20buffer=20change=20across=20all=20= base=20and=0Aindirect=20buffers.=20=20I=20also=20fixed=20a=20bug=20in=20= Ftreesit_parser_create=20where=0Awe=20unconditionally=20use=20the=20= current=20buffer=20when=20creating=20the=20parser,=0Aregardless=20of=20= the=20value=20of=20the=20BUFFER=20parameter.=0A=0A*=20src/treesit.c=20= (treesit_reap_indirect_buffers):=20New=20function.=0A= (treesit_record_change):=20Update=20all=20parsers=20in=20both=20the=20= base=20buffer=0Aand=20its=20indirect=20buffers.=0A= (Ftreesit_parser_create):=20Add=20this=20buffer=20to=20its=20base=20= buffer's=0Atreesit_indirect_list.=0A(Ftreesit__indirect_buffer_list):=20= New=20function.=0A=0A*=20test/src/treesit-tests.el=20= (treesit-indirect-buffers):=20New=20test.=0A---=0A=20src/treesit.c=20=20=20= =20=20=20=20=20=20=20=20=20=20|=2090=20= +++++++++++++++++++++++++++++++++++++--=0A=20test/src/treesit-tests.el=20= |=2063=20+++++++++++++++++++++++++++=0A=202=20files=20changed,=20149=20= insertions(+),=204=20deletions(-)=0A=0Adiff=20--git=20a/src/treesit.c=20= b/src/treesit.c=0Aindex=209a076be67c5..c6ee0c3322f=20100644=0A---=20= a/src/treesit.c=0A+++=20b/src/treesit.c=0A@@=20-690,6=20+690,27=20@@=20= treesit_tree_edit_1=20(TSTree=20*tree,=20ptrdiff_t=20start_byte,=0A=20=20= =20ts_tree_edit=20(tree,=20&edit);=0A=20}=0A=20=0A+/*=20Reap=20deleted=20= buffers=20in=20the=20treesit_parser_list=20of=20BASE_BUFFER.=20=20*/=0A= +static=20inline=20void=0A+treesit_reap_indirect_buffers=20(struct=20= buffer=20*base_buffer)=0A+{=0A+=20=20eassert=20(base_buffer->base_buffer=20= =3D=3D=200);=0A+=20=20Lisp_Object=20buffer_list=20=3D=20BVAR=20= (base_buffer,=20treesit_indirect_list);=0A+=20=20Lisp_Object=20= new_buffer_list=20=3D=20Qnil;=0A+=0A+=20=20/*=20Go=20over=20the=20= current=20buffer=20list=20and=20build=20a=20new=20list=20with=20only=0A+=20= =20=20=20=20live=20buffers,=20and=20replace=20the=20old=20list=20with=20= the=20new=20list.=20=20*/=0A+=20=20FOR_EACH_TAIL_SAFE=20(buffer_list)=0A= +=20=20{=0A+=20=20=20=20Lisp_Object=20the_buffer=20=3D=20XCAR=20= (buffer_list);=0A+=20=20=20=20eassert=20(BUFFERP=20(the_buffer));=0A+=20=20= =20=20if=20(BUFFER_LIVE_P=20(XBUFFER=20(the_buffer)))=0A+=20=20=20=20=20=20= new_buffer_list=20=3D=20Fcons=20(the_buffer,=20new_buffer_list);=0A+=20=20= }=0A+=20=20new_buffer_list=20=3D=20Fnreverse=20(new_buffer_list);=0A+=20=20= BVAR=20(base_buffer,=20treesit_indirect_list)=20=3D=20new_buffer_list;=0A= +}=0A+=0A=20/*=20Update=20each=20parser=20in=20PARSER_LIST.=20=20*/=0A=20= static=20inline=20void=0A=20treesit_record_change_1=20(Lisp_Object=20= parser_list,=20ptrdiff_t=20start_byte,=0A@@=20-766,10=20+787,37=20@@=20= treesit_record_change_1=20(Lisp_Object=20parser_list,=20ptrdiff_t=20= start_byte,=0A=20treesit_record_change=20(ptrdiff_t=20start_byte,=20= ptrdiff_t=20old_end_byte,=0A=20=09=09=20=20=20=20=20=20=20ptrdiff_t=20= new_end_byte)=0A=20{=0A-=20=20Lisp_Object=20parser_list=20=3D=20BVAR=20= (current_buffer,=20treesit_parser_list);=0A+=20=20/*=20We=20always=20act=20= on=20the=20base=20buffer.=20=20If=20this=20buffer=20is=20an=20indirect=0A= +=20=20=20=20=20buffer,=20switch=20to=20its=20base=20buffer.=20=20*/=0A+=20= =20struct=20buffer=20*base_buffer=20=3D=20current_buffer;=0A+=20=20if=20= (current_buffer->base_buffer)=0A+=20=20=20=20base_buffer=20=3D=20= current_buffer->base_buffer;=0A+=0A+=20=20/*=20First=20update=20base=20= buffer's=20parsers.=20=20*/=0A+=20=20Lisp_Object=20parser_list=20=3D=20= BVAR=20(base_buffer,=20treesit_parser_list);=0A=20=20=20= treesit_record_change_1=20(parser_list,=20start_byte,=0A=20=09=09=09=20=20= =20old_end_byte,=20new_end_byte);=0A=20=0A+=20=20/*=20Then=20update=20= parsers=20of=20indirect=20buffers.=20=20*/=0A+=20=20Lisp_Object=20= buffer_list=20=3D=20BVAR=20(base_buffer,=20treesit_indirect_list);=0A+=20= =20bool=20need_reap=20=3D=20false;=0A+=20=20FOR_EACH_TAIL_SAFE=20= (buffer_list)=0A+=20=20{=0A+=20=20=20=20struct=20buffer=20*buffer=20=3D=20= XBUFFER=20(XCAR=20(buffer_list));=0A+=20=20=20=20if=20(BUFFER_LIVE_P=20= (buffer))=0A+=20=20=20=20=20=20{=0A+=09Lisp_Object=20parser_list=20=3D=20= BVAR=20(buffer,=20treesit_parser_list);=0A+=09treesit_record_change_1=20= (parser_list,=20start_byte,=0A+=09=09=09=09=20old_end_byte,=20= new_end_byte);=0A+=20=20=20=20=20=20}=0A+=20=20=20=20else=0A+=20=20=20=20= =20=20need_reap=20=3D=20true;=0A+=20=20}=0A+=0A+=20=20/*=20If=20we=20= encountered=20deleted=20indirect=20buffer=20above,=20remove=20it=20from=0A= +=20=20=20=20=20the=20indirect=20list.=20=20*/=0A+=20=20if=20(need_reap)=0A= +=20=20=20=20treesit_reap_indirect_buffers=20(base_buffer);=0A=20}=0A=20=0A= =20/*=20Comment=20(ref:visible-beg-null)=20The=20purpose=20of=20= visible_beg/end=20is=20to=0A@@=20-1270,7=20+1318,10=20@@=20DEFUN=20= ("treesit-parser-create",=0A=20=20=20CHECK_SYMBOL=20(language);=0A=20=20=20= struct=20buffer=20*buf;=0A=20=20=20if=20(NILP=20(buffer))=0A-=20=20=20=20= buf=20=3D=20current_buffer;=0A+=20=20=20=20{=0A+=20=20=20=20=20=20buf=20= =3D=20current_buffer;=0A+=20=20=20=20=20=20XSETBUFFER=20(buffer,=20= current_buffer);=0A+=20=20=20=20}=0A=20=20=20else=0A=20=20=20=20=20{=0A=20= =20=20=20=20=20=20CHECK_BUFFER=20(buffer);=0A@@=20-1301,14=20+1352,26=20= @@=20DEFUN=20("treesit-parser-create",=0A=20=20=20ts_parser_set_language=20= (parser,=20lang);=0A=20=0A=20=20=20/*=20Create=20parser.=20=20*/=0A-=20=20= Lisp_Object=20lisp_parser=20=3D=20make_treesit_parser=20(Fcurrent_buffer=20= (),=0A-=09=09=09=09=09=09=20parser,=20NULL,=0A+=20=20Lisp_Object=20= lisp_parser=20=3D=20make_treesit_parser=20(buffer,=20parser,=20NULL,=0A=20= =09=09=09=09=09=09=20language);=0A=20=0A=20=20=20/*=20Update=20= parser-list.=20=20*/=0A=20=20=20Lisp_Object=20buffer_list=20=3D=20BVAR=20= (buf,=20treesit_parser_list);=0A=20=20=20BVAR=20(buf,=20= treesit_parser_list)=20=3D=20Fcons=20(lisp_parser,=20buffer_list);=0A=20=0A= +=20=20/*=20If=20this=20buffer=20is=20an=20indirect=20buffer,=20add=20= this=20buffer=20to=20its=20base=0A+=20=20=20=20=20buffer's=20= treesit_indirect_list.=20=20*/=0A+=20=20if=20(buf->base_buffer)=0A+=20=20= =20=20{=0A+=20=20=20=20=20=20struct=20buffer=20*base_buffer=20=3D=20= buf->base_buffer;=0A+=20=20=20=20=20=20Lisp_Object=20indirect_list=20=3D=20= BVAR=20(base_buffer,=20treesit_indirect_list);=0A+=20=20=20=20=20=20if=20= (NILP=20(Fmemq=20(buffer,=20indirect_list)))=0A+=09{=0A+=09=20=20= indirect_list=20=3D=20Fcons=20(buffer,=20indirect_list);=0A+=09=20=20= BVAR=20(base_buffer,=20treesit_indirect_list)=20=3D=20indirect_list;=0A+=09= }=0A+=20=20=20=20}=0A+=0A=20=20=20return=20lisp_parser;=0A=20}=0A=20=0A= @@=20-1382,6=20+1445,24=20@@=20DEFUN=20("treesit-parser-language",=0A=20=20= =20return=20XTS_PARSER=20(parser)->language_symbol;=0A=20}=0A=20=0A= +DEFUN=20("treesit--indirect-buffer-list",=0A+=20=20=20=20=20=20=20= Ftreesit__indirect_buffer_list,=20Streesit__indirect_buffer_list,=0A+=20=20= =20=20=20=20=200,=201,=200,=0A+=20=20=20=20=20=20=20doc:=20/*=20This=20= INTERNAL=20function=20is=20used=20for=20testing=20only.=0A+It=20does=20= NOT=20return=20all=20the=20indirect=20buffers=20of=20BUFFER.=20=20*/)=0A= +=20=20(Lisp_Object=20buffer)=0A+{=0A+=20=20CHECK_BUFFER=20(buffer);=0A+=20= =20struct=20buffer=20*buf=20=3D=20XBUFFER=20(buffer);=0A+=20=20= Lisp_Object=20return_list=20=3D=20Qnil;=0A+=20=20Lisp_Object=20tail=20=3D=20= BVAR=20(buf,=20treesit_indirect_list);=0A+=0A+=20=20FOR_EACH_TAIL=20= (tail)=0A+=20=20=20=20return_list=20=3D=20Fcons=20(XCAR=20(tail),=20= return_list);=0A+=0A+=20=20return=20Freverse=20(return_list);=0A+}=0A+=0A= =20/***=20Parser=20API=20*/=0A=20=0A=20DEFUN=20= ("treesit-parser-root-node",=0A@@=20-3105,6=20+3186,7=20@@=20= syms_of_treesit=20(void)=0A=20=20=20defsubr=20(&Streesit_parser_list);=0A= =20=20=20defsubr=20(&Streesit_parser_buffer);=0A=20=20=20defsubr=20= (&Streesit_parser_language);=0A+=20=20defsubr=20= (&Streesit__indirect_buffer_list);=0A=20=0A=20=20=20defsubr=20= (&Streesit_parser_root_node);=0A=20=20=20/*=20defsubr=20= (&Streesit_parse_string);=20*/=0Adiff=20--git=20= a/test/src/treesit-tests.el=20b/test/src/treesit-tests.el=0Aindex=20= 80fde408cd3..bc8502531dc=20100644=0A---=20a/test/src/treesit-tests.el=0A= +++=20b/test/src/treesit-tests.el=0A@@=20-31,6=20+31,7=20@@=0A=20= (declare-function=20treesit-parser-create=20"treesit.c")=0A=20= (declare-function=20treesit-parser-delete=20"treesit.c")=0A=20= (declare-function=20treesit-parser-list=20"treesit.c")=0A= +(declare-function=20treesit--indirect-buffer-list=20"treesit.c")=0A=20= (declare-function=20treesit-parser-buffer=20"treesit.c")=0A=20= (declare-function=20treesit-parser-language=20"treesit.c")=0A=20=0A@@=20= -156,6=20+157,68=20@@=20treesit-node-api=0A=20=20=20=20=20=20=20(should=20= (treesit-node-eq=20root-node=20root-node))=0A=20=20=20=20=20=20=20= (should=20(not=20(treesit-node-eq=20root-node=20doc-node))))))=0A=20=0A= +(ert-deftest=20treesit-indirect-buffers=20()=0A+=20=20"Test=20basic=20= parsing=20routines."=0A+=20=20(skip-unless=20= (treesit-language-available-p=20'json))=0A+=20=20(let*=20((base-buffer=20= (get-buffer-create=20"*treesit=20test*"))=0A+=20=20=20=20=20=20=20=20=20= (indirect-1=20(make-indirect-buffer=20base-buffer=20"*treesit=20test=20= 1*"))=0A+=20=20=20=20=20=20=20=20=20(indirect-2=20(make-indirect-buffer=20= base-buffer=20"*treesit=20test=202*")))=0A+=20=20=20=20(unwind-protect=0A= +=20=20=20=20=20=20=20=20(progn=0A+=20=20=20=20=20=20=20=20=20=20= (treesit-parser-create=20'json=20base-buffer)=0A+=20=20=20=20=20=20=20=20= =20=20(treesit-parser-create=20'json=20indirect-1)=0A+=20=20=20=20=20=20=20= =20=20=20(treesit-parser-create=20'json=20indirect-2)=0A+=20=20=20=20=20=20= =20=20=20=20;;=201.=20Creating=20parsers=20in=20indirect=20buffers=20= should=20add=20them=0A+=20=20=20=20=20=20=20=20=20=20;;=20to=20the=20= base=20buffer's=20indirect=20list.=0A+=20=20=20=20=20=20=20=20=20=20= (should=20(equal=20(treesit--indirect-buffer-list=20base-buffer)=0A+=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= (list=20indirect-2=20indirect-1)))=0A+=20=20=20=20=20=20=20=20=20=20;;=20= 2.=20Creating=20additional=20parsers=20in=20the=20indirect=20buffer=0A+=20= =20=20=20=20=20=20=20=20=20;;=20should=20not=20add=20duplicate=20= indirect=20buffers=20to=20the=20base=0A+=20=20=20=20=20=20=20=20=20=20;;=20= buffer's=20indirect=20list.=0A+=20=20=20=20=20=20=20=20=20=20= (treesit-parser-create=20'json=20indirect-2=20t)=0A+=20=20=20=20=20=20=20= =20=20=20(should=20(equal=20(treesit--indirect-buffer-list=20= base-buffer)=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20(list=20indirect-2=20indirect-1)))=0A+=20=20=20=20=20=20= =20=20=20=20;;=203.=20Edit=20the=20base=20buffer...=0A+=20=20=20=20=20=20= =20=20=20=20(with-current-buffer=20base-buffer=0A+=20=20=20=20=20=20=20=20= =20=20=20=20(insert=20"[1,2,3]"))=0A+=20=20=20=20=20=20=20=20=20=20;;=20= ...and=20parsers=20in=20the=20indirect=20buffer=20should=20be=20updated=20= too.=0A+=20=20=20=20=20=20=20=20=20=20(with-current-buffer=20indirect-1=0A= +=20=20=20=20=20=20=20=20=20=20=20=20(should=20(eq=20(treesit-node-end=20= (treesit-buffer-root-node))=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=208))=0A+=20=20=20=20=20=20=20=20=20=20=20=20= ;;=204.=20Edit=20the=20indirect=20buffer...=0A+=20=20=20=20=20=20=20=20=20= =20=20=20(goto-char=202)=0A+=20=20=20=20=20=20=20=20=20=20=20=20(insert=20= "0,"))=0A+=20=20=20=20=20=20=20=20=20=20;;=20...and=20parsers=20in=20the=20= base=20and=20other=20indirect=20buffers=20should=20be=0A+=20=20=20=20=20=20= =20=20=20=20;;=20updated=20too.=0A+=20=20=20=20=20=20=20=20=20=20= (with-current-buffer=20base-buffer=0A+=20=20=20=20=20=20=20=20=20=20=20=20= (should=20(eq=20(treesit-node-end=20(treesit-buffer-root-node))=0A+=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=2010)))=0A= +=20=20=20=20=20=20=20=20=20=20(with-current-buffer=20indirect-2=0A+=20=20= =20=20=20=20=20=20=20=20=20=20(should=20(eq=20(treesit-node-end=20= (treesit-buffer-root-node))=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=2010)))=0A+=20=20=20=20=20=20=20=20=20=20;;=20= 5.=20Kill=20an=20indirect=20buffer,=20editing=20the=20base=20buffer=20= and=20the=0A+=20=20=20=20=20=20=20=20=20=20;;=20other=20indirect=20= buffer=20should=20be=20fine.=0A+=20=20=20=20=20=20=20=20=20=20= (kill-buffer=20indirect-1)=0A+=20=20=20=20=20=20=20=20=20=20= (with-current-buffer=20base-buffer=0A+=20=20=20=20=20=20=20=20=20=20=20=20= (delete-region=20(point-min)=20(point-max)))=0A+=20=20=20=20=20=20=20=20=20= =20(with-current-buffer=20indirect-2=0A+=20=20=20=20=20=20=20=20=20=20=20= =20(insert=20"[1,2,3]"))=0A+=20=20=20=20=20=20=20=20=20=20= (with-current-buffer=20base-buffer=0A+=20=20=20=20=20=20=20=20=20=20=20=20= (should=20(eq=20(treesit-node-end=20(treesit-buffer-root-node))=0A+=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=208)))=0A= +=20=20=20=20=20=20=20=20=20=20(with-current-buffer=20indirect-2=0A+=20=20= =20=20=20=20=20=20=20=20=20=20(should=20(eq=20(treesit-node-end=20= (treesit-buffer-root-node))=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=208)))=0A+=20=20=20=20=20=20=20=20=20=20;;=20= 6.=20The=20killed=20indirect=20buffer=20should=20be=20removed=20from=20= the=0A+=20=20=20=20=20=20=20=20=20=20;;=20base=20buffer's=20indirect=20= list.=0A+=20=20=20=20=20=20=20=20=20=20(should=20(equal=20= (treesit--indirect-buffer-list=20base-buffer)=0A+=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20(list=20indirect-2)))=0A= +=20=20=20=20=20=20=20=20=20=20(kill-buffer=20indirect-2)=0A+=20=20=20=20= =20=20=20=20=20=20(kill-buffer=20base-buffer))=0A+=20=20=20=20=20=20= (kill-buffer=20base-buffer)=0A+=20=20=20=20=20=20(kill-buffer=20= base-buffer)=0A+=20=20=20=20=20=20(kill-buffer=20base-buffer))))=0A+=0A=20= (ert-deftest=20treesit-query-api=20()=0A=20=20=20"Tests=20for=20query=20= API."=0A=20=20=20(skip-unless=20(treesit-language-available-p=20'json))=0A= --=20=0A2.33.1=0A=0A= --Apple-Mail=_BC4D0109-2183-4F34-B0A6-745C75C74423-- From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 04 02:46:43 2022 Received: (at 59693) by debbugs.gnu.org; 4 Dec 2022 07:46:43 +0000 Received: from localhost ([127.0.0.1]:56013 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p1jhz-0008GR-3r for submit@debbugs.gnu.org; Sun, 04 Dec 2022 02:46:43 -0500 Received: from eggs.gnu.org ([209.51.188.92]:42000) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p1jhx-0008GL-3b for 59693@debbugs.gnu.org; Sun, 04 Dec 2022 02:46:41 -0500 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 1p1jhp-0007KX-Uf; Sun, 04 Dec 2022 02:46:33 -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=sz7i0nZ4LGzmxVe+rB1ZQQpWbZbBTGjntui6Cx0gJEU=; b=r7XK8ci+MWPDvKdvkOCp uqPkg4iKRah7BmcjZpPImbHII10sHUMWZPSFC+OfInvWpyaYGleLqfUTVBNwi0cKZYSZ3DfHwf/d/ 4vPx1rSvWQQBt24X2i2Psn624oqlBUcoILJ22kTBgvUfF29djrDcvWhz4jLIqfztJbkW2uM2Rafhu EPau7PYI2rmvDo5jEpIkdgPsno6grA9JLyO+tAxUZrJMgE6GEXCTGpTi2JrGZQYi6xVlTatupY1Of 5ADTETNfKWw8aHf3RbnO8IPE5fpnc/8BliECq0JQFfJ3pyk7QXVDccKDlQbICKans3D+m8DS9Yiak VaEGZsVIt8eB+g==; 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 1p1jhp-0003KC-2N; Sun, 04 Dec 2022 02:46:33 -0500 Date: Sun, 04 Dec 2022 09:46:13 +0200 Message-Id: <83sfhvbohm.fsf@gnu.org> From: Eli Zaretskii To: Yuan Fu , Stefan Monnier In-Reply-To: (message from Yuan Fu on Sat, 3 Dec 2022 23:20:59 -0800) Subject: Re: bug#59693: 29.0.50; treesitter in base buffer doesn't respond to modifications in indirect buffer correctly 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> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -0.3 (/) X-Debbugs-Envelope-To: 59693 Cc: 59693@debbugs.gnu.org, miha@kamnitnik.top X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.3 (-) > From: Yuan Fu > Date: Sat, 3 Dec 2022 23:20:59 -0800 > Cc: miha@kamnitnik.top, > 59693@debbugs.gnu.org > > >>> We don’t 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. > >> > >> Yes, the parsers should not be shared. > >> > >>> 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. > >> > >> 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. > > > > Good idea, it’s easier to know when to remove the reference with buffers, aka when buffer is killed. > > I now have a patch that fixes this problem. WDYT? I added a new buffer field since it’s cleaner than turning ts_parser_list into a cons, hopefully that’s not frowned upon. Thanks. If we are adding to the buffer object a field that holds the list of indirect buffers, then: . the name of the field should not include "treesit" in it, and it shouldn't be conditioned on HAVE_TREE_SITTER . I wonder if a flat list is a good idea, i.e. scalable enough? also, treesit_reap_indirect_buffers conses a lot as result . 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?) Stefan, any comments on this? Are there better ideas of how to track buffer text changes in indirect buffers? From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 04 18:21:22 2022 Received: (at 59693) by debbugs.gnu.org; 4 Dec 2022 23:21:22 +0000 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 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 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) 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) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: bug#59693: 29.0.50; treesitter in base buffer doesn't respond to modifications in indirect buffer correctly From: Yuan Fu In-Reply-To: <83sfhvbohm.fsf@gnu.org> Date: Sun, 4 Dec 2022 15:21:10 -0800 Content-Transfer-Encoding: quoted-printable 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> To: Eli Zaretskii X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Spam-Score: 2.0 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > On Dec 3, 2022, at 11:46 PM, Eli Zaretskii wrote: > >> From: Yuan Fu >> Date: Sat, 3 Dec 2022 23:20:59 -0800 >> Cc: miha@kamnitnik.top, >> 59693@debbugs.gnu.org >> >>>>> We don’t want indirect [...] Content analysis details: (2.0 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 2.0 PDS_OTHER_BAD_TLD Untrustworthy TLDs [URI: kamnitnik.top (top)] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (casouri[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.215.174 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [209.85.215.174 listed in wl.mailspike.net] -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders X-Debbugs-Envelope-To: 59693 Cc: 59693@debbugs.gnu.org, Stefan Monnier , miha@kamnitnik.top X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > 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= From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 04 22:49:28 2022 Received: (at 59693) by debbugs.gnu.org; 5 Dec 2022 03:49:28 +0000 Received: from localhost ([127.0.0.1]:33265 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p22Tv-0006zG-Rz for submit@debbugs.gnu.org; Sun, 04 Dec 2022 22:49:28 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:56181) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p22Tr-0006z9-A6 for 59693@debbugs.gnu.org; Sun, 04 Dec 2022 22:49:25 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 7BB06442359; Sun, 4 Dec 2022 22:49:17 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id DD02B441F6E; Sun, 4 Dec 2022 22:49:15 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1670212155; bh=ecUvPxeKsJ8fmYQTIqgcLJxb7X6lfvbexxcRyZyYMLk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=i8zixEy0PF3z7rJzVtUyddQItk0s57zOtCM9jdCuwx2gNo4dXQzRGrIoCz1fkcC+0 8nqbmR0U2TWxQnArGuHelYgya3mxqbQPh2DoK56G1RaJktipaRZ9R5nKUH1SgM9lNP cZQft48ptLuo6oZmVceALO6y+/8nZXBrRRqXu/r6fJKSYIgZky63pLiyYx+ZE5myMg XVek90HxK1cM7aHCOMa4epGHIzKfHvjdp2YKB2sAKngJUg5ulo1FW24mqCPIRU2cLB L1sS7bSMdZuCfRkKovGwXcMBypdKO/rUqCd0tkCe063odouaQPLIxlOgPnIppuv0Ju H2yKghUC+tJkg== Received: from alfajor (unknown [45.72.193.52]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id A8C8B121C2D; Sun, 4 Dec 2022 22:49:15 -0500 (EST) From: Stefan Monnier To: Yuan Fu Subject: Re: bug#59693: 29.0.50; treesitter in base buffer doesn't respond to modifications in indirect buffer correctly In-Reply-To: (Yuan Fu's message of "Thu, 1 Dec 2022 21:05:43 -0800") Message-ID: References: <87r0xlbjg6.fsf@miha-pc> <5F7AE71F-0327-409E-BCE9-310E1980C17A@gmail.com> <8335a0lept.fsf@gnu.org> Date: Sun, 04 Dec 2022 22:49:14 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.224 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 59693 Cc: Eli Zaretskii , 59693@debbugs.gnu.org, miha@kamnitnik.top X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Actually there=E2=80=99s a little bit of problem. When we edit the base b= uffer, we > would want to update the parsers in all of its indirect buffers as well, = and > AFAICT there is no pointer from base buffer to the indirect buffer, only = the > other way around.=20 Background note: I consider indirect buffers an attractive nuisance and for this reason I think we should spend as little time as possible improving them. Instead we should encourage people to develop alternative approaches. I know we have a large number of bugs lurking in that area. E.g.: Emacs -Q M-x clone-indirect-buffer RET M-x fundamental-mode RET we see that `*scratch*` has lost its font-lock highlighting even though we changed major mode in the "other" buffer. Now go to `*scratch*` type some text: you see that font-lock properly updates the new code's highlighting. Then go to `*scratch*<2>` and type some more text: you should see that font-lock does *not* properly update the new code's highlighting in the base buffer. AFAICT this is the exact same bug as what you're seeing, just with font-lock instead of tree-sitter. [ Of course, for font-lock it's worse because font-lock uses text-properties (which are shared between the base and the its indirect buffers) so it simply can't do its job properly in indirect buffers. ] This bug has been with us since indirect buffers were invented, so it has very low priority, AFAIC. > Then base buffer can update all indirect buffers=E2=80=99 parsers, and in= direct > buffer can find its base buffer and update all the parsers, including the > base buffer=E2=80=99s parsers and other indirect buffers=E2=80=99 parsers. Don't bother, please. Instead, I recommend you disallow the use of tree sitter in indirect buffers. And we should probably try and change `insdel.c` so it always runs the `after/before-change-functions` in the base buffer (this should fix the worst part of the problems). Stefan From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 05 03:19:31 2022 Received: (at 59693) by debbugs.gnu.org; 5 Dec 2022 08:19:31 +0000 Received: from localhost ([127.0.0.1]:34518 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p26hH-0001Oz-3g for submit@debbugs.gnu.org; Mon, 05 Dec 2022 03:19:31 -0500 Received: from eggs.gnu.org ([209.51.188.92]:43312) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p26hE-0001Ot-OI for 59693@debbugs.gnu.org; Mon, 05 Dec 2022 03:19:29 -0500 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 1p26h8-0000ya-Ao; Mon, 05 Dec 2022 03:19:22 -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:In-Reply-To:Subject:To:From: Date; bh=5ar3BYo8egdm0Jof9Yy5oeJ6z3A2JpuOGwpzgKUmjz0=; b=kuRy5w/YTOUMbk+o+pZQ /axICW0Ttu7WfuiW7mc8kDHzEz9LcI3vDyaVxCxBataHpjJ/m3vWYohks9+k3F0IKiJb330cI4G29 DC5GrzOJ/qXz3JiOjb82+CHZhTju+ZPG05pn+zXKHi/sH/LKICMM8QgcCnY5GuZ9qR9SIohSxuVvm cWWq/oDVJE00FwcL+1Ham+ePZNaV5mbjqYQnQ5dz88gtEiUE6BC9rJ75NVJNHzngBR0egQQMR5JGf t6cg6V4C53vaIcStTDgQJ/7A2URIgQTRDhk8hKCUoTvUfeZwArdF+DbiKqWuccgCQMofPru6cbokj xGVkzyCZNzNMuA==; Received: from [2a02:14f:17a:a7d0::1595:5ce5] (helo=[IPv6:::1]) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1p26h6-0002YX-EE; Mon, 05 Dec 2022 03:19:21 -0500 Date: Mon, 05 Dec 2022 10:19:15 +0200 From: Eli Zaretskii To: Stefan Monnier , Yuan Fu Subject: =?US-ASCII?Q?Re=3A_bug=2359693=3A_29=2E0=2E50=3B_tre?= =?US-ASCII?Q?esitter_in_base_buffer_doesn?= =?US-ASCII?Q?=27t_respond_to_modifications_in_indirect_buffer_correctly?= User-Agent: K-9 Mail for Android In-Reply-To: References: <87r0xlbjg6.fsf@miha-pc> <5F7AE71F-0327-409E-BCE9-310E1980C17A@gmail.com> <8335a0lept.fsf@gnu.org> Message-ID: <22B4F037-2979-4C65-8917-26D17CFBED0A@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Autocrypt: addr=eliz@gnu.org; keydata= mQENBF+pf4UBCAC6vjkWLSAsQpe8YIGKLQzNOJx/IjGtCdFF8uzmO5jmME+SD8ROuJN+t5KXVw58 uzu75EFD0vHTY9e+udJ2gkpuy0NnzkFcbumdLLo2ERKCoSctZZRhzKXI5z5cHxCqW0B2ygHRrRLt oNlGID7bAgcgSViT1ptGqTXO7zGVu4Airok7dNzcPtHgns8GlR5YAFX0TvE6oGd0l2VPghNeVJKJ OjrbfhoDxl3ucFpqbqMH8z9HTLDOFpz8UaYYUdJMi3xX6vwTZxI2sM2RRVLUpZyllAkSMI4lln1O OgazM/62DJUs/rKIHKBnF6h3/qsJUjUYXaAHbrXY26mWllAd536lABEBAAG0I0VsaSBaYXJldHNr aWkgKGVsaXopIDxlbGl6QGdudS5vcmc+iQE4BBMBAgAiBQJfqX+FAhsDBgsJCAcDAgYVCAIJCgsE FgIDAQIeAQIXgAAKCRCRwSYvAeuNOYUQB/4/iIKKOG45ijNaRoTvmJJZMvj1S07WQxEm7c5SHEeE QbLOAxB9vESOV7sLueuN3oqEndtzyYt4x1WTSBmHFF7h5fcCMjBs41siOIp5Sj/xD0Bvaa0IKGCR SZ7PAo8Mq3wgajXpTpn9vxE2PmtzA8KdEE0K1+f9pVAfOpUIcCl44rIxLUW352XG0y7iz6c/O6LB 1deOKMiKFctKO7pBti1dJEm1ImewLH3H8uTbwspLOs3EB8xhsESxmTidnze68HX2jt+2EeMgCdki NU+LWbexQZPfIS7+ZmE06ll0v6+Jy7ZdTkCCRypKWTnW7pIFsq/p4kybV8O/kHSV6B4vvQBfuQEN BF+pf4UBCACvFrdx/m22lgObypSmSS4TNlNvQnMUorrMmp0U32hv5adt6CKXeMjk05F+GcIfVMrp xqMBn4sEUIXWhhogQJa9ZbWEP/HbS8XjMMbz0Q0Siaty9+DSspK/9u2GWKsz3uQzLCexIJtzmXvj AVmvoMCAU/F2t038ggygjYLRgyLRNLgbbartu2dMkvrfxRjheip60S4S3utOcwUf/qdoa1grNann CFluHr/ftXCeeuGB4H8iO0BXWNby6NZPizxJttx9gdcH8/OmDOJkXyRMTT/3sSem76CSOjfXcz7s aJlg680NQhG5TmuYERjJD4+U02K5RuqTsEnOuWeFy4p+/mslABEBAAGJATYEGAECAAkFAl+pf4UC GwwAIQkQkcEmLwHrjTkWIQTmyQKcNjrUHXh6jruRwSYvAeuNOejsB/9rVegsfEBSRLjeeYXyJrOf dme7BYpYsQCw2vGTnrJTGFQ9HM2zT9+wAENBHWjQPJOptJwo5w4xIbZgwJy0uIN3sV18xbCRSxX0 ZSk8GJG0PrQTCaf2xs0kqsShnkvqyo5QSyUlFUAG7m1o7NUhF95Q89oxGO8JyvR356kqNbzUn0Cq PxKyS42QfC8dyFNgVhVPbZp6aONnUwY5SbtCLJtZCBgvppI9XaBH41BDukSE4GgSLoYsSIGShg4h e+bGypAsGtQ9uwmryUi1gRrDgca3wFo/G0rbJn2ZKoLbGFZivWPVgAgd9/O5sLSPFznOdcRGxEA2 gk7A1ReaJ10PtQz0 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 59693 Cc: 59693@debbugs.gnu.org, miha@kamnitnik.top X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On December 5, 2022 5:49:14 AM GMT+02:00, Stefan Monnier wrote: >=20 > Don't bother, please=2E > Instead, I recommend you disallow the use of tree sitter in indirect > buffers=2E And we should probably try and change `insdel=2Ec` so it alw= ays > runs the `after/before-change-functions` in the base buffer (this should > fix the worst part of the problems)=2E Will this "hold water" vis-a-vis the expectations of various features that= would like to use tree sitter related capabilities? Regardless of your op= inion on indirect buffers, many 3rd party packages and features use indirec= t buffers as the backbone of their implementation=2E We don't currently ha= ve any alternatives to that, AFAIK=2E So I'd expect a lot of disappointmen= t if we declare that indirect buffers will not be supported by tree sitter = as a matter of design decision=2E Changing insdel=2Ec to run stuff in base buffer could be a solution, but I= don't feel we can make such changes on the release branch=2E But maybe we= can do that now only for treesit=2Ec functions=2E Yuan, would tgat solve = this particular problem? From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 05 10:29:16 2022 Received: (at 59693) by debbugs.gnu.org; 5 Dec 2022 15:29:17 +0000 Received: from localhost ([127.0.0.1]:36700 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p2DPA-0004P1-LL for submit@debbugs.gnu.org; Mon, 05 Dec 2022 10:29:16 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:27068) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p2DP9-0004Ov-14 for 59693@debbugs.gnu.org; Mon, 05 Dec 2022 10:29:15 -0500 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 9750880725; Mon, 5 Dec 2022 10:29:09 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 9B6048054F; Mon, 5 Dec 2022 10:29:07 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1670254147; bh=x+931UO0eXedU3OcxYkCc5+UaRD+ZFnjUF10UC2mIac=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=VSLdPkPliN8MlMDlorB6IaS0iPd3EphHgkPo7KaGL9ddvaIgl6C1DAPK9iO+/sy4X ribvraiaSdHi8hjuosVXV+CSizvkCWoTdJghAUQeWoTZ8PRDIV9UCJ1E+ohbzeHTPz EUGBnkT5upccPVu185zU2kkoi0u+o63PoKRCQ0CKgiZlOr7QAs4LHIjb8Vv+ZgJxf5 viMUJdGoLR7VExnMCXDJgr9JhdqWN25dzdC+B6vhJi8voof5nYQhlQCHJ2f2rATbXP p2l+SJ+sqYdWTcfSRcwv2AXxGKo6hHfMyJpywfxEr1WG7P3b1OuU2WnYDI+pjgTOzp 9oFyzwIMx0VZg== Received: from alfajor (alfajor.sf.umontreal.ca [10.35.225.233]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 902B91209C1; Mon, 5 Dec 2022 10:29:07 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#59693: 29.0.50; treesitter in base buffer doesn't respond to modifications in indirect buffer correctly In-Reply-To: <22B4F037-2979-4C65-8917-26D17CFBED0A@gnu.org> (Eli Zaretskii's message of "Mon, 05 Dec 2022 10:19:15 +0200") Message-ID: References: <87r0xlbjg6.fsf@miha-pc> <5F7AE71F-0327-409E-BCE9-310E1980C17A@gmail.com> <8335a0lept.fsf@gnu.org> <22B4F037-2979-4C65-8917-26D17CFBED0A@gnu.org> Date: Mon, 05 Dec 2022 10:29:06 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 59693 Cc: Yuan Fu , 59693@debbugs.gnu.org, miha@kamnitnik.top X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Will this "hold water" vis-a-vis the expectations of various features that > would like to use tree sitter related capabilities? Regardless of your > opinion on indirect buffers, many 3rd party packages and features use > indirect buffers as the backbone of their implementation. We don't > currently have any alternatives to that, AFAIK. So I'd expect a lot of > disappointment if we declare that indirect buffers will not be supported by > tree sitter as a matter of design decision. I can't see why: a package that uses indirect buffers can just as well run its tree-sitter parsers in the base buffer. > Changing insdel.c to run stuff in base buffer could be a solution, but > I don't feel we can make such changes on the release branch. Agreed. > But maybe we can do that now only for treesit.c functions. Sounds OK to me, yes. Stefan From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 05 10:45:41 2022 Received: (at 59693) by debbugs.gnu.org; 5 Dec 2022 15:45:41 +0000 Received: from localhost ([127.0.0.1]:36834 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p2Df3-0004cx-3P for submit@debbugs.gnu.org; Mon, 05 Dec 2022 10:45:41 -0500 Received: from eggs.gnu.org ([209.51.188.92]:40576) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p2Df0-0004cn-Rt for 59693@debbugs.gnu.org; Mon, 05 Dec 2022 10:45:39 -0500 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 1p2Det-00056l-3H; Mon, 05 Dec 2022 10:45:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=DOJUvby9hz3MhkEZLxfgTx72F4JqyUaKZD7PnQtWFkA=; b=SN+a23bL6Zff HQnMHq/HXx7YDWpKnTSBeI6DSSKKkBL0Z+gVhqrDJrQHzfIhtFBnmoWjEzkvdeAqxE37Xt1at4jBt eOotGomEoi3CsjFhY9M/eOcq+6ZJuqPGvBUB49QrLshz/+sEIpf/RsUQS6urRylGMCbZqMf8hpqyM eLQMm/H90eNF1f/ssBjkdso2ddUR80n65tOSTAwFWIC1lDnGM/us2cDhsfnBmik+iATAY46Lyp7z/ h7XHZhzFgBH0i3B3Z9+vcUn2BSpn+j0BqeSPtldABOmi9JG1Ja5G64Ehk4v1zmdXKv0RBgNWwy1f4 KEOKRe8jU3SusKEr0QBjKw==; 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 1p2DeS-0004aC-Jh; Mon, 05 Dec 2022 10:45:30 -0500 Date: Mon, 05 Dec 2022 17:44:49 +0200 Message-Id: <83a64197ny.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Mon, 05 Dec 2022 10:29:06 -0500) Subject: Re: bug#59693: 29.0.50; treesitter in base buffer doesn't respond to modifications in indirect buffer correctly References: <87r0xlbjg6.fsf@miha-pc> <5F7AE71F-0327-409E-BCE9-310E1980C17A@gmail.com> <8335a0lept.fsf@gnu.org> <22B4F037-2979-4C65-8917-26D17CFBED0A@gnu.org> X-Spam-Score: -0.3 (/) X-Debbugs-Envelope-To: 59693 Cc: casouri@gmail.com, 59693@debbugs.gnu.org, miha@kamnitnik.top X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.3 (-) > From: Stefan Monnier > Cc: Yuan Fu , 59693@debbugs.gnu.org, miha@kamnitnik.top > Date: Mon, 05 Dec 2022 10:29:06 -0500 > > > Will this "hold water" vis-a-vis the expectations of various features that > > would like to use tree sitter related capabilities? Regardless of your > > opinion on indirect buffers, many 3rd party packages and features use > > indirect buffers as the backbone of their implementation. We don't > > currently have any alternatives to that, AFAIK. So I'd expect a lot of > > disappointment if we declare that indirect buffers will not be supported by > > tree sitter as a matter of design decision. > > I can't see why: a package that uses indirect buffers can just as well > run its tree-sitter parsers in the base buffer. I thought about those multi-mode modes, or features that show the same buffer more than once with different modes. > > Changing insdel.c to run stuff in base buffer could be a solution, but > > I don't feel we can make such changes on the release branch. > > Agreed. > > > But maybe we can do that now only for treesit.c functions. > > Sounds OK to me, yes. OK, thanks. Yuan, will this work for you? can you show a patch along these lines? From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 05 15:14:30 2022 Received: (at 59693) by debbugs.gnu.org; 5 Dec 2022 20:14:30 +0000 Received: from localhost ([127.0.0.1]:38130 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p2HrB-00014L-QH for submit@debbugs.gnu.org; Mon, 05 Dec 2022 15:14:29 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:14078) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p2HrA-00014E-4d for 59693@debbugs.gnu.org; Mon, 05 Dec 2022 15:14:28 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id B79814426B8; Mon, 5 Dec 2022 15:14:22 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 6DA824426B3; Mon, 5 Dec 2022 15:14:21 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1670271261; bh=BaZVTUjb3cSVvkAzJwMxAN+Ez57FkGemPdRuiD/j6K4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=I3RxAMClsEgXi+UaTn8hJhCqbORnhsprnGPwfq+H7W447f5q6Lgu0wXUMTGzZiBL7 efpvRzmdDjDEtSDU7K7W/uLX7xh+L984b5ZR5JB6K+5sWAn9YbnNLwpqRxxjDSjioo HulKYqRodYiOYI9f4khFlsEG6+XZ8CR20hWQ4+l6S3xbf2Owhrf+bdHKDfIU8JavMC uz845kDSPihsVfimg5mGMFZSbn3WI2BVHib2PTKh2Zl1JhagIdda/79JnztHAwQf0c /hBWv65GADzOn+TMsrxZpS6ix3gbKLUc2cvdSMb0ShcEpWTyG+ddDokA7PdnKtULrz uT8fFAC4QWC5A== Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 4FC21122535; Mon, 5 Dec 2022 15:14:21 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#59693: 29.0.50; treesitter in base buffer doesn't respond to modifications in indirect buffer correctly In-Reply-To: <83a64197ny.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 05 Dec 2022 17:44:49 +0200") Message-ID: References: <87r0xlbjg6.fsf@miha-pc> <5F7AE71F-0327-409E-BCE9-310E1980C17A@gmail.com> <8335a0lept.fsf@gnu.org> <22B4F037-2979-4C65-8917-26D17CFBED0A@gnu.org> <83a64197ny.fsf@gnu.org> Date: Mon, 05 Dec 2022 15:14:20 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.196 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 59693 Cc: casouri@gmail.com, 59693@debbugs.gnu.org, miha@kamnitnik.top X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> I can't see why: a package that uses indirect buffers can just as well >> run its tree-sitter parsers in the base buffer. > I thought about those multi-mode modes, or features that show the same > buffer more than once with different modes. Yes, that's exactly the case I'm thinking about: these packages should have no trouble running all their parsers in the base buffer (even if the rest of their work is done in indirect buffers). Stefan From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 05 21:15:18 2022 Received: (at 59693) by debbugs.gnu.org; 6 Dec 2022 02:15:18 +0000 Received: from localhost ([127.0.0.1]:39729 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p2NUL-0007TO-Sl for submit@debbugs.gnu.org; Mon, 05 Dec 2022 21:15:18 -0500 Received: from mail-pj1-f42.google.com ([209.85.216.42]:55821) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p2NUK-00075r-3Y for 59693@debbugs.gnu.org; Mon, 05 Dec 2022 21:15:16 -0500 Received: by mail-pj1-f42.google.com with SMTP id u5so3668183pjy.5 for <59693@debbugs.gnu.org>; Mon, 05 Dec 2022 18:15:16 -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=tfomrdvNUmUM0DVh/U2LdlxQg5b9e8K5Hwlv2gqCgww=; b=WLjlXzn0LhKE7FTnsvuObF2BCkA4HJzfDGSvfRwv4Sb1AdD6vwDAGjpKWhMmniUS/u UcuqgOT/e9Q1NabgdCud4ihFHGKqdw5D0qPulXvDywGGGKts4EP3EuvjUWBS9VWvm2gd 1k3mDfVQQfQBjT21GYLqrsOJnXMCtWWe1UcTFd8FDCCTT/33SYxyAkmjE3vPbWx01xCr s8d96TI+9VPyaM/ZrReX+6TO04rDdsDj5KlyayR+DqOLqT/6V2t3NZ6rg98eEidNx8Aq RnieNPS3RUqvXyBfPlqyPobDY4hNLR9bGhDC6E2IrFAjXzHwTnej1Yp99e+Z7Nav8WJN Eo8A== 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=tfomrdvNUmUM0DVh/U2LdlxQg5b9e8K5Hwlv2gqCgww=; b=x8Gm3VVGWstst8kX/RkSzp/ElDXZJfbHvNWL6O9NqdDexk8iQtAp6lLRn5naF27P7S Z/P/bJ4hNGPHoAMtVM0BkgrCpHryvCherJg/oGyD1CkFPWRfrR8gBgKJxWChgaUZgNdV AQlMp7wSOiIY+edjxp6qQ4fhtyfCQMOzqneqicFqzMsMpJfn4Yd27CbFYaXzwmOtglUA 2iFzw5vKTeHejZtjGxJ3fu9TwTvyWtCl805qTjF+Gp8L/8r6xBo6NEnwzqwvpzSYliXc 05BjcA28r2nIPuHfmiDL9U4Aa9pVJlORu/FJ+AEr7r6xbvzkmcZ0zWhNdIcN28nH2QqB F0wg== X-Gm-Message-State: ANoB5pk15dJof+C7VeusbZEZ6PGyaEBA0GWLSjUtELiiwnuWTgwNpEI1 qqbWnod1LaFnCDYXnVSlTKc= X-Google-Smtp-Source: AA0mqf5MDByl6EL4YEn1/Hh88cGDqSu1E7kGVm5J86Dud8W3UyxL+Brt8sh8gjIvb3GxvWejcvJ39A== X-Received: by 2002:a17:90b:3941:b0:215:db2e:bb17 with SMTP id oe1-20020a17090b394100b00215db2ebb17mr92196211pjb.166.1670292909931; Mon, 05 Dec 2022 18:15:09 -0800 (PST) Received: from smtpclient.apple (cpe-172-117-161-177.socal.res.rr.com. [172.117.161.177]) by smtp.gmail.com with ESMTPSA id d1-20020a170903230100b0017f74cab9eesm11272320plh.128.2022.12.05.18.15.08 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Dec 2022 18:15:09 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: bug#59693: 29.0.50; treesitter in base buffer doesn't respond to modifications in indirect buffer correctly From: Yuan Fu In-Reply-To: <83a64197ny.fsf@gnu.org> Date: Mon, 5 Dec 2022 18:15:07 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <0973FBCA-DFBE-4FF7-9052-2B60D2FC81DC@gmail.com> References: <87r0xlbjg6.fsf@miha-pc> <5F7AE71F-0327-409E-BCE9-310E1980C17A@gmail.com> <8335a0lept.fsf@gnu.org> <22B4F037-2979-4C65-8917-26D17CFBED0A@gnu.org> <83a64197ny.fsf@gnu.org> To: Eli Zaretskii X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Spam-Score: 2.0 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > On Dec 5, 2022, at 7:44 AM, Eli Zaretskii wrote: > >> From: Stefan Monnier >> Cc: Yuan Fu , 59693@debbugs.gnu.org, miha@kamnitnik.top >> Date: Mon, 05 Dec 2022 10:29:06 -0500 >> >>> Will this " [...] Content analysis details: (2.0 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 2.0 PDS_OTHER_BAD_TLD Untrustworthy TLDs [URI: kamnitnik.top (top)] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (casouri[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [209.85.216.42 listed in wl.mailspike.net] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.216.42 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders X-Debbugs-Envelope-To: 59693 Cc: 59693@debbugs.gnu.org, Stefan Monnier , miha@kamnitnik.top X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > On Dec 5, 2022, at 7:44 AM, Eli Zaretskii wrote: >=20 >> From: Stefan Monnier >> Cc: Yuan Fu , 59693@debbugs.gnu.org, = miha@kamnitnik.top >> Date: Mon, 05 Dec 2022 10:29:06 -0500 >>=20 >>> Will this "hold water" vis-a-vis the expectations of various = features that >>> would like to use tree sitter related capabilities? Regardless of = your >>> opinion on indirect buffers, many 3rd party packages and features = use >>> indirect buffers as the backbone of their implementation. We don't >>> currently have any alternatives to that, AFAIK. So I'd expect a lot = of >>> disappointment if we declare that indirect buffers will not be = supported by >>> tree sitter as a matter of design decision. >>=20 >> I can't see why: a package that uses indirect buffers can just as = well >> run its tree-sitter parsers in the base buffer. >=20 > I thought about those multi-mode modes, or features that show the same > buffer more than once with different modes. >=20 >>> Changing insdel.c to run stuff in base buffer could be a solution, = but >>> I don't feel we can make such changes on the release branch. >>=20 >> Agreed. >>=20 >>> But maybe we can do that now only for treesit.c functions. >>=20 >> Sounds OK to me, yes. >=20 > OK, thanks. Yuan, will this work for you? can you show a patch along = these > lines? That wouldn=E2=80=99t work, unfortunately. We need to update all the = parsers in every indirect and base buffer, enforce all changes to happen = in the base buffer doesn=E2=80=99t help with that: indirect buffers=E2=80=99= parsers would be out-of-sync. I can think of two ways: 1. Only allow base buffer to have parsers, no change is needed for = insdel.c, treesit_record_change can find the base buffer and update its = parsers. We can ask indirect buffers to use their base buffer=E2=80=99s = parser. Unless the base buffer is narrowed, I think it will work fine.=20= I remember that there were a discussion along the lines of user-narrow = vs low-level narrow, what was the outcome of that discussion? 2. The patch I sent earlier, which tracks indirect buffers so all the = relevant buffer=E2=80=99s parser are updated at a buffer content change. Yuan From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 05 22:57:33 2022 Received: (at 59693) by debbugs.gnu.org; 6 Dec 2022 03:57:33 +0000 Received: from localhost ([127.0.0.1]:40189 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p2P5J-0001PF-EP for submit@debbugs.gnu.org; Mon, 05 Dec 2022 22:57:33 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:5565) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p2P5H-0001P8-D0 for 59693@debbugs.gnu.org; Mon, 05 Dec 2022 22:57:32 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id CCAA3442748; Mon, 5 Dec 2022 22:57:25 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 8767E442746; Mon, 5 Dec 2022 22:57:24 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1670299044; bh=oCfw19OAXIWWeYcm4fcd2IvQR75+SbL8BdTusjn5oXY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=IXa/66mjg7JeRVZbGNdANxMr780hxvsIz7ZtMHIFptw3EcAJsJ0vGqQDBQD/Imuni xC0zKUP9hffxWW8ilv9M+DVvtTSEGXRTj2v6wAOzRXp7dhAbJVyRXcMN6mZRscP0p6 grpX35Jm4wBS8FvX5k5bjytaS/fyPQE/tN8ozs57X4K/PtXXsQvujx6aFK3y7Ec+tf Wra6r3j5Qpca3cXGuJhub2R4DqmB8oM6LQmjFUiN2InvSDTciand4YuziWzxzmZ3VT EQoVJBe3lO7wGeXJqics0C5m9M7dir2yP+HYVLuLbdQ+NEUoG5LR31oDkZLlBgH/p8 EAfeVxU905bpQ== Received: from pastel (unknown [45.72.193.52]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 4E23A122535; Mon, 5 Dec 2022 22:57:24 -0500 (EST) From: Stefan Monnier To: Yuan Fu Subject: Re: bug#59693: 29.0.50; treesitter in base buffer doesn't respond to modifications in indirect buffer correctly In-Reply-To: <0973FBCA-DFBE-4FF7-9052-2B60D2FC81DC@gmail.com> (Yuan Fu's message of "Mon, 5 Dec 2022 18:15:07 -0800") Message-ID: References: <87r0xlbjg6.fsf@miha-pc> <5F7AE71F-0327-409E-BCE9-310E1980C17A@gmail.com> <8335a0lept.fsf@gnu.org> <22B4F037-2979-4C65-8917-26D17CFBED0A@gnu.org> <83a64197ny.fsf@gnu.org> <0973FBCA-DFBE-4FF7-9052-2B60D2FC81DC@gmail.com> Date: Mon, 05 Dec 2022 22:57:23 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.319 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 59693 Cc: Eli Zaretskii , 59693@debbugs.gnu.org, miha@kamnitnik.top X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > 1. Only allow base buffer to have parsers, no change is needed for insdel= .c, That's the option I recommend, and I that's what I understood Eli was agreeing we do. > treesit_record_change can find the base buffer and update its parsers. We > can ask indirect buffers to use their base buffer=E2=80=99s parser. Unles= s the base > buffer is narrowed, I think it will work fine.=20 Exactly. Code that uses this can `widen` as needed as well. Stefan From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 06 07:18:08 2022 Received: (at 59693) by debbugs.gnu.org; 6 Dec 2022 12:18:08 +0000 Received: from localhost ([127.0.0.1]:42659 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p2Wtk-0006yY-Ee for submit@debbugs.gnu.org; Tue, 06 Dec 2022 07:18:08 -0500 Received: from eggs.gnu.org ([209.51.188.92]:54476) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p2Wth-0006yB-QJ for 59693@debbugs.gnu.org; Tue, 06 Dec 2022 07:18:06 -0500 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 1p2Wtb-0006I1-2w; Tue, 06 Dec 2022 07:17:59 -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=gUfy0NkOHrk2FZ2d4L1uNg19SD0eCR9YXNoQgfrZd8s=; b=ouavrMF1rRtOdpM5Pzc3 FwdaDpwWhzgTTDMB5oZcOAzZh+ApgG7J9eLRhjwYuhql7h+7oZJnN5axsm27x1RufOnHD05GGbaB8 lYDQAEPawypmYNSYwRmxOHZawzXqQ53L0sNH4Y8N7R9Fr56ltKDDDDVKIo9w5nATSQGJaA/qTiCGA /CV7ra4RyUwBR7ut6kAN1vQ01fHznzojmvE7kMSYNLgsW5dmlD+rwUk6759pa906FJ3Ak0K8QEj51 Fff8EYav8YLWqiNw+AByS9v1OyiWBp0rz0reV/GKEPznS4AZnk0R3bdvAZdt0ZMmHhymsF36ztz8Y X0NTyWQK0qi8zg==; 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 1p2Wta-0005L3-5w; Tue, 06 Dec 2022 07:17:58 -0500 Date: Tue, 06 Dec 2022 14:17:44 +0200 Message-Id: <83tu287ml3.fsf@gnu.org> From: Eli Zaretskii To: Yuan Fu In-Reply-To: <0973FBCA-DFBE-4FF7-9052-2B60D2FC81DC@gmail.com> (message from Yuan Fu on Mon, 5 Dec 2022 18:15:07 -0800) Subject: Re: bug#59693: 29.0.50; treesitter in base buffer doesn't respond to modifications in indirect buffer correctly References: <87r0xlbjg6.fsf@miha-pc> <5F7AE71F-0327-409E-BCE9-310E1980C17A@gmail.com> <8335a0lept.fsf@gnu.org> <22B4F037-2979-4C65-8917-26D17CFBED0A@gnu.org> <83a64197ny.fsf@gnu.org> <0973FBCA-DFBE-4FF7-9052-2B60D2FC81DC@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -0.3 (/) X-Debbugs-Envelope-To: 59693 Cc: 59693@debbugs.gnu.org, monnier@iro.umontreal.ca, miha@kamnitnik.top X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.3 (-) > From: Yuan Fu > Date: Mon, 5 Dec 2022 18:15:07 -0800 > Cc: Stefan Monnier , > 59693@debbugs.gnu.org, > miha@kamnitnik.top > > 1. Only allow base buffer to have parsers, no change is needed for insdel.c, treesit_record_change can find the base buffer and update its parsers. We can ask indirect buffers to use their base buffer’s parser. Unless the base buffer is narrowed, I think it will work fine. I think this is fine, but we need to document it. > I remember that there were a discussion along the lines of user-narrow vs low-level narrow, what was the outcome of that discussion? Nothing in particular, and I don't think it's relevant. If some mode needs to widen, it can. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Wed Dec 07 18:13:47 2022 Received: (at 59693) by debbugs.gnu.org; 7 Dec 2022 23:13:47 +0000 Received: from localhost ([127.0.0.1]:52750 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p33bj-0004Q3-C2 for submit@debbugs.gnu.org; Wed, 07 Dec 2022 18:13:47 -0500 Received: from mail-pj1-f42.google.com ([209.85.216.42]:42944) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p33bT-0004Px-D1 for 59693@debbugs.gnu.org; Wed, 07 Dec 2022 18:13:42 -0500 Received: by mail-pj1-f42.google.com with SMTP id k88-20020a17090a4ce100b00219d0b857bcso3214728pjh.1 for <59693@debbugs.gnu.org>; Wed, 07 Dec 2022 15:13:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=ZrSKpvRKQdXLbKPpY3bHragUPeDKirDPHdpGk7VEVBY=; b=cjAwA7LYRZQyH14sLTlTQ3+lLLjqT+Clc+8EiQfbMNtz4b4FQyxofl5nENf3KH1ERf y+d4j9GaIiLzl2kYdhR7Syq/W8ui3hixTUur5qQDhf7CrZIVWNNqHQpxp1g5M722oaru qNWNc4t8+N1D+zfcxwWo7W3sz1d1GmuINHkGvRU3Fn8oISthAp5Ls3Ho3A6RccZyB3xW MuaYuE1WTDFPJ2w2SUOAfstZiTQlhE+eW8QfXE1FOsBwrUxks0uhkPXpokjXZu+02V0p 1CZdAcjB5D/loE7ewgA3KYwUZhtpPK/rSZnVo6A5OQ3uyGppB/a5TogrWF97gzTjrEzl msHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ZrSKpvRKQdXLbKPpY3bHragUPeDKirDPHdpGk7VEVBY=; b=h0bFHHLpfIS5Y6SVYntX8SCFSLSgABjI0K5Ok0BVt1xtJsC7QUmIaJoY+a8bIpYdYC pa2ZsNdkIEQS4V9jn0SGKeHX4cp0qxEUtVGsfkffVuoXzM9gzfoEvhVszu4k9nrcZfkb Otu9EfJ1LOR2sLZYc4e4ZJ8jvr3cX8Sdl1biMY7+Kv1Sw2rOnUqCyI0UD2MXS9OemIfP EnRt6BKiNt5KHgXqIi3sDyPLJNlGmMbNXJDHxfJ3eAotRm/sMJIxVp3jiDAQ5apPO91h a8W+lC0BihDtwJcitEmRf8rmvHxIwVQEnLnbGQ07fccIKlv+KXam19BQWZtqtpktQ9mD DQ9A== X-Gm-Message-State: ANoB5pkMBDcX3KiQZxOFqAcpGab9o774wvU6mUBfLxuCe64ckOkNf4FC jmzGruvB0XEfoay8H4mCQmA= X-Google-Smtp-Source: AA0mqf5/kOdEJI7xDNeADOsIZ/0n5b1mU/tp28KGp8/7qzW5YFVp2TdMqt4TpuiTSqTXoOs/SqlzKA== X-Received: by 2002:a17:902:e892:b0:188:f0da:c25c with SMTP id w18-20020a170902e89200b00188f0dac25cmr1783215plg.14.1670454801629; Wed, 07 Dec 2022 15:13:21 -0800 (PST) Received: from smtpclient.apple (cpe-172-117-161-177.socal.res.rr.com. [172.117.161.177]) by smtp.gmail.com with ESMTPSA id i20-20020a170902e49400b00168dadc7354sm15097806ple.78.2022.12.07.15.13.20 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Dec 2022 15:13:21 -0800 (PST) From: Yuan Fu Message-Id: <77899171-04F5-4BB2-BE26-4C999DAB0CA0@gmail.com> Content-Type: multipart/mixed; boundary="Apple-Mail=_33EA85EC-285A-4797-BC72-7219836DFFD9" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: bug#59693: 29.0.50; treesitter in base buffer doesn't respond to modifications in indirect buffer correctly Date: Wed, 7 Dec 2022 15:13:19 -0800 In-Reply-To: <83tu287ml3.fsf@gnu.org> To: Eli Zaretskii References: <87r0xlbjg6.fsf@miha-pc> <5F7AE71F-0327-409E-BCE9-310E1980C17A@gmail.com> <8335a0lept.fsf@gnu.org> <22B4F037-2979-4C65-8917-26D17CFBED0A@gnu.org> <83a64197ny.fsf@gnu.org> <0973FBCA-DFBE-4FF7-9052-2B60D2FC81DC@gmail.com> <83tu287ml3.fsf@gnu.org> X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Spam-Score: 2.0 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > On Dec 6, 2022, at 4:17 AM, Eli Zaretskii wrote: > >> From: Yuan Fu >> Date: Mon, 5 Dec 2022 18:15:07 -0800 >> Cc: Stefan Monnier , >> 59693@debbugs.gnu.org, >> miha@kamnitnik.top >> >> 1. Only [...] Content analysis details: (2.0 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 2.0 PDS_OTHER_BAD_TLD Untrustworthy TLDs [URI: kamnitnik.top (top)] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (casouri[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.216.42 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [209.85.216.42 listed in wl.mailspike.net] -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders X-Debbugs-Envelope-To: 59693 Cc: 59693@debbugs.gnu.org, Stefan Monnier , miha@kamnitnik.top X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) --Apple-Mail=_33EA85EC-285A-4797-BC72-7219836DFFD9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Dec 6, 2022, at 4:17 AM, Eli Zaretskii wrote: >=20 >> From: Yuan Fu >> Date: Mon, 5 Dec 2022 18:15:07 -0800 >> Cc: Stefan Monnier , >> 59693@debbugs.gnu.org, >> miha@kamnitnik.top >>=20 >> 1. Only allow base buffer to have parsers, no change is needed for = insdel.c, treesit_record_change can find the base buffer and update its = parsers. We can ask indirect buffers to use their base buffer=E2=80=99s = parser. Unless the base buffer is narrowed, I think it will work fine.=20= >=20 > I think this is fine, but we need to document it. >=20 >> I remember that there were a discussion along the lines of = user-narrow vs low-level narrow, what was the outcome of that = discussion? >=20 > Nothing in particular, and I don't think it's relevant. If some mode = needs > to widen, it can. >=20 > Thanks. Here is a patch that does #1. Yuan --Apple-Mail=_33EA85EC-285A-4797-BC72-7219836DFFD9 Content-Disposition: attachment; filename=indirect.patch Content-Type: application/octet-stream; x-unix-mode=0644; name="indirect.patch" Content-Transfer-Encoding: quoted-printable =46rom=2092f3fe1fe6cb021b24247b518fbe852592c0852c=20Mon=20Sep=2017=20= 00:00:00=202001=0AFrom:=20Yuan=20Fu=20=0ADate:=20Wed,=20= 7=20Dec=202022=2014:50:16=20-0800=0ASubject:=20[PATCH]=20Make=20indirect=20= buffers=20use=20tree-sitter=20parsers=20in=20their=20base=0A=20buffer=0A=0A= *=20src/treesit.c=20(treesit_record_change):=20Always=20use=20the=20base=20= buffer.=0A(Ftreesit_parser_create):=20Always=20use=20the=20base=20= buffer.=20=20Also=20change=20the=0Afor=20loop=20into=20FOR_EACH_TAIL=20= (stylistic=20change).=0A(Ftreesit_parser_list):=20Always=20use=20the=20= base=20buffer.=0A=0A*=20doc/lispref/parsing.texi=20(Using=20Parser):=20= Update=20manual.=0A*=20test/src/treesit-tests.el=20= (treesit-indirect-buffer):=20New=20test.=0A---=0A=20= doc/lispref/parsing.texi=20=20|=2012=20++++++++-=0A=20src/treesit.c=20=20= =20=20=20=20=20=20=20=20=20=20=20|=2056=20= +++++++++++++++++++++++++++------------=0A=20test/src/treesit-tests.el=20= |=2034=20++++++++++++++++++++++++=0A=203=20files=20changed,=2084=20= insertions(+),=2018=20deletions(-)=0A=0Adiff=20--git=20= a/doc/lispref/parsing.texi=20b/doc/lispref/parsing.texi=0Aindex=20= 3223875320a..98582227fd7=20100644=0A---=20a/doc/lispref/parsing.texi=0A= +++=20b/doc/lispref/parsing.texi=0A@@=20-409,6=20+409,14=20@@=20Using=20= Parser=0A=20By=20default,=20this=20function=20reuses=20a=20parser=20if=20= one=20already=20exists=20for=0A=20@var{language}=20in=20@var{buffer},=20= but=20if=20@var{no-reuse}=20is=0A=20non-@code{nil},=20this=20function=20= always=20creates=20a=20new=20parser.=0A+=0A+If=20@var{buffer}=20(or=20= the=20current=20buffer)=20is=20an=20indirect=20buffer,=20its=0A+base=20= buffer=20is=20used=20instead.=20=20That=20is,=20indirect=20buffers=20= uses=20their=0A+base=20buffer's=20parsers.=20=20If=20the=20base=20buffer=20= is=20narrowed,=20an=20indirect=0A+buffer=20might=20not=20be=20able=20to=20= retrieve=20information=20of=20the=20portion=20of=20the=0A+buffer=20text=20= that=20are=20invisible=20in=20the=20base=20buffer.=20=20Lisp=20programs=0A= +should=20widen=20as=20necessary=20should=20they=20want=20to=20use=20a=20= parser=20in=20an=0A+indirect=20buffer.=0A=20@end=20defun=0A=20=0A=20= Given=20a=20parser,=20we=20can=20query=20information=20about=20it.=0A@@=20= -447,7=20+455,9=20@@=20Using=20Parser=0A=20@defun=20treesit-parser-list=20= &optional=20buffer=0A=20This=20function=20returns=20the=20parser=20list=20= of=20@var{buffer}.=20=20If=0A=20@var{buffer}=20is=20@code{nil}=20or=20= omitted,=20it=20defaults=20to=20the=20current=0A-buffer.=0A+buffer.=20=20= If=20@var{buffer}=20(or=20the=20current=20buffer)=20is=20an=20indirect=0A= +buffer,=20its=20base=20buffer=20is=20used=20instead.=20=20That=20is,=20= indirect=20buffers=0A+uses=20their=20base=20buffer's=20parsers.=0A=20= @end=20defun=0A=20=0A=20@defun=20treesit-parser-delete=20parser=0Adiff=20= --git=20a/src/treesit.c=20b/src/treesit.c=0Aindex=20= 8b485ca4ece..74370cd772d=20100644=0A---=20a/src/treesit.c=0A+++=20= b/src/treesit.c=0A@@=20-384,7=20+384,10=20@@=20#define=20= ts_tree_root_node=20fn_ts_tree_root_node=0A=20=20=20=20mysteriously=20= drops.=20=203)=20what=20if=20a=20user=20uses=20so=20many=20stuff=20that=20= the=0A=20=20=20=20default=20cache=20size=20(20)=20is=20not=20enough=20= and=20we=20end=20up=20thrashing?=0A=20=20=20=20These=20are=20all=20= imaginary=20scenarios=20but=20they=20are=20not=20impossible=0A-=20=20=20= :-)=20*/=0A+=20=20=20:-)=0A+=0A+=20=20=20Parsers=20in=20indirect=20= buffers:=20We=20make=20indirect=20buffers=20to=20share=20the=0A+=20=20=20= parser=20of=20its=20base=20buffer.=20=20See=20bug#59693=20for=20= reasoning.=20=20*/=0A=20=0A=20=0C=0A=20/***=20Initialization=20*/=0A@@=20= -697,9=20+700,10=20@@=20treesit_tree_edit_1=20(TSTree=20*tree,=20= ptrdiff_t=20start_byte,=0A=20treesit_record_change=20(ptrdiff_t=20= start_byte,=20ptrdiff_t=20old_end_byte,=0A=20=09=09=20=20=20=20=20=20=20= ptrdiff_t=20new_end_byte)=0A=20{=0A-=20=20Lisp_Object=20parser_list;=0A-=0A= -=20=20parser_list=20=3D=20BVAR=20(current_buffer,=20ts_parser_list);=0A= +=20=20struct=20buffer=20*base_buffer=20=3D=20current_buffer;=0A+=20=20= if=20(current_buffer->base_buffer)=0A+=20=20=20=20base_buffer=20=3D=20= current_buffer->base_buffer;=0A+=20=20Lisp_Object=20parser_list=20=3D=20= BVAR=20(base_buffer,=20ts_parser_list);=0A=20=0A=20=20=20= FOR_EACH_TAIL_SAFE=20(parser_list)=0A=20=20=20=20=20{=0A@@=20-1252,12=20= +1256,19=20@@=20DEFUN=20("treesit-parser-create",=0A=20=20=20=20=20=20=20= =201,=203,=200,=0A=20=20=20=20=20=20=20=20doc:=20/*=20Create=20and=20= return=20a=20parser=20in=20BUFFER=20for=20LANGUAGE.=0A=20=0A-The=20= parser=20is=20automatically=20added=20to=20BUFFER's=20parser=20list,=20= as=0A-returned=20by=20`treesit-parser-list'.=0A-LANGUAGE=20is=20a=20= language=20symbol.=20=20If=20BUFFER=20is=20nil=20or=20omitted,=20it=0A= -defaults=20to=20the=20current=20buffer.=20=20If=20BUFFER=20already=20= has=20a=20parser=20for=0A-LANGUAGE,=20return=20that=20parser,=20but=20if=20= NO-REUSE=20is=20non-nil,=20always=0A-create=20a=20new=20parser.=20=20*/)=0A= +The=20parser=20is=20automatically=20added=20to=20BUFFER's=20parser=20= list,=20as=20returned=0A+by=20`treesit-parser-list'.=20=20LANGUAGE=20is=20= a=20language=20symbol.=20=20If=20BUFFER=0A+is=20nil=20or=20omitted,=20it=20= defaults=20to=20the=20current=20buffer.=20=20If=20BUFFER=0A+already=20= has=20a=20parser=20for=20LANGUAGE,=20return=20that=20parser,=20but=20if=20= NO-REUSE=0A+is=20non-nil,=20always=20create=20a=20new=20parser.=0A+=0A= +If=20BUFFER=20(or=20the=20current=20buffer)=20is=20an=20indirect=20= buffer,=20its=20base=0A+buffer=20is=20used=20instead.=20=20That=20is,=20= indirect=20buffers=20uses=20their=20base=0A+buffer's=20parsers.=20=20If=20= the=20base=20buffer=20is=20narrowed,=20an=20indirect=20buffer=0A+might=20= not=20be=20able=20to=20retrieve=20information=20of=20the=20portion=20of=20= the=20buffer=0A+text=20that=20are=20invisible=20in=20the=20base=20= buffer.=20=20Lisp=20programs=20should=0A+widen=20as=20necessary=20should=20= they=20want=20to=20use=20a=20parser=20in=20an=20indirect=0A+buffer.=20=20= */)=0A=20=20=20(Lisp_Object=20language,=20Lisp_Object=20buffer,=20= Lisp_Object=20no_reuse)=0A=20{=0A=20=20=20treesit_initialize=20();=0A@@=20= -1271,16=20+1282,21=20@@=20DEFUN=20("treesit-parser-create",=0A=20=20=20=20= =20=20=20CHECK_BUFFER=20(buffer);=0A=20=20=20=20=20=20=20buf=20=3D=20= XBUFFER=20(buffer);=0A=20=20=20=20=20}=0A+=20=20if=20(buf->base_buffer)=0A= +=20=20=20=20buf=20=3D=20buf->base_buffer;=0A+=0A=20=20=20= treesit_check_buffer_size=20(buf);=0A=20=0A=20=20=20/*=20See=20if=20we=20= can=20reuse=20a=20parser.=20=20*/=0A-=20=20for=20(Lisp_Object=20tail=20=3D= =20BVAR=20(buf,=20ts_parser_list);=0A-=20=20=20=20=20=20=20NILP=20= (no_reuse)=20&&=20!NILP=20(tail);=0A-=20=20=20=20=20=20=20tail=20=3D=20= XCDR=20(tail))=0A+=20=20if=20(NILP=20(no_reuse))=0A=20=20=20=20=20{=0A-=20= =20=20=20=20=20struct=20Lisp_TS_Parser=20*parser=20=3D=20XTS_PARSER=20= (XCAR=20(tail));=0A-=20=20=20=20=20=20if=20(EQ=20= (parser->language_symbol,=20language))=0A-=09return=20XCAR=20(tail);=0A+=20= =20=20=20=20=20Lisp_Object=20tail=20=3D=20BVAR=20(buf,=20= ts_parser_list);=0A+=20=20=20=20=20=20FOR_EACH_TAIL=20(tail)=0A+=20=20=20= =20=20=20{=0A+=09struct=20Lisp_TS_Parser=20*parser=20=3D=20XTS_PARSER=20= (XCAR=20(tail));=0A+=09if=20(EQ=20(parser->language_symbol,=20language))=0A= +=09=20=20return=20XCAR=20(tail);=0A+=20=20=20=20=20=20}=0A=20=20=20=20=20= }=0A=20=0A=20=20=20/*=20Load=20language.=20=20*/=0A@@=20-1329,7=20= +1345,10=20@@=20DEFUN=20("treesit-parser-list",=0A=20=20=20=20=20=20=20=20= Ftreesit_parser_list,=20Streesit_parser_list,=0A=20=20=20=20=20=20=20=20= 0,=201,=200,=0A=20=20=20=20=20=20=20=20doc:=20/*=20Return=20BUFFER's=20= parser=20list.=0A-BUFFER=20defaults=20to=20the=20current=20buffer.=20=20= */)=0A+=0A+BUFFER=20defaults=20to=20the=20current=20buffer.=20=20If=20= BUFFER=20(or=20the=20current=0A+buffer)=20is=20an=20indirect=20buffer,=20= its=20base=20buffer=20is=20used=20instead.=20=20That=0A+is,=20indirect=20= buffers=20uses=20their=20base=20buffer's=20parsers.=20=20*/)=0A=20=20=20= (Lisp_Object=20buffer)=0A=20{=0A=20=20=20struct=20buffer=20*buf;=0A@@=20= -1340,6=20+1359,9=20@@=20DEFUN=20("treesit-parser-list",=0A=20=20=20=20=20= =20=20CHECK_BUFFER=20(buffer);=0A=20=20=20=20=20=20=20buf=20=3D=20= XBUFFER=20(buffer);=0A=20=20=20=20=20}=0A+=20=20if=20(buf->base_buffer)=0A= +=20=20=20=20buf=20=3D=20buf->base_buffer;=0A+=0A=20=20=20/*=20Return=20= a=20fresh=20list=20so=20messing=20with=20that=20list=20doesn't=20affect=20= our=0A=20=20=20=20=20=20internal=20data.=20=20*/=0A=20=20=20Lisp_Object=20= return_list=20=3D=20Qnil;=0Adiff=20--git=20a/test/src/treesit-tests.el=20= b/test/src/treesit-tests.el=0Aindex=20aba12759c34..1cc2217bd3b=20100644=0A= ---=20a/test/src/treesit-tests.el=0A+++=20b/test/src/treesit-tests.el=0A= @@=20-161,6=20+161,40=20@@=20treesit-node-api=0A=20=20=20=20=20=20=20= (should=20(treesit-node-eq=20root-node=20root-node))=0A=20=20=20=20=20=20= =20(should=20(not=20(treesit-node-eq=20root-node=20doc-node))))))=0A=20=0A= +(ert-deftest=20treesit-indirect-buffer=20()=0A+=20=20"Tests=20for=20= indirect=20buffers."=0A+=20=20(skip-unless=20= (treesit-language-available-p=20'json))=0A+=20=20(let=20((base=20= (get-buffer-create=20"*treesit=20test*"))=0A+=20=20=20=20=20=20=20=20= parser=20indirect)=0A+=20=20=20=20(unwind-protect=0A+=20=20=20=20=20=20=20= =20(progn=0A+=20=20=20=20=20=20=20=20=20=20(with-current-buffer=20base=0A= +=20=20=20=20=20=20=20=20=20=20=20=20(setq=20indirect=20= (clone-indirect-buffer=20"*treesit=20test=201*"=20nil)))=0A+=20=20=20=20=20= =20=20=20=20=20(with-current-buffer=20indirect=0A+=20=20=20=20=20=20=20=20= =20=20=20=20(setq=20parser=20(treesit-parser-create=20'json)))=0A+=20=20=20= =20=20=20=20=20=20=20;;=201.=20Parser=20created=20in=20the=20indirect=20= buffer=20should=20be=0A+=20=20=20=20=20=20=20=20=20=20;;=20actually=20be=20= created=20in=20the=20base=20buffer.=0A+=20=20=20=20=20=20=20=20=20=20= (with-current-buffer=20base=0A+=20=20=20=20=20=20=20=20=20=20=20=20= (should=20(equal=20(list=20parser)=0A+=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20(treesit-parser-list)))=0A+=20= =20=20=20=20=20=20=20=20=20=20=20(insert=20"[1,2,3]"))=0A+=20=20=20=20=20= =20=20=20=20=20;;=20Change=20in=20the=20base=20buffer=20should=20be=20= reflected=20in=20the=0A+=20=20=20=20=20=20=20=20=20=20;;=20indirect=20= buffer.=0A+=20=20=20=20=20=20=20=20=20=20(with-current-buffer=20indirect=0A= +=20=20=20=20=20=20=20=20=20=20=20=20(should=20(eq=20(treesit-node-end=0A= +=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20(treesit-buffer-root-node))=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=208))=0A+=20=20=20=20=20=20=20=20=20=20=20= =20(erase-buffer))=0A+=20=20=20=20=20=20=20=20=20=20;;=20Change=20in=20= the=20indirect=20buffer=20should=20be=20reflected=20in=20the=0A+=20=20=20= =20=20=20=20=20=20=20;;=20base=20buffer.=0A+=20=20=20=20=20=20=20=20=20=20= (with-current-buffer=20base=0A+=20=20=20=20=20=20=20=20=20=20=20=20= (should=20(eq=20(treesit-node-end=0A+=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20(treesit-buffer-root-node))=0A+=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=201))=0A= +=20=20=20=20=20=20=20=20=20=20=20=20(erase-buffer)))=0A+=20=20=20=20=20=20= (kill-buffer=20base)=0A+=20=20=20=20=20=20(kill-buffer=20indirect))))=0A= +=0A=20(ert-deftest=20treesit-query-api=20()=0A=20=20=20"Tests=20for=20= query=20API."=0A=20=20=20(skip-unless=20(treesit-language-available-p=20= 'json))=0A--=20=0A2.33.1=0A=0A= --Apple-Mail=_33EA85EC-285A-4797-BC72-7219836DFFD9 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_33EA85EC-285A-4797-BC72-7219836DFFD9-- From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 08 01:47:36 2022 Received: (at 59693) by debbugs.gnu.org; 8 Dec 2022 06:47:36 +0000 Received: from localhost ([127.0.0.1]:54774 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p3Agy-0004jV-F5 for submit@debbugs.gnu.org; Thu, 08 Dec 2022 01:47:36 -0500 Received: from eggs.gnu.org ([209.51.188.92]:41738) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p3Agu-0004jP-Kr for 59693@debbugs.gnu.org; Thu, 08 Dec 2022 01:47:35 -0500 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 1p3Agn-0002np-IH; Thu, 08 Dec 2022 01:47:25 -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=8TxXK1p2oXIjnpYKr7eAXD3nKZ5zO7P1X+rvDGQe4uo=; b=XooUEEXwasKS3DM2RbV9 px9YsXeb6YuC2u8UtQZiHWIry8pSk8FI2ln3Z0AcrvZaermREsK/LZCsM8ISnmb39642fhDCeS+j6 PbJGuW4MrDDTSgYIuWn50zGNvTPSsvhYjPIEvZkAfnJWrgmGksfQQK5MDX4ZBvp3LU1MpqhBJ9kpS IE8wCsLlNXAuSNCMV0oD5wPIg7ap6Sll5nUN+NJ+vB0uaG1EdbNWMvih6wjUQamsTIcuZW+bObdJC ZzYjmq2HWNhPrGh5jnoCFqtjk7h3Fn4wHkBn7ruuVx7bBDje9ze6/QGqzVHnMZsAiJnz117ysMgCh xd0kIIq+7sg1tw==; 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 1p3Agm-0002bU-BJ; Thu, 08 Dec 2022 01:47:24 -0500 Date: Thu, 08 Dec 2022 08:47:13 +0200 Message-Id: <83zgby2xzi.fsf@gnu.org> From: Eli Zaretskii To: Yuan Fu In-Reply-To: <77899171-04F5-4BB2-BE26-4C999DAB0CA0@gmail.com> (message from Yuan Fu on Wed, 7 Dec 2022 15:13:19 -0800) Subject: Re: bug#59693: 29.0.50; treesitter in base buffer doesn't respond to modifications in indirect buffer correctly References: <87r0xlbjg6.fsf@miha-pc> <5F7AE71F-0327-409E-BCE9-310E1980C17A@gmail.com> <8335a0lept.fsf@gnu.org> <22B4F037-2979-4C65-8917-26D17CFBED0A@gnu.org> <83a64197ny.fsf@gnu.org> <0973FBCA-DFBE-4FF7-9052-2B60D2FC81DC@gmail.com> <83tu287ml3.fsf@gnu.org> <77899171-04F5-4BB2-BE26-4C999DAB0CA0@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -0.3 (/) X-Debbugs-Envelope-To: 59693 Cc: 59693@debbugs.gnu.org, monnier@iro.umontreal.ca, miha@kamnitnik.top X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.3 (-) > From: Yuan Fu > Date: Wed, 7 Dec 2022 15:13:19 -0800 > Cc: Stefan Monnier , > 59693@debbugs.gnu.org, > miha@kamnitnik.top > > >> 1. Only allow base buffer to have parsers, no change is needed for insdel.c, treesit_record_change can find the base buffer and update its parsers. We can ask indirect buffers to use their base buffer’s parser. Unless the base buffer is narrowed, I think it will work fine. > > > > I think this is fine, but we need to document it. > > > >> I remember that there were a discussion along the lines of user-narrow vs low-level narrow, what was the outcome of that discussion? > > > > Nothing in particular, and I don't think it's relevant. If some mode needs > > to widen, it can. > > > > Thanks. > > Here is a patch that does #1. Thanks, a few minor comments for documentation below. > +If @var{buffer} (or the current buffer) is an indirect buffer, its > +base buffer is used instead. That is, indirect buffers uses their ^^^^^^^^^^^^^^^^^^^^^ "use", in plural. > @@ -447,7 +455,9 @@ Using Parser > @defun treesit-parser-list &optional buffer > This function returns the parser list of @var{buffer}. If > @var{buffer} is @code{nil} or omitted, it defaults to the current > -buffer. > +buffer. If @var{buffer} (or the current buffer) is an indirect ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I'd say more concisely If that buffer is an indirect buffer, ... And please add a cross-reference to the node where indirect buffers are described. > +buffer, its base buffer is used instead. That is, indirect buffers > +uses their base buffer's parsers. ^^^^ "use". > + Parsers in indirect buffers: We make indirect buffers to share the > + parser of its base buffer. See bug#59693 for reasoning. */ I'd rather have a short summary of the reasoning here than ask the readers to go to the bug tracker and read a long discussion. Just explain why indirect buffers present a problem for a parser, and then say that we decided to do this as the easiest, simplest solution. > +If BUFFER (or the current buffer) is an indirect buffer, its base > +buffer is used instead. That is, indirect buffers uses their base ^^^^ "use" > +buffer's parsers. If the base buffer is narrowed, an indirect buffer > +might not be able to retrieve information of the portion of the buffer > +text that are invisible in the base buffer. Lisp programs should > +widen as necessary should they want to use a parser in an indirect > +buffer. */) Here I would remove the second sentence: it is appropriate for the manual, but is redundant in the doc string, since the next sentence says it all. > @@ -1329,7 +1345,10 @@ DEFUN ("treesit-parser-list", > Ftreesit_parser_list, Streesit_parser_list, > 0, 1, 0, > doc: /* Return BUFFER's parser list. > -BUFFER defaults to the current buffer. */) > + > +BUFFER defaults to the current buffer. If BUFFER (or the current > +buffer) is an indirect buffer, its base buffer is used instead. That > +is, indirect buffers uses their base buffer's parsers. */) ^^^^ "use" Otherwise, LGTM. From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 09 20:41:14 2022 Received: (at 59693-done) by debbugs.gnu.org; 10 Dec 2022 01:41:14 +0000 Received: from localhost ([127.0.0.1]:39723 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p3orZ-0001Tz-Tl for submit@debbugs.gnu.org; Fri, 09 Dec 2022 20:41:14 -0500 Received: from mail-pj1-f46.google.com ([209.85.216.46]:34544) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p3orY-0001Tp-MI for 59693-done@debbugs.gnu.org; Fri, 09 Dec 2022 20:41:13 -0500 Received: by mail-pj1-f46.google.com with SMTP id hd14-20020a17090b458e00b0021909875bccso9221454pjb.1 for <59693-done@debbugs.gnu.org>; Fri, 09 Dec 2022 17:41:12 -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=hFyM+MDd1NtINxm5b31tfYXFJLJsgqiOzSaqcOJBuwE=; b=C2F3X98QkicnNWyxj/snnKv5J3Sog6wVGt4k9NHnHN5eKZALhm2MYwSFHlPgB5qfof hppPkst/xexxpyiuyfx1zo4Mrg/UjCpZZkqCqVfJBG6O50kDM19XKK3cANRyc40+MM9S 0zyUlVgB4UJuFBrOgyC1tYjIvZu8uecBVx+Ouya+dIYls8kntjlryhx98I9gVjlfwSoM RkUvGj+AaZzQTlhf22iPxAFik+SIn47vJj6rY5hTVM1VKZkEyZE8yWEzDVUBkdl95Urg lmsHol/UcDy4zoyoUdbWxgg/eOCv0wppTcUcDOz8cljbexXf8BDSqTBgGC0VW5wcOmnV 4nJg== 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=hFyM+MDd1NtINxm5b31tfYXFJLJsgqiOzSaqcOJBuwE=; b=755iSbaBhbjNmmzOeF36rSJUejfrDBOPH9y27sSvbvrodds2w2/h1zMZbNEcSfkkz+ LKCtBexDY65BoD636zZ7VyPFb+WQwWSXClavy7CwALWrdB0gBgx3Y1/mKFGAyI52OB9I XCn/0HenDrYqsp8KHAE2njlr9JsgZN6iDoKp4la2W58S7igIu6i8iBM5/7mMQYwDs8r7 UIjT+3MR30ss2rCxpy9sP/g7Br263NTLEOtAOCiTaJjeVqP9/JOukOft+C84mh8YSTc4 5aibeSl3+vxjKaQsMPdi4B7RcqpHCd2PdhR9A6qLr9HeHpmBAFfiTD/S7VFysmYYoXRP 44dQ== X-Gm-Message-State: ANoB5pmoBTvepnpTg9fBMIRlANtUIscSmsZpQHUPEElvcnvzNx6RzgGi S8H6u3w0d8xHXCIsGjka399ZffSA/ax9aQ== X-Google-Smtp-Source: AA0mqf4w+4pBPAfjPQSKxsGai6Cl11x/Npg6JPBVyVu5AfJcBnY4BYhMNFNq6b+ZofwW2WVdUH9zkQ== X-Received: by 2002:a05:6a20:b295:b0:ac:6a79:29a with SMTP id ei21-20020a056a20b29500b000ac6a79029amr8334015pzb.54.1670636466742; Fri, 09 Dec 2022 17:41:06 -0800 (PST) Received: from smtpclient.apple (cpe-172-117-161-177.socal.res.rr.com. [172.117.161.177]) by smtp.gmail.com with ESMTPSA id r1-20020a6560c1000000b00477def759cbsm1531399pgv.58.2022.12.09.17.41.05 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Dec 2022 17:41:06 -0800 (PST) From: Yuan Fu Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: bug#59693: 29.0.50; treesitter in base buffer doesn't respond to modifications in indirect buffer correctly Message-Id: Date: Fri, 9 Dec 2022 17:41:04 -0800 To: Eli Zaretskii X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Spam-Score: 2.0 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Eli Zaretskii writes: >> From: Yuan Fu >> Date: Wed, 7 Dec 2022 15:13:19 -0800 >> Cc: Stefan Monnier , >> 59693@debbugs.gnu.org, >> miha@kamnitnik.top >> >> >> 1. Only allow base buffer to have parsers, no change is nee [...] Content analysis details: (2.0 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.216.46 listed in list.dnswl.org] 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 2.0 PDS_OTHER_BAD_TLD Untrustworthy TLDs [URI: kamnitnik.top (top)] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (casouri[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [209.85.216.46 listed in wl.mailspike.net] -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders X-Debbugs-Envelope-To: 59693-done Cc: 59693-done@debbugs.gnu.org, miha@kamnitnik.top, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) Eli Zaretskii writes: >> From: Yuan Fu >> Date: Wed, 7 Dec 2022 15:13:19 -0800 >> Cc: Stefan Monnier , >> 59693@debbugs.gnu.org, >> miha@kamnitnik.top >>=20 >> >> 1. Only allow base buffer to have parsers, no change is needed >> >> for insdel.c, treesit_record_change can find the base buffer and >> >> update its parsers. We can ask indirect buffers to use their base >> >> buffer=E2=80=99s parser. Unless the base buffer is narrowed, I = think it >> >> will work fine. >> >=20 >> > I think this is fine, but we need to document it. >> >=20 >> >> I remember that there were a discussion along the lines of = user-narrow vs low-level narrow, what was the outcome of that = discussion? >> >=20 >> > Nothing in particular, and I don't think it's relevant. If some = mode needs >> > to widen, it can. >> >=20 >> > Thanks. >>=20 >> Here is a patch that does #1. > > Thanks, a few minor comments for documentation below. > >> +If @var{buffer} (or the current buffer) is an indirect buffer, its >> +base buffer is used instead. That is, indirect buffers uses their > ^^^^^^^^^^^^^^^^^^^^^ > "use", in plural. > >> @@ -447,7 +455,9 @@ Using Parser >> @defun treesit-parser-list &optional buffer >> This function returns the parser list of @var{buffer}. If >> @var{buffer} is @code{nil} or omitted, it defaults to the current >> -buffer. >> +buffer. If @var{buffer} (or the current buffer) is an indirect > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > I'd say more concisely > > If that buffer is an indirect buffer, ... > > And please add a cross-reference to the node where indirect buffers > are described. > >> +buffer, its base buffer is used instead. That is, indirect buffers >> +uses their base buffer's parsers. > ^^^^ > "use". > >> + Parsers in indirect buffers: We make indirect buffers to share = the >> + parser of its base buffer. See bug#59693 for reasoning. */ > > I'd rather have a short summary of the reasoning here than ask the > readers to go to the bug tracker and read a long discussion. Just > explain why indirect buffers present a problem for a parser, and then > say that we decided to do this as the easiest, simplest solution. > >> +If BUFFER (or the current buffer) is an indirect buffer, its base >> +buffer is used instead. That is, indirect buffers uses their base > ^^^^ > "use" > >> +buffer's parsers. If the base buffer is narrowed, an indirect = buffer >> +might not be able to retrieve information of the portion of the = buffer >> +text that are invisible in the base buffer. Lisp programs should >> +widen as necessary should they want to use a parser in an indirect >> +buffer. */) > > Here I would remove the second sentence: it is appropriate for the > manual, but is redundant in the doc string, since the next sentence > says it all. > >> @@ -1329,7 +1345,10 @@ DEFUN ("treesit-parser-list", >> Ftreesit_parser_list, Streesit_parser_list, >> 0, 1, 0, >> doc: /* Return BUFFER's parser list. >> -BUFFER defaults to the current buffer. */) >> + >> +BUFFER defaults to the current buffer. If BUFFER (or the current >> +buffer) is an indirect buffer, its base buffer is used instead. = That >> +is, indirect buffers uses their base buffer's parsers. */) > ^^^^ > "use" > > Otherwise, LGTM. Cool, I fixed those and pushed. Yuan From unknown Thu Jun 19 14:13:17 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sat, 07 Jan 2023 12:24:11 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator