bug#66732: tree-sitter fontification doesn't update multi-line syntax reliably

[Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

> The problem is, when you type /* RET foo RET */ the block comment is not fontified in comment face
>
> x
>
>
>
> That’s because before the user types the final “/“, there isn’t a complete
> comment node in the parse tree. When the user types the “/“, we need to mark
> the whole block comment for refontification.
>
> We actually have that, when the parser reparses, it’ll also compute the
> affected region, the region that changed during the last reparse, and it’ll
> call the “notifiers” with that region. We install a font-lock-notifier,
> which simply sets fontified text property to nil in that region, so
> redisplay would call jit-lock to fontify that region.
>
> In our example, the region would be the block comment.

Thanks.

If the reparse is done during `jit-lock` then, depending on how we do
it, it may indeed require re-running jit-lock, tho not necessarily.
E.g. if the reparse+notification is used to extend-region, then
fontification will already have been done and doesn't need to
be repeated.
OTOH the rendering will have already been done with the pre-reparse
state of the buffer for the beginning of the buffer (i.e. before the
"*/"), so we need to re-render (i.e. re-run the redisplay) for that part
of the buffer.  But that should not need any re-parse nor re-fontification.

If your `font-lock-extend-region-function` returns correct bounds,
jit-lock should take care of re-rendering as needed.

If the reparse (and the corresponding setting of `fontified`) is done
before redisplay, then there should be no need to do any double work at
all.  So maybe reparsing from a `pre-redisplay-functions` is an even
better option.  The downside is that it doesn't save you from needing to
handle reparses from the `font-lock-extend-region-function`, in order to
handle the cases where the redisplay wasn't involved.


        Stefan