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, 25 Mar 2023 03:51:48 +0200 Message-ID: References: <87fs9yur7r.fsf@gmail.com> <2fd8f2b8-d9c4-c825-a789-f2d42324859f@yandex.ru> <09539C5E-23DA-4B00-A3F6-873A41D6A2CE@gmail.com> <83h6uc549z.fsf@gnu.org> <665745A2-FDC8-45DE-BFF5-2F688FC85431@gmail.com> <491b788f-c3c3-4877-daa0-f515be9f3a17@yandex.ru> <83sfduelab.fsf@gnu.org> <8FC25A01-6934-43BB-899C-CA5926BEA3CF@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32827"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Cc: Wilhelm Kirschbaum , 62333@debbugs.gnu.org To: Yuan Fu , Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Mar 25 02:52:26 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 1pft4y-0008Jk-J7 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 25 Mar 2023 02:52:24 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pft4g-0001kN-8t; Fri, 24 Mar 2023 21:52:06 -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 1pft4e-0001jy-Ms for bug-gnu-emacs@gnu.org; Fri, 24 Mar 2023 21:52:04 -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 1pft4d-0004sy-RJ for bug-gnu-emacs@gnu.org; Fri, 24 Mar 2023 21:52:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pft4c-0003nN-8e for bug-gnu-emacs@gnu.org; Fri, 24 Mar 2023 21:52: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, 25 Mar 2023 01:52:02 +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.167970911914580 (code B ref 62333); Sat, 25 Mar 2023 01:52:02 +0000 Original-Received: (at 62333) by debbugs.gnu.org; 25 Mar 2023 01:51:59 +0000 Original-Received: from localhost ([127.0.0.1]:41796 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pft4Z-0003n6-7R for submit@debbugs.gnu.org; Fri, 24 Mar 2023 21:51:59 -0400 Original-Received: from mail-wr1-f47.google.com ([209.85.221.47]:34476) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pft4X-0003mr-AK for 62333@debbugs.gnu.org; Fri, 24 Mar 2023 21:51:57 -0400 Original-Received: by mail-wr1-f47.google.com with SMTP id v1so3448621wrv.1 for <62333@debbugs.gnu.org>; Fri, 24 Mar 2023 18:51:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679709111; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=RjpFoAmwwHkswfT0rV4ePqyml0Rf7pIRU+z36FMFrvE=; b=oHlu/M/1va4X3BmLoOyr0iUhEeehtoZ7xdz/JaCoTAmFRIsldrNOXs53lG92KxK3IL SGGl2/j+rnN7920aMQH4r0aHQQVknQv8wtTNRXx/19fGQJ/VX7KkJ2W1Rbn6KRjDXgj9 AmyGS/DzPJDVnPjhDr7NJdbR9MsNlVAVCBUMxk3JCIAu9OK/4Ta7BJK0KWiTNP04Bath zQPYnOTJsnd65Z0EVgYW3rgr2Ii4FVuQf2R7sOHYOscqQfg+A58D90GUIqGlW34oZLZE 4luiXSiwXF0Og1ep2IueUBzh3gFutSTsWJ/it7HiQwr7p+AtujU3sVYukpExyIBXwjeC PgQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679709111; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=RjpFoAmwwHkswfT0rV4ePqyml0Rf7pIRU+z36FMFrvE=; b=6NqessPmGpH2jQKvj1C4iK1r+xr7fGovkH/yh+uVqn+wMPkrCKaVhnPobVs18k5V1n H017g8vSkcpd7P/X/be0xzvur0WiZM0F4UhohryySY6dolnAztggdrYIpnn4S8xszMzi stS1IhtgaTbH5Me7/tXNmxDdgWkQNIi3D4Nj62w4NXS3klmLj8GqEEcuDHg3+JLehS/V 0MeYzxBhNlm+RphI+rhqbQ+o/VKQDf2dswEInzckbq1Xy195hpzcse+0t2sZgJPYvkk3 C91Kil2Me1LF9+bvazOQBp66SkvpumR0cu12iWfz4fmPuV961zMWB64BDzKD/Dp4Qp2A nmiQ== X-Gm-Message-State: AAQBX9fs68a5pcnZ7ZBewYRX4PEC27m1lDfFM+KqUJr8I9nIokegkBsv 57BpHj4LcyO5990qTjJKEpo= X-Google-Smtp-Source: AKy350avZOxlUuVgC+NVrLL58v4UKKmciGrt30BIoMWQBX705imy1vv6gCck05XqGeoye1XMJwaZlw== X-Received: by 2002:adf:f4cd:0:b0:2da:3ef5:5a39 with SMTP id h13-20020adff4cd000000b002da3ef55a39mr3245496wrp.14.1679709111082; Fri, 24 Mar 2023 18:51:51 -0700 (PDT) Original-Received: from [192.168.0.2] ([85.132.229.92]) by smtp.googlemail.com with ESMTPSA id q7-20020adff947000000b002d419f661d6sm17991895wrr.82.2023.03.24.18.51.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 24 Mar 2023 18:51:50 -0700 (PDT) Content-Language: en-US In-Reply-To: <8FC25A01-6934-43BB-899C-CA5926BEA3CF@gmail.com> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:258537 Archived-At: On 24/03/2023 09:34, Yuan Fu wrote: > Well, this is a bit embarrassing, there is even a comment warning this mistake, but anyway, I pushed a fix, once it gets merged into master, the problem should go away. Excellent, thanks. > As things stands right now, every time blink-match-open blinks the matching parenthesis, tree-sitter would reparse the buffer twice, that’s not exactly ideal. Blink-match-open’s use of narrowing is legit, and we can’t just automatically widen in tree-sitter functions. Not ideal indeed. Aside from the performance impact, we could also see cases where the "narrowed" parse tree contains errors (due to incomplete code) which make the tree itself less useful. Especially when the narrowing's end is closer to the current position than in blink-matching-open's usage. Not sure how to solve that, but suppose we had a way to convey to treesit.c that it shouldn't change the visibility bounds for the parser in this particular instance? Though that would raise the issue of code trying to use node positions beyond the current accessible range.