|
From: | Gregory Heytings |
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.
[Prev in Thread] | Current Thread | [Next in Thread] |