bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#56682: Fix the long lines font locking related slowdowns


From: Eli Zaretskii
Subject: bug#56682: Fix the long lines font locking related slowdowns
Date: Fri, 05 Aug 2022 13:57:19 +0300

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: gregory@heytings.org,  dgutov@yandex.ru,  56682@debbugs.gnu.org
> Date: Fri, 05 Aug 2022 05:03:25 -0400
> 
> >> The use of `syntax-wholeline-max` in
> >> `font-lock-extend-region-wholelines` supposedly fixed this problem since
> >> it changed `font-lock` so it doesn't ask `syntax-ppss` to compute the
> >> whole line/buffer.
> >
> > It did?
> > And if it did, how is that better or different from a locked
> > narrowing?
> 
> In terms of end-user behavior, it's very similar: it can break the
> `font-lock-keywords` part of font-lock but it still lets `syntax-ppss`
> look at the whole buffer and will thus still provide correct recognition
> of strings and comments, except when the major mode relies on
> `syntax-propertize-function` since that one also obeys
> `syntax-wholeline-max` and can thus misbehave in a similar way to the
> narrowing.
> 
> The more important difference is that it can be
> tweaked/changed/broken/improved by any ELisp package without
> necessitating a recompilation of Emacs's C code, or ugly workarounds to
> escape the narrowing, like postponing the actual font-lock to a timer or
> some such.

AFAIK, the problem is not entirely solved by syntax-wholeline-max.  If
and when it is solved, we could revisit this issue.  However, since
syntactic fontifications are invoked by a major-mode's font-lock
setup, there's still a problem of how to prevent the rest of font-lock
from causing significant slowdown.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]