From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#62333: 30.0.50; Issue with tree-sitter syntax tree during certain changes Date: Sat, 1 Apr 2023 04:53:13 +0300 Message-ID: <8921484d-b027-365f-abb9-e1c56f25b6ab@yandex.ru> References: <87fs9yur7r.fsf@gmail.com> <1ca302bf-99dc-7f9e-8544-063064a1cb21@yandex.ru> <831qlcdisi.fsf@gnu.org> <398721ad-79b0-3f6d-97b3-4902d9bfbe39@yandex.ru> <83wn34c2qa.fsf@gnu.org> <3b3d82d1-f0f6-a768-a5db-8dc9386a5a34@yandex.ru> <83r0tcbz8g.fsf@gnu.org> <1967361679760225@umbzx4hqxrw5qxo7.sas.yp-c.yandex.net> <83mt40bxzd.fsf@gnu.org> <83jzz4bugh.fsf@gnu.org> <3d64520c-54da-a04a-ed0d-a66b4e753f8a@yandex.ru> <831qlcaysh.fsf@gnu.org> <29679184-7366-0167-9e94-def97048f663@yandex.ru> <83v8inal29.fsf@gnu.org> <9886ffa5-ead2-50d5-a325-f6704b736ada@yandex.ru> <728618716b8c5349d27e@heytings.org> <83bkke9uue.fsf@gnu.org> <83ilel861g.fsf@gnu.org> <290987e0-821e-a231-c1c4-b40bb9542ffe@yandex.ru> <83lejf7r2o.fsf@gnu.org> <1c4c8b47-e4aa-242a-bb66-1d6b5c879de4@yandex.ru> <83wn2x30js.fsf@gnu.org> <7d4c5109-63ec-76a5-cab4-42f35dab9778@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35175"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Cc: Wilhelm Kirschbaum , Eli Zaretskii , Gregory Heytings , 62333@debbugs.gnu.org To: Yuan Fu Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Apr 01 03:54:18 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1piQRd-0008wp-91 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 01 Apr 2023 03:54:17 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1piQRQ-0004Nd-UY; Fri, 31 Mar 2023 21:54:05 -0400 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 1piQRO-0004IO-S4 for bug-gnu-emacs@gnu.org; Fri, 31 Mar 2023 21:54:02 -0400 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 1piQRO-0002gb-DL for bug-gnu-emacs@gnu.org; Fri, 31 Mar 2023 21:54:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1piQRO-0000RZ-0a for bug-gnu-emacs@gnu.org; Fri, 31 Mar 2023 21:54:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 01 Apr 2023 01:54:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62333 X-GNU-PR-Package: emacs Original-Received: via spool by 62333-submit@debbugs.gnu.org id=B62333.16803140041658 (code B ref 62333); Sat, 01 Apr 2023 01:54:01 +0000 Original-Received: (at 62333) by debbugs.gnu.org; 1 Apr 2023 01:53:24 +0000 Original-Received: from localhost ([127.0.0.1]:34924 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1piQQm-0000Qg-G6 for submit@debbugs.gnu.org; Fri, 31 Mar 2023 21:53:24 -0400 Original-Received: from mail-wm1-f42.google.com ([209.85.128.42]:42734) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1piQQj-0000QP-Rf for 62333@debbugs.gnu.org; Fri, 31 Mar 2023 21:53:22 -0400 Original-Received: by mail-wm1-f42.google.com with SMTP id m6-20020a05600c3b0600b003ee6e324b19so14989895wms.1 for <62333@debbugs.gnu.org>; Fri, 31 Mar 2023 18:53:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1680313996; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=85sHb7YasgFxLJ26ZQkFglXu/Nfn6XO7WUs9MJ/7hZo=; b=JbWrVmZ8CFXxi8pAKynzQsUThNuEYbxZsveskJJDYqUdVzYvz9lW+DCHLhOZXb3onE zojljfhAMHCivGTCK35UFJvg4HD5NoN0KcoAtVOTgKQTNjLYYroOOl2i/iMfHqd/nDjJ BxdKBnFXQp6mZfQVpBNtak/i94cQ+hHZKfxs8Hs3HkYCIiRJ1GbPW3/8F3MPKag93pzL cVmkYVRpAXRIP+wdz2of8wcScUVkC2G35tOb4ANWbeMWW0rQyhYIvzy5Pg7GO/Ladx3V Bu+1WE0JtLfyB9rPVIp4p+4rTle8KmqoPR+1bs4aqSylyiE8tGKyFI5vNSpDd0ICDUyR velQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680313996; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=85sHb7YasgFxLJ26ZQkFglXu/Nfn6XO7WUs9MJ/7hZo=; b=wZ0+OM0Y7skUl0w0GC2pzfd5X64k4Yf+D3HULR4CndtrbFRfl7bnJxxn4TxjagkcjM g11gSSZO13Jov9fSC2lpm6lddquUP9LpXsuYw4wGRrXPKMFDkbgpVEEIXn3CdNmNMAvQ RcrKzIuRRGPC89VKDkGUVbfs9zIH6CRcAwhgszMA/3OMdze3N+MD+v2EloAnoFQW1FSM iyUKQ3AqOzmK95xZfQt8mspz+yK79+ZChgb1TCG+FV9YSBMp/s0UClh4ykvDIOEAF2l4 jxrXOsMBzS72SwxMUyOZwlmA0VhjrBe5kYhjIgtxZcR5wFphJpAuyMzvBBk3F/abpfM9 Jgxw== X-Gm-Message-State: AO0yUKU6sxhwK1M+A+dcBvm8UTNCApLcDCnzIlehiexJtCdMwWZi41E2 d18Xb7qVGPwetL+ecYsEWhk= X-Google-Smtp-Source: AK7set+unn3nayOVpTxQ7NT2GUGDz+XhvMbyv/PqfEO4rqc02LSPW1mLCf1IZm2c98dxdyeEeDWMYQ== X-Received: by 2002:a1c:7516:0:b0:3ef:3ce6:7c69 with SMTP id o22-20020a1c7516000000b003ef3ce67c69mr21784143wmc.8.1680313995794; Fri, 31 Mar 2023 18:53:15 -0700 (PDT) Original-Received: from [192.168.1.2] ([31.216.80.60]) by smtp.googlemail.com with ESMTPSA id hg13-20020a05600c538d00b003ed793d9de0sm15927687wmb.1.2023.03.31.18.53.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 31 Mar 2023 18:53:15 -0700 (PDT) Content-Language: en-US In-Reply-To: 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:259022 Archived-At: On 31/03/2023 21:43, Yuan Fu wrote: > I think the distinction lies between “I want to narrow to this defun and work on it without distraction” vs “treat this region as an isolated buffer”. The former used by users, the latter used by lisp programs like Info and mmm-mode. The former still considers the visible region part of the whole buffer, just temporarily narrowed for convenience, the latter wants to make everything thinks the visible region_is_ the whole buffer. This distinction lies in how user-level features are implemented, though. E.g. for font-lock we have the variable font-lock-dont-widen which determines whether it will widen before getting the syntax information (calling syntax-ppss and so on) and acting on it. > It might be good for tree-sitter or other parsers to be exempt from (but still acknowledges) the first kind of narrowing. This way the parser can avoid unnecessary re-parse, and always provide the optimal information. We just need to modify tree-sitter functions to check for this narrowing and don’t return anything beyond the boundaries. It’s probably going to be a lot of hair, but should be doable, I think? > > This way, most lisp programs still obeys the narrowing, but specific things like tree-sitter can choose to secretly look around while still appear to obey the narrowing, when peeking around wouldn’t hurt. And when the narrowing is really indented, tree-sitter (or other parser) knows not to look around. I'm not sure this is different from the "regular" major modes which use syntax-ppss as their parser. They also call 'widen' in a lot of cases to "peek around". So that was my point: the external requirements for tree-sitter modes' behavior don't seem that different from the "classic" modes. Narrowing in blink-matching-paren, BTW, also should have a similar cache-busting effect on syntax-ppss, with the main difference that it keeps two caches around, so it might end up reparsing only once (the narrowed parse state), hence the performance impact, over the smaller range of text, would be limited.