bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#56393: Actually fix the long lines display bug


From: Eli Zaretskii
Subject: 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@heytings.org>
> cc: gerd.moellmann@gmail.com, larsi@gnus.org, 56393@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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]