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

Previous Next

Full log

Message #284 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 12:59:01 +0300

> Date: Sat, 09 Jul 2022 09:39:39 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: gerd.moellmann <at> gmail.com, larsi <at> gnus.org, 56393 <at> debbugs.gnu.org
> 
> 
> >> 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?

I don't think so.  find_newline1 is very fast, and if we call it once
for every window, it shouldn't be a problem.  Of course, only actually
trying that will tell if I'm right or am missing something.

And maybe this is not needed at all if restricting
find_newline_no_quit is enough to solve the problem.

> >> 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.

That's awesome, thanks.  I guess we will only need more measures if
some situations are reported where this is not fast enough, or causes
some other problems.

Previous Next

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