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

Previous Next

Full log

Message #2001 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 21:36:03 +0000

>> 1. M-: (let ((large-file-warning-threshold nil)) (find-file "dictionary.json") (narrow-to-region 4000000 4004000)) RET
>> 2. C-x n w
>> 3. Kaboom!
>
> By "Kaboom!" you mean what? a crash?  Because it doesn't crash here. 
> This is a build from the latest emacs-29 branch.
>

I mean that Emacs is trapped in the long line problem again, don't you see 
it?

>
> This is all beyond argument.  We do want the heuristic.  I just want it 
> to be cheaper than it is now, especially for buffers without any long 
> lines, where each time we run this loop we waste CPU cycles.  So I'm 
> looking for ways of wasting less of them.
>

There are none, or at least none that I can see.  Your proposed heuristic 
to limit the scan to some portion of the buffer around point cannot work, 
precisely because the loop is not called during each redisplay cycle, but 
only from time to time.  See the example above.  Again, we cannot know 
what happened in the buffer between these two moments, which could be far 
away in time. We can either use a heuristic on the whole buffer, or not 
use a heuristic and scan only a portion of the buffer.  We cannot combine 
both, and use a heuristic on a portion of the buffer.  It would simply be 
too unsafe.

Previous Next

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