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: Tue, 28 Mar 2023 02:20:09 +0300 Message-ID: <683e0eb4-8f36-b8bd-ab0b-022845cafdac@yandex.ru> References: <87fs9yur7r.fsf@gmail.com> <491b788f-c3c3-4877-daa0-f515be9f3a17@yandex.ru> <83sfduelab.fsf@gnu.org> <8FC25A01-6934-43BB-899C-CA5926BEA3CF@gmail.com> <83jzz5c8ml.fsf@gnu.org> <83edpdc6sn.fsf@gnu.org> <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> 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="23055"; 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: wkirschbaum@gmail.com, Eli Zaretskii , casouri@gmail.com, 62333@debbugs.gnu.org To: Gregory Heytings Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Mar 28 01:21:20 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pgw9Q-0005gz-Bf for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 28 Mar 2023 01:21:20 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pgw9A-0004t6-Vx; Mon, 27 Mar 2023 19:21: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 1pgw99-0004s0-8k for bug-gnu-emacs@gnu.org; Mon, 27 Mar 2023 19:21:03 -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 1pgw98-0003DJ-JR for bug-gnu-emacs@gnu.org; Mon, 27 Mar 2023 19:21:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pgw97-0006X0-P1 for bug-gnu-emacs@gnu.org; Mon, 27 Mar 2023 19:21:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 27 Mar 2023 23:21: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.167995921925029 (code B ref 62333); Mon, 27 Mar 2023 23:21:01 +0000 Original-Received: (at 62333) by debbugs.gnu.org; 27 Mar 2023 23:20:19 +0000 Original-Received: from localhost ([127.0.0.1]:48580 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pgw8R-0006Vd-4g for submit@debbugs.gnu.org; Mon, 27 Mar 2023 19:20:19 -0400 Original-Received: from mail-wr1-f52.google.com ([209.85.221.52]:47071) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pgw8P-0006VR-HW for 62333@debbugs.gnu.org; Mon, 27 Mar 2023 19:20:17 -0400 Original-Received: by mail-wr1-f52.google.com with SMTP id r29so10345385wra.13 for <62333@debbugs.gnu.org>; Mon, 27 Mar 2023 16:20:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679959212; 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=GMq2XbV7Ze57sHLYjCHOpPvC/m2zrJ01ZrAOjxM4qsg=; b=FZhLq1ox8YsPzS0lbHnKSq8D8nOx484L/zPYvXKfQdp+ZtRXNZjGxlsdJgcSpgCo2S 3v3/IEYvTRJFemnQyv9DuRCZ/oTP1k8VuU/3bzKdsAhm05q+4gkesX/VuOz5ts9XiL35 G2QfDJmC1zM+Tygikg8E9Hr5nj0zOk963g0vgXyThgQ8p/H8cEKNxkBcxKTUKbxam0lZ HEeJMpZlV/BPPeU/Z6VxUKjcCWvjYuqcxlWzPr3tQ2/pJeVeuwc3RcCZCXQAVXQx52Dy OplkoV4mB4ZKOHwkJQfjgEl+1kUd3owEerlQuxEUR6KQ4V+f/SQ+Forf0FNOKDJeAJIt N5og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679959212; 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=GMq2XbV7Ze57sHLYjCHOpPvC/m2zrJ01ZrAOjxM4qsg=; b=HYk0BHLa9SeDNneH36R5/2t1KiyjQdgfZxLGM87ZVncYAP9e8kEOy2SaJO+27waXFZ jGGpKGbhQ3z4npNBPeaircizhvlLqYLAo8ptLbRHlU1i3NedRGfZJ27bFokQXPp3fv11 PoPb4h5HuikLe/aBwzpvTH1FzWqR2545HmFsJJrJhPrZnJ7ZNIxsyZFfD6BPzvsonwvV KWiowMr77t32VIsjlt9Y4EFhU3XfPn6nRXe/rOWaky+g+1W2njwK+egxLoMoXwR/3Ar1 kM52DC9Mp1+jWTxGnMb9/ph7F5Z7WI2pA2jmfX4xzQSLwJOU5QYE3VtzfnEcmx/tKpzR +BuQ== X-Gm-Message-State: AAQBX9fAYJpIv91Ym8CvOAItmwqoNo3gsuEwVGDii3Bk+UIfF1fLLyY1 P2YlHZdbcs6INfXBqgPzGgSmb6Q6Ywk= X-Google-Smtp-Source: AKy350ZI9/uRKBW3sAWY7uSbnljKM4AavYKHh3pECzCYpmhlyyQosrPtxyzdoAEtx/zivDlmBRH9Og== X-Received: by 2002:adf:f887:0:b0:2ce:a9e9:4905 with SMTP id u7-20020adff887000000b002cea9e94905mr11860378wrp.34.1679959211626; Mon, 27 Mar 2023 16:20:11 -0700 (PDT) Original-Received: from [192.168.1.2] ([31.216.80.60]) by smtp.googlemail.com with ESMTPSA id x2-20020a5d60c2000000b002cfe71153b4sm26091373wrt.60.2023.03.27.16.20.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 27 Mar 2023 16:20:11 -0700 (PDT) Content-Language: en-US In-Reply-To: <728618716b8c5349d27e@heytings.org> 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:258774 Archived-At: On 27/03/2023 11:24, Gregory Heytings wrote: > >>>>> Again, I'm talking about using a parser library.  We may need to >>>>> introduce a way of limiting the parser to a certain range of buffer >>>>> text positions, independently of narrowing. >>>> >>>> Except it's already limited by narrowing. >>> >>> Which is a fragile, semi-broken means, as we all know. >> >> What is a broken mess, is user-level narrowing. And how the downstream >> code can never guess the purpose the narrowing was applied for. >> > > Note that this is what labeled narrowings attempts to solve.  It's > perhaps not the best way to deal with code that has existed for a long > time (because such code is not prepared to handle that kind of narrowing > gracefully), but I don't see why it couldn't be used in new code/modes > such as tree-sitter ones.  It is independent of user-level narrowing, > and downstream code can act differently depending on the reason for > which the narrowing was applied. It indeed sounds like something we had considered before: different types of narrowing (at the time we only wanted to distinguish between two types: "soft" and "hard", the latter for use by mixed-mode features, or other stuff which wanted to preclude full widening, such as Info). But that fizzled out on the prototyping stage. (Aside: tree-sitter itself has its own support for "ranges", which will work without any narrowing related stuff as long as grammars for all langs are available -- or perhaps the combination should be available as a grammar too, I'm not sure -- anyway, it doesn't need much help, but it would still be nice to support embedding tree-sitter managed code inside "regular" modes, or have better support for mixing said regular modes, something we already do.) The new narrowing feature with labels kind of resembles that, except if I'm thinking about "intents", I could probably enumerate "visual" (for interactive narrowing), "hard" (for mixed-mode stuff or Info), or... "movement" (simply performed to constrain movement, but without goal to alter the parsing context -- such as narrowing before calling forward-sexp, in blink-matching-paren's example). These could be documented and assigned relative depth, sorting them like "hard > movement > visual", where code willing to undo "movement" would naturally undo "visual" as well, and code will to undo "hard" narrowing would undo them all. How treesit-forward-sexp would handle "movement" narrowing is something up for discussion, though: maybe just ignore it (given that there is no performance tax), or maybe it would still perform a position check at the end (after finding the matching paren), to see if it ends up beyond the accessible region.