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

Previous Next

Full log

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 56682 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca, dgutov <at> yandex.ru
Subject: Re: bug#56682: locked narrowing
Date: Thu, 01 Dec 2022 22:23:38 +0000

>> I mean that Emacs is trapped in the long line problem again, don't you 
>> see it?
>
> No, not in particular.  Maybe you use a different file?
>

???  Did you try to edit the file after widening, or even just to move the 
cursor?  I'm using the same dictionary.json file we've been using.

>
> But anyway, what exactly does this prove, and how?  I asked why we need 
> to look beyond the narrowing, so how does the above answer that 
> question? what am I missing?
>

It proves that the long line detection loop must be executed on the whole 
buffer.  In this case there are no modifications to the buffer when it is 
widened, so the detection loop is not triggered, and because there was no 
long line in BEGV/ZV before widening Emacs did not activate the long line 
optimizations.

>
> I give up.  I will probably try to find time to code this myself, since 
> you don't even want to try.
>

Of course I'm willing to try.  But I already tried, I already explored the 
possibility you now consider, and concluded that it was not possible to do 
that.  I'm just trying to explain why and how I reached that conclusion. 
If you have other ideas, I'm all ears.

Previous Next

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