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

Previous Next

Full log

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Eli Zaretskii <eliz <at> gnu.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 09:39:39 +0000

>> I don't think we can detect long lines reliably enough.  The problem of 
>> the original implementation is what Gerd mentioned: "What happens when 
>> evaluating an expression in *scratch* that returns a really large 
>> result?
>
> That problem doesn't exist when you run the detection code at the 
> beginning of redisplay (either in redisplay_window or in start_display 
> or in init_iterator), because by the time redisplay runs the buffer text 
> was already updated by the insertion that is the result of the 
> evaluation.
>

Wouldn't running such detection code at the beginning of each redisplay be 
too expensive?

>> Note that we the current implementation does not always restrict 
>> display code from seeing the entire buffer, it does so in a few 
>> well-chosen places, everywhere else the display code sees the entire 
>> buffer.
>
> And this is enough to make Emacs responsive?  If yes, that's great.
>

It is.  On master C-p at the end of dictionary.json loaded "literally" 
takes 27 seconds.  Now the effect is immediate.  On master inserting a 
character there takes several (about 5) seconds, now the effect is 
immediate.  On master you cannot even move to the end of 
hugedictionary.json (the 1 GB file) for example with C-e (or perhaps you 
can, but I gave up after a few minutes).  Now you can move there 
instantly, and the effect of commands there is immediate, too.

Previous Next

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