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: Mon, 27 Mar 2023 01:00:20 +0300 Message-ID: <9886ffa5-ead2-50d5-a325-f6704b736ada@yandex.ru> References: <87fs9yur7r.fsf@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> <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> 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="1269"; 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 Mon Mar 27 00:01:21 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 1pgYQS-000AYs-Mb for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 27 Mar 2023 00:01:20 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pgYQD-0006MU-Gy; Sun, 26 Mar 2023 18:01: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 1pgYQB-0006MF-1Z for bug-gnu-emacs@gnu.org; Sun, 26 Mar 2023 18:01: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 1pgYQA-0003LB-Ic for bug-gnu-emacs@gnu.org; Sun, 26 Mar 2023 18:01:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pgYQA-0000Cs-2N for bug-gnu-emacs@gnu.org; Sun, 26 Mar 2023 18:01: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: Sun, 26 Mar 2023 22:01: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.1679868031742 (code B ref 62333); Sun, 26 Mar 2023 22:01:02 +0000 Original-Received: (at 62333) by debbugs.gnu.org; 26 Mar 2023 22:00:31 +0000 Original-Received: from localhost ([127.0.0.1]:46032 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pgYPe-0000Bt-Kc for submit@debbugs.gnu.org; Sun, 26 Mar 2023 18:00:31 -0400 Original-Received: from mail-wm1-f52.google.com ([209.85.128.52]:37561) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pgYPc-0000Bd-Du for 62333@debbugs.gnu.org; Sun, 26 Mar 2023 18:00:29 -0400 Original-Received: by mail-wm1-f52.google.com with SMTP id n10-20020a05600c4f8a00b003ee93d2c914so5851443wmq.2 for <62333@debbugs.gnu.org>; Sun, 26 Mar 2023 15:00:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679868022; 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=9Oi9j8eJL7/nD1QEy70M/3n7TIVb6pFgfsJ9GDVQ9ak=; b=LlDLMD+a0tjgfCa8xrgXfvfkaLYm26RVgITBLS1Jdtkx2HeoJeI/6EKJ7wZAJ8Okv7 bz/UHecz2CRDjdDjRtgA6Xbv5DjTPFGl12jSK8mPlECgPXNFjZ9msQBKh1EORX+A/nY6 2CX82yO7aUoZTPGtaYDfPPgr9/mQiDRjB5902uwGjNoPmMrwfzX6fKCKKo3TXOqYLSBh xVdArULkWfUSQR56dmxh/6gFM6L/wUz/wHLv8DIQ+FyqSN8TgBwjOXPB0OMX5H8Uo/IP jJwimkNhYHX/eIUa6k7egpoy39pejLbP//c2+tl9+L6AXo3PVQsQbOdNUEvUQ8memADO yyTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679868022; 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=9Oi9j8eJL7/nD1QEy70M/3n7TIVb6pFgfsJ9GDVQ9ak=; b=CZHmHlCkI/p0XNbgPsJ2KrCygHXMPGwxS5UGl8QskGFFN/KfNQEBglcA0B3cldiPyF f+jp85Cr/AXS9xyjvWv6e4imPU5ODK9wN7y0cWfTBup3ukn22/kckOZq3gqH+1EH3FXj AHG8AuoQg9ZT7eeTRyZWFZedO0+G5LftBbM2iTkUjHMT0kD51+jyh1+O428Bf1XFEDAk 5hXmgSiqPJN78JbfZHgDCwLJSa9HEdsD4xlMzlk1EeBa+r3Rrlt1BwvIHaJ8YSFoSixP siVIh/m9kCVdPzneu8Hvo/VXFFf5CM+UUgmMPX3jZHGGOO6G4hyaW/gqH7MdnM0ira2s g1xA== X-Gm-Message-State: AAQBX9eG/CzrtgJ9dGhzfNLVoN6tXQwhsGbIquUt3PLpp1oZ8kV3Nrbp awT1FqLTzeNR0dtT6kfLhVI= X-Google-Smtp-Source: AKy350YyUVW+cvzHHq3w4RyjVA8woulPKei7icSj/CC8WNtMfsjl/OBGgpPQFzy3DrdQFSQetjkP+A== X-Received: by 2002:a7b:ce84:0:b0:3ef:6fee:803a with SMTP id q4-20020a7bce84000000b003ef6fee803amr209742wmj.35.1679868022332; Sun, 26 Mar 2023 15:00:22 -0700 (PDT) Original-Received: from [192.168.0.2] ([85.132.229.92]) by smtp.googlemail.com with ESMTPSA id l18-20020a05600c4f1200b003ef67848a21sm4778400wmq.13.2023.03.26.15.00.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 26 Mar 2023 15:00:21 -0700 (PDT) Content-Language: en-US In-Reply-To: <83v8inal29.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:258701 Archived-At: On 26/03/2023 13:01, Eli Zaretskii wrote: >> Date: Sun, 26 Mar 2023 12:25:30 +0300 >> Cc: wkirschbaum@gmail.com, casouri@gmail.com, 62333@debbugs.gnu.org >> From: Dmitry Gutov >> >> On 26/03/2023 08:04, Eli Zaretskii wrote: >>>> Date: Sun, 26 Mar 2023 00:57:22 +0200 >>>> Cc: wkirschbaum@gmail.com, casouri@gmail.com, 62333@debbugs.gnu.org >>>> From: Dmitry Gutov >>>> >>>>> How does that work with features such as font-lock, which do widen? >>>> >>>> Using font-lock-dont-widen. >>> >>> That's only for font-lock. Parsing was not on the table when that was >>> introduced, so it doesn't have a similar mechanism. >> >> Parsing is on-demand, by font-lock and other features. > > So you are suggesting to introduce kludges like font-lock-dont-widen > in all of those places? font-lock-dont-widen is a kludge, but that's largely determined by the way it's defined and used. If we take indent-for-tab-command, for example, it doesn't have such a variable, and doesn't really need to: the top-level command calls 'widen', and then indent-line-function (set by major mode and altered by e.g. mmm-mode) is free to impose its specific bounds. I think, as far the immediate problem is concerned, blink-matching-paren could use the same route. And could even try to reuse show-paren-data-function instead of creating its own customization point. > I don't even see how we will find them all in > advance, let alone fix them or make sure they do what we want. Just do it step-by-step. The "grand unified theory of mixed major modes" has been attempted a few times in the past, and never reached anything practical. That's not to say nobody should try again, but they should keep that in mind. >>> 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. >>> As we all know, narrowing >>> is a problematic feature to use in Lisp programs, so maybe we should >>> do this better in the case of parsers. Then problems like this one >>> could be solved more cleanly and simply. >> >> Narrowing problematic to use in Lisp? > > Yes, because users can easily change narrowing. We've had problems > with that many times, and even some attempts at solving it, so why are > you pretending you don't know about those deficiencies? Because I suggested deprecating certain uses of it several times, and always got a "no" for an answer. >>>> And anyway, I like I mentioned, this will break this common pattern as well: >>>> >>>> (save-restriction >>>> (narrow-to-region ... some-limit-position) >>>> (forward-sexp)) >>>> >>>> I've used it in ruby-syntax-propertize-percent-literal, for example. >>>> Except with 'forward-list' rather than 'forward-sexp', but others can >>>> use the latter. >>> >>> You want to repeat all the arguments we already brought up? >> >> You might choose to ignore a third-party mode, but breaking a common >> pattern seems more dangerous. > > ??? How does that follow from what I said? > > Look, I'm trying to see how we could come up with an infrastructure > that will support multiple modes and other similar features in the > same buffer without relying on narrowing, thus bypassing the > disadvantages and difficulties that come with narrowing. I think we > have a good chance here to come up with such a solution, specifically > for features that us a parsing library. If you aren't interested in > discussing that, and think we should stick to narrowing, then this > goes nowhere, and I'd rather bow out of it. What I've seen here so far is you suggesting we go ahead and break the existing convention and then let "them" (third-party authors including myself) come up with a new working one. My stance here is we shouldn't break it before we create a new one. And I'm happy to discuss it, of course. Just please don't expect me to take the initiative at this point.