bug#59630: 29.0.50; treesitter-buffer-root-node doesn't change when changing buffer restriction

[Eli Zaretskii <eliz@gnu.org>]

> From: Yuan Fu <casouri@gmail.com>
> Date: Sun, 27 Nov 2022 14:40:41 -0800
> Cc: 59630@debbugs.gnu.org,
>  Eli Zaretskii <eliz@gnu.org>
> 
> >  ELISP> (widen)
> >  ELISP> (treesit-buffer-root-node 'bash)
> >  #<treesit-node
> >  (program)
> >  in 1-4>  ;; <---- This is not expected, the root node should span 1-9
> > 
> >  ELISP> (buffer-string)
> >  "echo '123'"
> 
> Thanks. We didn’t edit the buffer after widening, so tree-sitter didn’t reparse and used the old tree, which sees the narrowed buffer. Eli, what would be a good and reliable way to know that narrowing has changed? I see current_buffer->clip_changed set to 1 in narrow-to-region and widen, but when are they set to 0?

Not sure what exactly are you after.  If you want to catch the moment when
we change the buffer restriction, you will have to add something to
Fnarrow_to_region and Fwiden.  However, why does tree-sitter need to know
about changes in the narrowing, unless it is asked to update something or
produce a tree?  I thought we decided to update this stuff lazily, only when
actually needed?  Being sensitive to these changes would require you to have
some logic, because a buffer can be narrowed and widened several times in a
sequence without any consequences for tree-sitter, and asking the parser to
update itself will just burn CPU cycles.  So if this is really needed, let's
discuss for which purposes and under what conditions.

I actually don't think why we should be worried by the above scenario; can
you explain?

To answer your question: the clip_changed flag is reset in
reconsider_clip_changes, which is called at the beginning of redisplay, and
when a window's redisplay is successfully completed (see
mark_window_display_accurate_1).  However, this flag is not meaningful
outside of redisplay, in particular when redisplay cycle is NOT running.  So
I'm not sure it is what you want.