GNU bug report logs - #67977
30.0.50; tree-sitter: Emacs crashes when accessing treesit-nodes in a narrowed buffer

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: casouri <at> gmail.com, dvzubarev <at> yandex.ru, 67977 <at> debbugs.gnu.org
Subject: bug#67977: 30.0.50; tree-sitter: Emacs crashes when accessing treesit-nodes in a narrowed buffer
Date: Thu, 28 Dec 2023 18:16:30 +0200

On 28/12/2023 15:53, Eli Zaretskii wrote:
>> Date: Thu, 28 Dec 2023 13:44:43 +0200
>> Cc: Denis Zubarev<dvzubarev <at> yandex.ru>,67977 <at> debbugs.gnu.org
>> From: Dmitry Gutov<dmitry <at> gutov.dev>
>>
>>>> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.