bug#56683: 29.0.50; long lines fix doesn't work correctly when lines are truncated

[Gregory Heytings]

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