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

24.12.2023, 06:01, "Yuan Fu" <casouri@gmail.com>:

On Dec 23, 2023, at 12:08 AM, Yuan Fu <casouri@gmail.com> wrote:

On Dec 22, 2023, at 11:26 PM, Eli Zaretskii <eliz@gnu.org> wrote:

From: Denis Zubarev <dvzubarev@yandex.ru>
Date: Sat, 23 Dec 2023 02:18:20 +0300

1. emacs -Q
2. M-x find-file /tmp/t.py
3. paste there
start=1
def _init(self, param1, param2, param3=False):
   self._param1 = param2
   self._param2 = param2
   self._param3 = param3
4. python-ts-mode
5. select two last lines and M-x narrow-to-region
6. answer all prompts
7. Put cursor on the last self
8. M-x eval-expression
(progn
(setq temp-node (treesit-node-at (point)))
(sit-for 2)
(garbage-collect)
(message "node %s" temp-node))
9. Emacs crashes or prints node that contains garbage

Thanks.

Yuan, this also happens on the emacs-29 branch, so we should try
fixing this crash ASAP.

Yeah. The node wants to print it’s type name (with ts_node_type), which access it’s parse tree, but the tree is already freed, that means the node is outdated and shouldn’t try to print it’s type name, but should rather print “outdated”.

But simply narrowing the buffer shouldn’t reparse the buffer and cause the parse tree to be freed. Anyway, let me see what’s going on.

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?

Yuan