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: Yuan Fu <casouri <at> gmail.com>, Denis Zubarev <dvzubarev <at> yandex.ru>
Cc: Eli Zaretskii <eliz <at> gnu.org>, "67977 <at> debbugs.gnu.org" <67977 <at> debbugs.gnu.org>
Subject: bug#67977: 30.0.50; tree-sitter: Emacs crashes when accessing treesit-nodes in a narrowed buffer
Date: Sun, 31 Dec 2023 02:08:38 +0200

On 30/12/2023 22:23, Yuan Fu wrote:
> 
>> On Dec 30, 2023, at 8:21 AM, Denis Zubarev<dvzubarev <at> yandex.ru>  wrote:
>>
>>> I pushed a fix and now it shouldn’t crash anymore. However, I’m yet not sure why at some point the buffer was widened. Is there any way to track who called widen?
>>   Thank you, It doesn't crash anymore.
>>   > So it seems working in a narrowed buffer would trigger a lot of back-and-fortch reparse. I wonder if it’s worth optimizing for (eg, use two parsers behind the scenes, one for widened buffer and one for narrowed buffer).
>>   I have performed a quite naive benchmark and haven't seen any significant slow down when inserting text in a narrowed buffer.
> Right, when you type, since the only thing that access the parser is font-lock, which always widens the buffer, there’s no unnecessary reparse. If you invoke some function that access the parser while the buffer is narrowed, that’ll trigger a reparse, and the next time font-lock runs, it’ll widen and make the parser reparse the full buffer again.

The difference might also only be noticeable with larger files: 
tree-sitter is pretty fast by itself, so an extra reparse might not make 
a difference unless it triggers a full re-fontification or application 
of text properties over a large span.

Previous Next

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