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

Previous Next

Full log

Message #44 received at 67977 <at> debbugs.gnu.org (full text, mbox):

From: Yuan Fu <casouri <at> gmail.com>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Denis Zubarev <dvzubarev <at> yandex.ru>,
 67977 <at> debbugs.gnu.org
Subject: Re: bug#67977: 30.0.50; tree-sitter: Emacs crashes when accessing
 treesit-nodes in a narrowed buffer
Date: Fri, 29 Dec 2023 20:35:45 -0800

> On Dec 29, 2023, at 4:48 AM, Dmitry Gutov <dmitry <at> gutov.dev> wrote:
> 
> On 29/12/2023 09:00, Yuan Fu wrote:
>>> On Dec 28, 2023, at 8:16 AM, Dmitry Gutov <dmitry <at> gutov.dev> wrote:
>>> 
>>> 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.
>> 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.

I’m sure both strict and non-strict narrowing has their use-cases. For movement functions, we probably don’t want to widen; for indentation, I think both could be useful depending on, again, specific use-cases.

I don’t think any of use are motivated enough :-) We can wait until someone with a specific problem/requirement comes up.

> 
> 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.

Right, Lisp programmers can decide whether they want to widen. And if there are enough important use-cases for widening, we can starting thinking about optimizing switching back-and-forth between narrowed and widened buffer.

Yuan

Previous Next

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