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#67977: 30.0.50; tree-sitter: Emacs crashes when accessing treesit-nodes in a narrowed buffer Date: Fri, 29 Dec 2023 14:48:32 +0200 Message-ID: <52f3f5c0-fc5a-46fa-949f-33437fd8878a@gutov.dev> References: <87r0jdddxf.fsf@yandex.ru> <835y0pfkgr.fsf@gnu.org> <1DE32BF7-75D8-4F49-975D-53C782D26016@gmail.com> <08D379EF-1556-4498-8E60-F7972A25752A@gmail.com> <83edfccbwi.fsf@gnu.org> <262157E9-A92C-4063-ADA4-725C156FB227@gmail.com> <83r0j79522.fsf@gnu.org> <83tto277s1.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14630"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: Eli Zaretskii , dvzubarev@yandex.ru, 67977@debbugs.gnu.org To: Yuan Fu Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Dec 29 13:49: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 1rJCIp-0003fW-S9 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 29 Dec 2023 13:49:28 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rJCIU-0008T4-ON; Fri, 29 Dec 2023 07:49:06 -0500 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 1rJCIR-0008S8-4p for bug-gnu-emacs@gnu.org; Fri, 29 Dec 2023 07:49:03 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rJCIQ-0008Po-Nw for bug-gnu-emacs@gnu.org; Fri, 29 Dec 2023 07:49:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rJCIQ-00059Y-JG for bug-gnu-emacs@gnu.org; Fri, 29 Dec 2023 07:49:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 29 Dec 2023 12:49:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 67977 X-GNU-PR-Package: emacs Original-Received: via spool by 67977-submit@debbugs.gnu.org id=B67977.170385412619765 (code B ref 67977); Fri, 29 Dec 2023 12:49:02 +0000 Original-Received: (at 67977) by debbugs.gnu.org; 29 Dec 2023 12:48:46 +0000 Original-Received: from localhost ([127.0.0.1]:40972 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rJCI9-00058h-Ab for submit@debbugs.gnu.org; Fri, 29 Dec 2023 07:48:45 -0500 Original-Received: from wout5-smtp.messagingengine.com ([64.147.123.21]:46815) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rJCI7-00057x-57 for 67977@debbugs.gnu.org; Fri, 29 Dec 2023 07:48:43 -0500 Original-Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 2352C3200A4B; Fri, 29 Dec 2023 07:48:37 -0500 (EST) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Fri, 29 Dec 2023 07:48:37 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1703854116; x=1703940516; bh=nqOeTrCnetvndXApxl3hl0FVFuG7y3GXuZn1yiH+7mM=; b= cKPAHWj95KxhhdRU69tNJvLE/8goY3AuLHcdtvnp7/eKsAwZzXwg+ZnA6/gTsyru aVduxGqk93M9fejSquYPn41A2qAD2kC7cZ/whq+vFLO7MpvzGMSPgGBIqzqKJ/fc GTz24IXCqI/yOKsw3gs1Q5sk8x1NY99T3UZ1xvMdAeq4IuAFNjWcb3sTzEMR1OGl TGIgrYGFkt7QJI1H2kAV/JWvjy9DwpWXByP8WiiX2gAeqX5JhrfvcEonhYUAq+O6 pA2CVSvQeKkPwZ/XkUrG6/GexXA+0FYXwskt4hrjzlSkJgeSgBzfMjJ36rpa0I34 WEHd+msUsEEv0vbQ315ewg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1703854116; x= 1703940516; bh=nqOeTrCnetvndXApxl3hl0FVFuG7y3GXuZn1yiH+7mM=; b=1 4DJWJhomlA+2MTCsaufC6evOuaDdEc2hr0cHwguTxYzxzsPIBYHhaxYi0nuCDOoX +ctTIFtTs1w2PgfTauRzYBOqQ+eT1U5G6APiqN5Vf2IlSYsygMDijgZLslZXt7fx w959E09s5+PCPR6IPBMdkn1DqfBz2sQkB1O/GIeyJZ6/mlDWaXrDA/MJZSem1cxq l62PK2vV/GzvAUHHMXR1t8e2cUvQX1fZ2YYsEDcNcgERYA+vuBllMwKJmHR7nHF9 pEXP05czRvY9U3j4PC70sry8Sa97CbfKWols63kaJKfrC5HfrLlTUjkq3+TcI23c eYg9X397tVbDGzvfV7m6A== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdeffedggeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtvdejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepgeelfeetkefghfdvhfdtgeevveevteetgeetveegtedthefhudekteehffeu keeknecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 29 Dec 2023 07:48:34 -0500 (EST) Content-Language: en-US In-Reply-To: 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:277013 Archived-At: On 29/12/2023 09:00, Yuan Fu wrote: > > >> On Dec 28, 2023, at 8:16 AM, Dmitry Gutov wrote: >> >> On 28/12/2023 15:53, Eli Zaretskii wrote: >>>> Date: Thu, 28 Dec 2023 13:44:43 +0200 >>>> Cc: Denis Zubarev,67977@debbugs.gnu.org >>>> From: Dmitry Gutov >>>> >>>>>> Could font-lock-dont-widen help, perhaps? >>>>> Yes. If font-lock doesn’t widen, then there wouldn’t be back-and-forth reparses. >>>> But then treesit major modes will be affected by user narrowing (e.g. if >>>> the user narrowed to inside the string, the buffer won't be highlighted >>>> as a string). >>> Why is that a problem? When the user narrows the buffer, the part >>> outside the narrowing doesn't exist as far as Emacs is concerned. >> >> That's not how it works in most major modes, at least since the introduction of font-lock-dont-widen 20 years ago. >> >> Like its docstring says, the exceptions were supposed to be weird modes like RMAIL and Info which use narrowing for their own purposes (that seems buggy in Info's case, when 'C-x n w' breaks the intended display right away). But even Info-mode doesn't actually change font-lock-dont-widen, actually, because the apparent behavior would be the same. But it could. >> >> I don't have a personal stake in this (I never use narrowing interactively). But maybe you'll want to make a poll, to ask the users that do. > > I guess that depends on how you view narrowing, I assume most of the time the user considers narrowing to be something that narrows the view to a region, rather than effectively removing the rest of the buffer. IIRC We’ve had discussions on adding “types” to narrows but to no conclusion. Indeed. > Anyway, if the reparse caused by narrowing prove to be problematic, I can implement the optimization I mentioned earlier, where we use two parsers, one for when buffer is widened and one for when buffer is narrowed. This will be in C and is transparent to lisp. This definitely can work, but perhaps we should examine concrete use cases first. It could be that the caller would want the full parse tree available anyway, when the view was narrowed interactively by the user. Then the actual advice from us would be to (save-restriction (widen ...)) anyway, and the second parse tree would stay mostly unused. It's a good thing to have fixed the crash, though, so the developers can try it both ways and decide what's best for them.