From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#62333: 30.0.50; Issue with tree-sitter syntax tree during certain changes Date: Sun, 26 Mar 2023 13:01:02 +0300 Message-ID: <83v8inal29.fsf@gnu.org> References: <87fs9yur7r.fsf@gmail.com> <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> <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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1104"; mail-complaints-to="usenet@ciao.gmane.io" Cc: wkirschbaum@gmail.com, casouri@gmail.com, 62333@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Mar 26 12:02:13 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 1pgNCW-000AYm-Tb for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 26 Mar 2023 12:02:13 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pgNCQ-0007AQ-CN; Sun, 26 Mar 2023 06:02: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 1pgNCN-0007AA-F3 for bug-gnu-emacs@gnu.org; Sun, 26 Mar 2023 06:02: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 1pgNCM-0007wH-MM for bug-gnu-emacs@gnu.org; Sun, 26 Mar 2023 06:02:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pgNCM-0000Yp-3Z for bug-gnu-emacs@gnu.org; Sun, 26 Mar 2023 06:02:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 26 Mar 2023 10:02: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.16798248722099 (code B ref 62333); Sun, 26 Mar 2023 10:02:02 +0000 Original-Received: (at 62333) by debbugs.gnu.org; 26 Mar 2023 10:01:12 +0000 Original-Received: from localhost ([127.0.0.1]:44099 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pgNBY-0000Xm-DK for submit@debbugs.gnu.org; Sun, 26 Mar 2023 06:01:12 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:58746) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pgNBX-0000XY-98 for 62333@debbugs.gnu.org; Sun, 26 Mar 2023 06:01:11 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pgNBQ-0007qr-Au; Sun, 26 Mar 2023 06:01:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=qleRDqit2tSuMJ7DLaKV8qIAAoyVl60tTtXEFkTYdPo=; b=boQjz6LXokej 213wc1RPuL6feHbDbjSokB/SJvpqh0HkEbTQeL/iRCHYJlGOpfrEs+5b6Ro5sy0iLgl+BcC/RY2Il HKDIV5Zcq6bE52ghBXl8uUaXnAXTJH+dE0k0xHWsXtO3uChkOJQx8l3fd+j7NHooYBZwj2KzvLckD cECBoxaQskA65VyPXUOQlB3wAMUhBSfCfhFIsJdBKVrnk2OWM50XGT++/chsJF//6220yVosjBQyz pPILnntRbHfAdQWgZ/NpSdhBx1Qn6sCyK9Gee0iO+TRqc0G7OVegH97dygTBUFI25bRuOeIsKWv1g 2B9422KMPfV7Wc793gRhRQ==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pgNBP-0006Se-QE; Sun, 26 Mar 2023 06:01:04 -0400 In-Reply-To: <29679184-7366-0167-9e94-def97048f663@yandex.ru> (message from Dmitry Gutov on Sun, 26 Mar 2023 12:25:30 +0300) 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:258666 Archived-At: > 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? 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. > > 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. > > 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? > >> 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.