bug#60223: 29.0.60; Improve how tree-sitter changes to treesit--font-lock-fast-mode

[Yuan Fu <casouri@gmail.com>]

ronisbr <ronisbr@ronanarraes.com> writes:

> Hi!
>
> First of all, this is my very first interaction with Emacs mailing
> list. I have
> a problem in the tree-sitter module that leads to a bug (Emacs 29).
> Hence, I am
> not even sure if this is the right place to report it.
>
> treesit.el has a fast font-lock mode that is also used to avoid
> locking if some
> a query is taking too long:
>
>             ;; If for any query the query time is strangely long,
>             ;; switch to fast mode (see comments above).
>             (when (> (time-to-seconds (time-subtract end-time
>             start-time))
>                      0.01)
>               (setq-local treesit--font-lock-fast-mode t))
>
> When coding Julia major mode using tree-sitter
> (https://github.com/ronisbr/julia-ts-mode/blob/main/julia-ts-mode.el),
> I found a
> strange behavior in my setup (Doom Emacs) that is caused precisely by
> that
> feature.
>
> If I open this file together with Emacs (first initialization):
>
> https://github.com/ronisbr/PrettyTables.jl/blob/master/src/print.jl
>
> The file has almost no font decoration and
> `treesit--font-lock-fast-mode` is set
> to t. If I manually set it to nil and recompute everything, the font
> locking
> works perfectly again.
>
> However, everything works as expected if I open any other Julia code
> before
> opening that file (print.jl). In this case,
> `treesit--font-lock-fast-mode`
> remains nil.
>
> My guess is that due to something that might or might not be related
> to my
> setup, the query is taking longer than the 0.01s if I open that file
> during the
> initialization of Julia mode. It is caused by that enormous string
> used to
> document the function that seems to slow down tree-sitter parsing.
> Thus, I think
> it would be very important to have a variable to customize this time
> interval
> depending on the situation.
>
> Best regards,
> Ronan Arraes
>

Thanks for the report!

The "fast mode" should be buffer-local, so that particular file
shouldn’t affect other buffers. Just to make sure, you said that if you
open print.jl first, all other files are affected?

And I agree that the 0.01 second criterion is a crude one, but a long
string shouldn’t affect the _query_ time, and that string is not long at
all, far from enough to make tree-sitter query to slow down. Let me
investigate and see what’s the real cause, and if this can be solved by
better solutions than making the threshold customizable. We can’t expect
everyone to be able to pinpoint the culprit like you did :-)

Yuan