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:33:38 +0300 Message-ID: <10aa98b6-908b-c467-7c77-767906692088@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> <83fs9q9vak.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="19575"; 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 Tue Mar 28 01:34:28 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 1pgwM8-0004l2-1T for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 28 Mar 2023 01:34:28 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pgwLl-0001nL-9K; Mon, 27 Mar 2023 19:34: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 1pgwLj-0001mr-OA for bug-gnu-emacs@gnu.org; Mon, 27 Mar 2023 19:34: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 1pgwLj-0008U5-7C for bug-gnu-emacs@gnu.org; Mon, 27 Mar 2023 19:34:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pgwLi-0006tW-Ag for bug-gnu-emacs@gnu.org; Mon, 27 Mar 2023 19:34: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: Mon, 27 Mar 2023 23:34: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.167996002726472 (code B ref 62333); Mon, 27 Mar 2023 23:34:02 +0000 Original-Received: (at 62333) by debbugs.gnu.org; 27 Mar 2023 23:33:47 +0000 Original-Received: from localhost ([127.0.0.1]:48585 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pgwLS-0006ss-Ka for submit@debbugs.gnu.org; Mon, 27 Mar 2023 19:33:47 -0400 Original-Received: from mail-wm1-f43.google.com ([209.85.128.43]:39524) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pgwLR-0006sg-Ep for 62333@debbugs.gnu.org; Mon, 27 Mar 2023 19:33:46 -0400 Original-Received: by mail-wm1-f43.google.com with SMTP id i5-20020a05600c354500b003edd24054e0so8326983wmq.4 for <62333@debbugs.gnu.org>; Mon, 27 Mar 2023 16:33:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679960019; 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=9OOPw4XXgx4I2Wbzj7ytcO0jpIVLhxgA/ww6NjOrLkg=; b=osxLjyWKmnOqTseVn9h0HvlpLji7s7R2a/D61syLaZQht59EHD1WAo6UMcx6K9UMjH Fyu2snQsQnmdhElLrdT8a5WX3XPZExuvCKYiHj2km+cqU8yO+W0p/FbjeHJ7v/GieZn+ pcF5oe/X5NzEyrxZhfTbubHHhpQMw+LWYjH64w9Pnm/jk8wepjKi4Jldcybjw3Aqrhow zb9QzcMRfHfVBqU4OU6OyxI75iu/vnTM2WsLugboUDHOPXupdBSAWMugjqBDNm5QCYUj RDtBjettfXsNlw+PSGSX0FhXMw0nRaonGrWr4IgOZtFQkQndJn7VUXZLgH29B8jdtJBc /ZdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679960019; 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=9OOPw4XXgx4I2Wbzj7ytcO0jpIVLhxgA/ww6NjOrLkg=; b=yvEMkoNF+XSdxFnFyJHQCe17gurCSioUnAeoV9Dyn75Gl+nHz1Uo3OR7JLHrbSGuBO nZBxHWIM44FvNqD9AKKRljbk8JlpS5KAPAHARkaLkieKEWIyGQZIeobAGZSCkIunB6Z8 JF0t0r+cKDHi14tRQig+q6oX1P02/ZVUWpjDlpZFheVu75ajH1ZrsTC8lDbwo9DH/DVp L1C931Ao2IxylV/Csp4SyWje2G8dY+lBeLXKZEupZa0OhXV9PtnE+T+25OXGoRt4qlBr 8agSY9scPDzo8206visg+VrQIJQx4CAhFV0FIciZTSgKsxJRvLXUlr9O0DAoi4GyBUjr dUxw== X-Gm-Message-State: AO0yUKWGQ7SdX00/UMxWfxJ3BWk9YN49/5USWFsUuTh+IwlxTwyjf5yP l0KlshKOvUw/k24hois35sM5YmFV7lk= X-Google-Smtp-Source: AK7set+lhUX1zHcnEv8dCb9miI5zloP3sLo8yWpXKBT2+x9pW4mJpeJ7NbK6YtBJvOtog7UZubodXA== X-Received: by 2002:a05:600c:2909:b0:3eb:383c:1870 with SMTP id i9-20020a05600c290900b003eb383c1870mr10942815wmd.11.1679960019474; Mon, 27 Mar 2023 16:33:39 -0700 (PDT) Original-Received: from [192.168.1.2] ([31.216.80.60]) by smtp.googlemail.com with ESMTPSA id z4-20020a05600c0a0400b003ef4cd057f5sm10423062wmp.4.2023.03.27.16.33.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 27 Mar 2023 16:33:39 -0700 (PDT) Content-Language: en-US In-Reply-To: <83fs9q9vak.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:258775 Archived-At: On 27/03/2023 16:29, Eli Zaretskii wrote: >> Date: Mon, 27 Mar 2023 01:00:20 +0300 >> Cc: wkirschbaum@gmail.com, casouri@gmail.com, 62333@debbugs.gnu.org >> From: Dmitry Gutov >> >>> 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. > > With parser-based features, we have an opportunity to do this in a > cleaner manner. parser-based features don't need this at all, if considered in isolation. But if we try to combine them with existing mode, or existing packages, they need to play by the common rules. Which they currently do. >> 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 thought about a lower-level, infrastructure-level, mechanism that > could be used to restrict a parser to a certain region of the buffer. > Then this could be used by every feature based on parsers, instead of > us having to invent a separate solution for each one. 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? >> 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. >>>> 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. > > Which is why restricting parsers should not be a user-level feature. We're talking elisp-level, though. The problem with interactive narrowing, is its impossible to tell apart from one effected by Lisp. And they usually have different goals. >>> 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. > > You are mixing two semi-separate issues: how to fix the immediate > problem with blink-matching-paren (if we consider it a serious > problem), and how to try solving similar issues as a whole. Not mixing anything. We have one proposal for improving blink-matching-paren integration anyway. It should be compatible with whatever we choose regarding narrowing and mixed modes. > The > latter is a long-term goal, and we can discuss it freely and calmly; > whereby ideas can be brought up even if they might not be the most > clever ones or the ones with which you personally agree. I'm not looking for "clever". >> 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.