GNU bug report logs -
#56683
29.0.50; long lines fix doesn't work correctly when lines are truncated
Previous Next
Full log
Message #107 received at 56683 <at> debbugs.gnu.org (full text, mbox):
>
> 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.
This bug report was last modified 2 years and 326 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.