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

[Yuan Fu]

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