GNU bug report logs - #56683
29.0.50; long lines fix doesn't work correctly when lines are truncated

Previous Next

Full log

View this message in rfc822 format

From: Gregory Heytings <gregory <at> heytings.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gerd.moellmann <at> gmail.com, andreyorst <at> gmail.com, 56683 <at> debbugs.gnu.org
Subject: bug#56683: 29.0.50; long lines fix doesn't work correctly when lines are truncated
Date: Tue, 26 Jul 2022 20:14:14 +0000

>
> My feeling is that we didn't yet exhaust the potential for speedups by 
> ways other than by turning off features.
>

My feeling is that we did, if we take the truncate-lines case out of the 
picture.  My feeling is also that adding more optimizations for the 
truncate-lines case is not worth the price.

>
> The font-lock effect is a good case in point: if we were to decide to 
> turn it off when there are long lines, we'd have missed the speedup you 
> just installed.
>

The difference is that I told you that I would look at that problem, and 
that now, after having spent many hours on this, I highly doubt it's 
possible to do better, especially given that no matter what we do to 
improve the truncate-lines case, we'll hit another ceil very soon (the 
DISP_INFINITY one, even if you decide to enlarge it).  It seems to me that 
the most reasonable thing to do is to simply tell users that Emacs has a 
limit in that case (and again, it has one, no matter what we do).

As far as I can see, the only way to really speedup the truncate-lines 
case would be to introduce an entirely new narrowing method, in which the 
buffer would be narrowed in a rectangular way.  That is, instead of 
narrowing a buffer between BEGV and ZV, each line 1, ..., n around point 
would be narrowed between BEGV1..ZV1, ..., BEGVn..ZVn.

>
> truncate-lines is an important feature (we just heard someone explaining 
> one such use case),
>

In that specific use case the lines do not hit the long-line-threshold 
limit.

Previous Next

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