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: Fri, 31 Mar 2023 04:17:19 +0300 Message-ID: <7228ade1-7686-a94a-0744-d77b7f09eb55@yandex.ru> References: <87fs9yur7r.fsf@gmail.com> <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> <83fs9q9vak.fsf@gnu.org> <10aa98b6-908b-c467-7c77-767906692088@yandex.ru> <83h6u585si.fsf@gnu.org> <5c683b3b-48e8-5099-8ab1-459c348d1f88@yandex.ru> <83jzyz7qmy.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30171"; 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, casouri@gmail.com, 62333@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Mar 31 03:18:17 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 1pi3PF-0007cj-5F for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 31 Mar 2023 03:18:17 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pi3P1-0000CK-FY; Thu, 30 Mar 2023 21:18:03 -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 1pi3P0-0000Bs-Pf for bug-gnu-emacs@gnu.org; Thu, 30 Mar 2023 21:18: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 1pi3P0-0001JI-H2 for bug-gnu-emacs@gnu.org; Thu, 30 Mar 2023 21:18:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pi3Oz-0002ue-UU for bug-gnu-emacs@gnu.org; Thu, 30 Mar 2023 21:18: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: Fri, 31 Mar 2023 01:18: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.168022544911152 (code B ref 62333); Fri, 31 Mar 2023 01:18:01 +0000 Original-Received: (at 62333) by debbugs.gnu.org; 31 Mar 2023 01:17:29 +0000 Original-Received: from localhost ([127.0.0.1]:59885 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pi3OS-0002to-VE for submit@debbugs.gnu.org; Thu, 30 Mar 2023 21:17:29 -0400 Original-Received: from mail-wm1-f49.google.com ([209.85.128.49]:41607) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pi3OR-0002tb-57 for 62333@debbugs.gnu.org; Thu, 30 Mar 2023 21:17:27 -0400 Original-Received: by mail-wm1-f49.google.com with SMTP id r19-20020a05600c459300b003eb3e2a5e7bso12935579wmo.0 for <62333@debbugs.gnu.org>; Thu, 30 Mar 2023 18:17:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1680225441; 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=AC3QnWyfoZENdSas2MGnguqmA8wWeXpW4vN+dDBP+t8=; b=SX8oTjZM9Em/dO//5N7ThsxesuI61pWqAYfYmnZZ/yG1Dj2arLVu9rOp686oZo1s04 9SW2G5QxUBOFEgpzBABilwudG2dcBs7dF77UCNRL9PeZMBhLyRiDpqWhQddoYZ303P9O /o+ZoePFznXT/8WV7FmreEkLZ1RxdGj7I2CeBr8WH+JSGRoWlNTJXAdnRO4Mi8+R2H6b XTA+c2ZHnSUEObo2IBy1m9miw2xybuXZd8FsQCEc/ZfoTIkT9Z16vOtxlr/fYUmBuF5Y ema4rvaxHjP+73nUboc3D+s9GF76XEOkeFH+NzYBR+xf/dM7aNxsj4d5b6niJMKaTRxG saMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680225441; 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=AC3QnWyfoZENdSas2MGnguqmA8wWeXpW4vN+dDBP+t8=; b=MUiUgUrSdS1z5lPK86zj4PAmcbm36qDtyDA9CU+TC3q23aoleGis7bnnT37dKF3Zc2 Da6Kqr77ZOusUmj97RHjEMVxB1E4hX2msa6ea6awjzrsglVFgslxvn57z+oBLkwbhZ1Z 4UXMUOPup8shkZ2Bk9aCrU5Ur/mveLXjD/ezKQc+Oz3i/eygY9pr14KjwsBGL0JDMZq1 NP8Zcn2oEGcg6Hj33bYe8VWiXyM9h0I4UT9uyQppADzWfAFe6c6WQBt+gSn+wsDxKLpn yu8rpIsX+d2AIH11xSHvbDgYkKaNNIDRk6TszSjQGV2vbjeoOTlMEIdGGeFAt5D4el9Q 9x5g== X-Gm-Message-State: AAQBX9dSKG5esCyf7ff4ZuLQdugFs079Pz6NnyMDGXmnM5IJdhLQoKws BEKp0T3nnz9I5D9FoinZ8b0= X-Google-Smtp-Source: AKy350a1vrQMmgK9x3QSaWQjUG7w/sQWhAweEy5+6XN8ewCHlmVdOyPH4pWGpw1Zia/IhmZFPuFyEg== X-Received: by 2002:a7b:ce84:0:b0:3ef:6fee:803a with SMTP id q4-20020a7bce84000000b003ef6fee803amr11045990wmj.35.1680225441326; Thu, 30 Mar 2023 18:17:21 -0700 (PDT) Original-Received: from [192.168.1.2] ([31.216.80.60]) by smtp.googlemail.com with ESMTPSA id l5-20020a5d5265000000b002e55cc69169sm745544wrc.38.2023.03.30.18.17.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 30 Mar 2023 18:17:20 -0700 (PDT) Content-Language: en-US In-Reply-To: <83jzyz7qmy.fsf@gnu.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:258955 Archived-At: On 29/03/2023 14:17, Eli Zaretskii wrote: >> Date: Wed, 29 Mar 2023 00:19:41 +0300 >> Cc: wkirschbaum@gmail.com, casouri@gmail.com, 62333@debbugs.gnu.org >> From: Dmitry Gutov >> >>>> Like narrowing, but just for parsers? But parsers obey narrowing >>>> already. Sounds a bit like conceptual duplication. How does this solve >>>> blink-matching-paren issue anyway? >>> >>> We could widen without fearing that a parser will "invade" regions of >>> buffer text that we don't want it to wander into. >> >> So any code that wants to restrict a "parser" based buffer, would need >> to use a different primitive to narrow? > > No, the idea is to create the parser with these restrictions to begin > with. > >> And vice versa, any code that uses a parser, will need to (widen) >> first, to ensure that the parser is not affected by any restriction >> set up by any code previously? > > No, if the parser is restricted, there should be no need to "widen" > it, at least not in most cases I could think about where a parser > should be restricted to a part of the buffer. > >> Anyway, I don't see why we should institute a special category for these >> buffers. > > Because IMO it's cleaner and simpler than using narrowing, and doesn't > suffer from the problems we see in narrowing. You are not describing anything that one couldn't do with a major mode before tree-sitter parsers (choose a region, apply font-lock keywords, etc), so that should give you an idea that the suggestion is probably not novel. And doesn't solve the existing problems in new ways. Why would we apply that approach to "proper" parsers only? >>>>>> The "grand unified theory of mixed major modes" has been attempted a few >>>>>> times in the past, and never reached anything practical. >>>>> >>>>> But here we have a unique opportunity to maybe find a solution, at >>>>> least for stuff based on tree-sitter and similar libraries. That >>>>> maybe not "grand", but certainly "respectable". >>>> >>>> tree-sitter has its own support for mixed languages. >>> >>> So your argument about mmm framework was a red herring, cause that >>> problem doesn't exist wrt tree-sitter parsers? >> >> Nope, see the first paragraph of my previous reply (the "no relevance" one). > > Which first paragraph is that? In what "previous reply" should I look > and where? (And why couldn't you simply copy that here, to make > following the discussion easier?) The reply you answered with "I don't see the relevance". There is really no good way to continue the explanation after that. Copying it into multiple successive emails doesn't sound logical either. >>>>>> My stance here is we shouldn't break it before we create a new one. >>>>> >>>>> No one broke anything. We are just discussing ideas. Please don't >>>>> exaggerate. >>>> >>>> I never said anybody has broken anything already. >>> >>> You did say that my ideas break something, see above. Ideas cannot >>> break any code, so this argument shouldn't be brought up if you want a >>> calm and rational discussion. >> >> Ideas cannot, but implementing them can. "This or that change will break >> an existing convention" is a rational argument. >> >> Shall we stop quibbling over words? > > I'm "quibbling" over words because your particular selection of words > makes serious discussion nigh impossible. Not the first time, either. > As soon as there's some disagreement, sooner or later those words > (like "quibbling") come out. Whether it's because of some attitude or > not, I don't know, but you may wish to reflect on that and perhaps try > to express your disagreements using different words. "Breaking a convention" is an industry term.