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

Previous Next

Full log

Message #1492 received at 56682 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 56682 <at> debbugs.gnu.org, gregory <at> heytings.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#56682: Fix the long lines font locking related slowdowns
Date: Mon, 15 Aug 2022 14:51:22 +0300

> Date: Mon, 15 Aug 2022 13:06:14 +0300
> Cc: 56682 <at> debbugs.gnu.org, gregory <at> heytings.org, monnier <at> iro.umontreal.ca
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> 
> > And btw, I have very different impression of what happens with 100x
> > larger narrowing on my machine and with unoptimized builds.
> 
> Given what we've seen about your parse-partial-sexp's performance (10x 
> slower than mine), I would hope for someone to figure out why it's so 
> slow in your unoptimized build. But if it doesn't happen, you would 
> probably use a different threshold/narrowing radius (through customization).
> 
> It would make sense for our defaults not to be tailored to this very 
> particular development rig.

If you are willing to lose my ability to debug complex redisplay
problems in many cases, sure, go ahead.

> >> So yeah, the font-lock related widen/narrowing logic should indeed live
> >> in one place. And until now it has resided in font-lock-fontify-region.
> > 
> > Since when is font-lock-fontify-region specific to a language?  It is
> > as general as xdisp.c.
> 
> syntax-propertize is general, and yet it invokes language-specific rules 
> (through syntax-propertize-function).

Nothing prevents xdisp.c from invoking those same rules if needed.

Previous Next

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