GNU bug report logs -
#56682
Fix the long lines font locking related slowdowns
Previous Next
Full log
Message #985 received at 56682 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: gregory <at> heytings.org, dgutov <at> yandex.ru, 56682 <at> 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.
This bug report was last modified 2 years and 8 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.