GNU bug report logs - #56393
Actually fix the long lines display bug

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: gerd.moellmann <at> gmail.com, larsi <at> gnus.org, 56393 <at> debbugs.gnu.org
Subject: Re: bug#56393: Actually fix the long lines display bug
Date: Sat, 09 Jul 2022 13:01:30 +0300

> Date: Sat, 09 Jul 2022 09:49:36 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: gerd.moellmann <at> gmail.com, larsi <at> gnus.org, 56393 <at> debbugs.gnu.org
> 
> > If this is enough, then it's great.  I'm just asking myself how come 
> > font-lock, for example, no longer slows things down as it did before? Do 
> > you understand why?
> >
> 
> Font lock does slow things down, see the NEWS entry.  But it also slows 
> things down on much smaller files (see the long-line-excerpt.xml file I 
> sent you).  As I said, to me the slowdown of font locking is a separate 
> problem, as is shown by the fact that turning it off removes the remaining 
> slowdowns in many/most cases.  There are in fact four separate problems 
> here:
> 
> 1. slowdowns caused by long lines,
> 
> 2. slowdowns caused by multibyte characters in long lines (which are not 
> solved by solving 1),
> 
> 3. slowdowns caused by font locking,
> 
> 4. slowdowns caused by major and minor modes (pre and post-command hooks 
> and the like).
> 
> This bug "only" solves 1 and 2.  And as I said, I can try to look at 3 if 
> you want, but not now.

I'm asking whether applying the "restriction" where we call
Vfontification_functions from the display engine won't also solve 3.

Previous Next

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