When narrowing changes, parse reparses, so the timestamp should
definitely increment, just like in ts_record_changes.
Failing to increment this timestamp, outdated nodes would think they
are still up-to-date, and try to print their type name. Printing
their type name involves accessing the old parse tree, which is
already freed during the last reparse.
I also found that we don't increment timestamp when changing parser
ranges and fixed that as well.
* src/treesit.c (treesit_sync_visible_region):
(Ftreesit_parser_set_included_ranges): Increment timestamp.
* src/treesit.h (Lisp_TS_Parser): Add some comments.
this function is called), we need to reparse. */
if (visible_beg != BUF_BEGV_BYTE (buffer)
|| visible_end != BUF_ZV_BYTE (buffer))
- XTS_PARSER (parser)->need_reparse = true;
+ {
+ XTS_PARSER (parser)->need_reparse = true;
+ XTS_PARSER (parser)->timestamp++;
+ }
/* Before we parse or set ranges, catch up with the narrowing
situation. We change visible_beg and visible_end to match
ranges);
XTS_PARSER (parser)->need_reparse = true;
+ XTS_PARSER (parser)->timestamp++;
return Qnil;
}
/* Re-parsing an unchanged buffer is not free for tree-sitter, so we
only make it re-parse when need_reparse == true. That usually
means some change is made in the buffer. But others could set
- this field to true to force tree-sitter to re-parse. */
+ this field to true to force tree-sitter to re-parse. When you
+ set this to true, you should _always_ also increment
+ timestamp. */
bool need_reparse;
/* These two positions record the buffer byte position (1-based) of
the "visible region" that tree-sitter sees. Before re-parse, we