bug#60650: 30.0.50; tree-sitter: parsing (and font locking) occasionally breaks during editing

[Mickey Petersen]

It is occasionally possible to put the tree-sitter parser, I am guessing, into 
an erroneous state w.r.t. the contents of the buffer it is charged with parsing.

This rarely presents itself, and when it does, it only seems to happen when 
text is deleted and inserted in short order (`delete-region' + `insert') from 
an elisp command.

The resulting erroneous state then breaks font locking, resulting in 
mis-fontified code.

I must note that the parse tree is _correct_ and not invalid. There is no easy 
way to 'fix' this bug, as newlines and other manual edits rarely fixes the 
issue. There is also no easy way to insist that tree-sitter must re-do 
everything. Presumably deleting and recreating the parser could work as a 
workaround? I do not know.

The only way to truly and accurately fix the issue is to save and re-open the 
file. This then forces a complete re-parse of the buffer and fontification, 
fixing the issue.

I have zero means of reliably of reproducing this, unfortunately: it is 
sporadic, intermittent, and happens somewhat infrequently.

So I'd love some ideas on how to go about debugging this.



In GNU Emacs 30.0.50 (build 6, x86_64-pc-linux-gnu, GTK+ Version
 3.24.20, cairo version 1.16.0) of 2023-01-02 built on mickey-work
Repository revision: c209802f7b3721a1b95113290934a23fee88f678
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12013000
System Description: Ubuntu 20.04.3 LTS

Configured using:
 'configure --with-native-compilation --with-json --with-mailutils
 --without-compress-install --with-imagemagick CC=gcc-10'