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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
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: Tue, 26 Jul 2022 20:29:05 +0300

> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: Gregory Heytings <gregory <at> heytings.org>,  56682 <at> debbugs.gnu.org,
>   monnier <at> iro.umontreal.ca
> Date: Tue, 26 Jul 2022 15:08:18 +0200
> 
> What about the following idea, in general.  Sorry if that is in the
> wrong sub-thread, I'm beginning to loose orientation a bit.
> 
> While iterating,
> 
> - remmember where we started, say it's 'start_pos'.
> 
> - when reaching start_pos + X, without reaching a line end, refuse to do
>   any complex stuff, no faces, invisible text and so on.
> 
> I could think of numerous variations of that theme.
> 
> I just loaded long-lines.xml in VSCode, and it seems to do something
> like that.  It says that "tokenization has been disabled" in the long
> line.  The long line doesn't have the highlighting that the shorter ones
> have, and VSCode also wraps the long line instead of truncating it.

We keep this possibility in mind all the time, you can see it in, for
example, the discussion whether to turn off line truncation.  But, as
I explained a minute ago, I think we haven't yet exhausted less
drastic measures, and there could still be opportunities for speedup
in the basic display code or thereabouts.  Our display is different
from that of VSCode, so the trade-offs are different as well.

Previous Next

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