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: Fri, 31 Mar 2023 09:19:35 +0300 Message-ID: <83wn2x30js.fsf@gnu.org> References: <87fs9yur7r.fsf@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> <83bkke9uue.fsf@gnu.org> <83ilel861g.fsf@gnu.org> <290987e0-821e-a231-c1c4-b40bb9542ffe@yandex.ru> <83lejf7r2o.fsf@gnu.org> <1c4c8b47-e4aa-242a-bb66-1d6b5c879de4@yandex.ru> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31275"; mail-complaints-to="usenet@ciao.gmane.io" Cc: wkirschbaum@gmail.com, gregory@heytings.org, 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 Fri Mar 31 08:20:42 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 1pi87t-0007yH-U0 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 31 Mar 2023 08:20:42 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pi87T-0006cH-Gu; Fri, 31 Mar 2023 02:20:15 -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 1pi87H-0006YA-U9 for bug-gnu-emacs@gnu.org; Fri, 31 Mar 2023 02:20:04 -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 1pi87G-0001Hk-B0 for bug-gnu-emacs@gnu.org; Fri, 31 Mar 2023 02:20:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pi87G-0002OA-69 for bug-gnu-emacs@gnu.org; Fri, 31 Mar 2023 02:20: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: Fri, 31 Mar 2023 06:20: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.16802435719114 (code B ref 62333); Fri, 31 Mar 2023 06:20:02 +0000 Original-Received: (at 62333) by debbugs.gnu.org; 31 Mar 2023 06:19:31 +0000 Original-Received: from localhost ([127.0.0.1]:60173 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pi86k-0002Mw-LF for submit@debbugs.gnu.org; Fri, 31 Mar 2023 02:19:31 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:48058) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pi86i-0002Mf-GE for 62333@debbugs.gnu.org; Fri, 31 Mar 2023 02:19:28 -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 1pi86d-0001Al-5o; Fri, 31 Mar 2023 02:19:23 -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=1bvwOnAbdfNMsKx6uyVL6aW6jg8zTyQXpDlYiJbNM/Q=; b=Pc1B8lV7WdWV p1WDsl+9YYZt1/SlyCBXpWWlSf2ryI4wxhVd8Uce8vtIRlf3iYTL+LU0k02JnP+nR1L9ELw26de+I pamUVxyDDyU9BTV1NQKsIrgUENXlhwbELpoxge7whe54fXUJ9FgUgc4uqn+p9hMv/b5iicfwoWg2B fkxm26uTrvKejIha0snO5LgmgHRMnFYcO0ANUzlzy/qQP4ojX7qSE5GRTTwi4hzaarJ7olm46bp4K fsZkueFhdmniWtQkN9Hf4I3pUMoqSlSoN9XaMxc8jiTM4jqgmGCnBwmHbx9VyIgX6sjUo36Apor6n O3xK8vJt3nyE86mUcXxnlA==; 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 1pi86c-0005mz-8n; Fri, 31 Mar 2023 02:19:22 -0400 In-Reply-To: <1c4c8b47-e4aa-242a-bb66-1d6b5c879de4@yandex.ru> (message from Dmitry Gutov on Fri, 31 Mar 2023 04:10:54 +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:258968 Archived-At: > Date: Fri, 31 Mar 2023 04:10:54 +0300 > Cc: wkirschbaum@gmail.com, gregory@heytings.org, casouri@gmail.com, > 62333@debbugs.gnu.org > From: Dmitry Gutov > > On 29/03/2023 14:08, Eli Zaretskii wrote: > >> Date: Wed, 29 Mar 2023 00:08:53 +0300 > >> Cc: wkirschbaum@gmail.com, gregory@heytings.org, casouri@gmail.com, > >> 62333@debbugs.gnu.org > >> From: Dmitry Gutov > >> > >>>> Is that because we don't think the user level narrowing is done purely > >>>> for visual effect? > >>> > >>> Indeed, it isn't always for visual effect. > >> > >> When isn't it? Is there a way to determine that from code? > > > > I'm not sure I understand the question, but if I do, then narrowing to > > prevent search functions > > If we're talking about isearch, then that seems like a natural > consequence of visual effect (hiding the remainder of the buffer): even > if isearch highlighted those other hits, they would not be visible. If you consider narrowing in this example to be "for visual effect", then everything in Emacs is "for visual effect". After all, Emacs is a visual editor, showing the results of editing to the user at all times. But this POV makes this part of the discussion useless. > > I was talking about user commands that narrow, so I'm not sure I > > understand how documentation could help. When the user types "C-x n n", > > there's nothing Emacs can do except obey. > > There is really only one main user command that narrows, and that's > narrow-to-region, bound to 'C-x n n'. Any user command can narrow as part of its job. > Simple example: if the beginning of the narrowed region falls inside a > (let's say multine) string, should the visible remainder of that string > continue to be highlighted as a string? No. > Or should the buffer contents after the string's closer now be > highlighted as being inside a string? Yes.