GNU bug report logs - #56682
Fix the long lines font locking related slowdowns

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 56682 <at> debbugs.gnu.org, gregory <at> heytings.org, dgutov <at> yandex.ru
Subject: bug#56682: Fix the long lines font locking related slowdowns
Date: Wed, 03 Aug 2022 15:08:42 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: gregory <at> heytings.org,  dgutov <at> yandex.ru,  56682 <at> debbugs.gnu.org
> Date: Wed, 03 Aug 2022 04:37:55 -0400
> 
> >> > Indeed, that's my conclusion too.  So until syntax-ppss (at least) is made
> >> > an order of magnitude faster, the right thing to do is to use the forced
> >> > narrowing method.
> >> 
> >> By tying this to "long lines" is wrong, since it has nothing to do with
> >> long lines, only with large buffers.
> >
> > I thought you told me once that syntax-propertize needs to consider
> > complete lines in some (frequent) situations?
> 
> Yes, but we're talking about `syntax-ppss` here.  Admittedly,
> `syntax-ppss` uses `syntax-propertize` internally, but I think the two
> need to be considered separately (and `syntax-propertize` already tries
> to bound its work via `syntax-wholeline-max`).

What about parse-partial-sexp, which calls scan_sexps_forward?  It
looks like I've misremembered, and that was the culprit in the
scenario we discussed, see
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45898#92.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.