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

Previous Next

Package: emacs;

Reported by: Gregory Heytings <gregory <at> heytings.org>

Date: Thu, 21 Jul 2022 18:01:01 UTC

Severity: normal

Done: Gregory Heytings <gregory <at> heytings.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Gregory Heytings <gregory <at> heytings.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 56682 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: bug#56682: Fix the long lines font locking related slowdowns
Date: Sun, 31 Jul 2022 08:08:55 +0000
>
> How 'bout we do the reverse then: set the narrowing, but let-bind a 
> variable to indicate that we're inside a line-length-induced narrowing, 
> together with the previous narrowing bounds, so jit-lock or its clients 
> can undo the narrowing when needed?
>

That's not possible: the narrowing is (really) locked (with un uninterned 
symbol), it cannot be undone.  What would be possible would be to add an 
optional "unlock" argument to widen.  But somehow I don't think that would 
be TRT, as mode authors who now do a (widen) would simply take the habit 
to write (widen t) instead, and the same problems would surface again.

BTW, my tests show that syntax-ppss can be rather slow, when the file is 
large enough (say 1 GB).  I didn't look at what it does, but is it not 
possible to design a version of syntax-ppss that would approximate, with 
some heuristics, what syntax-ppss does, but on a smaller chunk of the 
buffer?  For example, I'd guess that '"' immediately followed by an 
alphanumeric character most likely starts a string, and '"' immediately 
preceded by an alphanumeric character most likely ends a string.




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.