From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Yuan Fu Newsgroups: gmane.emacs.bugs Subject: bug#59693: 29.0.50; treesitter in base buffer doesn't respond to modifications in indirect buffer correctly Date: Fri, 9 Dec 2022 17:41:04 -0800 Message-ID: References: <87r0xlbjg6.fsf@miha-pc> Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20315"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 59693-done@debbugs.gnu.org, miha@kamnitnik.top, monnier@iro.umontreal.ca To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Dec 10 02:42:15 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1p3osZ-00055P-Nc for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 10 Dec 2022 02:42:15 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p3osO-0000OM-K0; Fri, 09 Dec 2022 20:42:04 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p3osM-0000NW-R8 for bug-gnu-emacs@gnu.org; Fri, 09 Dec 2022 20:42:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1p3osM-0004k6-Id for bug-gnu-emacs@gnu.org; Fri, 09 Dec 2022 20:42:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1p3osM-0001Ul-E1 for bug-gnu-emacs@gnu.org; Fri, 09 Dec 2022 20:42:02 -0500 In-Reply-To: <87r0xlbjg6.fsf@miha-pc> Resent-From: Yuan Fu Original-Sender: "Debbugs-submit" Resent-To: bug-gnu-emacs@gnu.org Resent-Date: Sat, 10 Dec 2022 01:42:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: cc-closed 59693 X-GNU-PR-Package: emacs Mail-Followup-To: 59693@debbugs.gnu.org, casouri@gmail.com, miha@kamnitnik.top Original-Received: via spool by 59693-done@debbugs.gnu.org id=D59693.16706364745707 (code D ref 59693); Sat, 10 Dec 2022 01:42:02 +0000 Original-Received: (at 59693-done) by debbugs.gnu.org; 10 Dec 2022 01:41:14 +0000 Original-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 Original-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 Original-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) Original-Received: from smtpclient.apple (cpe-172-117-161-177.socal.res.rr.com. [172.117.161.177]) by smtp.gmail.com with ESMTPSA id 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) X-Mailer: Apple Mail (2.3696.120.41.1.1) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:250480 Archived-At: 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