bug#72830: Big rectangular selections are slow

["Mattias Engdegård" <mattias.engdegard@gmail.com>]

27 aug. 2024 kl. 21.16 skrev Eli Zaretskii <eliz@gnu.org>:

>> It has to be done with the display code, but does not have to be as
>> part of redisplay.  We can use functions like vertical-motion,
>> window-text-pixel-size, posn-at-point, and other similar APIs, which
>> all employ display code that performs layout-related calculations
>> without actually displaying anything.
> 
> Btw, the horizontal dimensions of the window are known in advance even
> without calling the display code, and we could use posn-at-x-y to find
> the buffer position that corresponds to the right edge of the window.
> Isn't that what's needed to avoid highlighting the portions of text
> that are outside of the viewport?

Unfortunately I don't think that helps. The way it works now is that a pre-redisplay function puts a highlight overlay on every line in the rectangular selection. All this work and memory completely tanks performance.

Only putting overlays on lines where they can be seen would solve the problem, but we have to know the first and last line that will be displayed. I tried using `posn-at-x-y` but it doesn't seem to recompute `window-start` so it has the same problem.

27 aug. 2024 kl. 21.44 skrev Stefan Monnier <monnier@iro.umontreal.ca>:

> I rely on it on a regular basis, and I'm probably not the only one, so
> even if we disable it by default, we should make it work well enough for
> large rectangular regions.

Yes, that's probably true. Let's deal with that concern later; it's orthogonal to the redisplay problem.

> There might be some remaining issues with (re)running the
> `pre-redisplay-function(s)` when redisplay forces a change in
> `window-start` (or in the unlikely case where the highlighting moves the
> `window-end` further), but these are things we need to fix anyway.

That's what I wondered how to deal with. I agree we can probably assume that highlighting won't affect the viewport in any substantial way.

To be clear, just using the (inaccurate) window-start and window-end to clip the setting of highlight overlays works very well and with excellent speed until the viewport moves, in which case it no longer does.

> There are further issues when several windows display the buffer.

Are there? The highlight overlay is set with a `window` parameter that keeps it visible in one window only.

> We could also move some of the work to jit-lock, which would have the
> advantage that it would additionally be able to skip over (large) chunks
> that are marked as `invisible`.

Not sure how this would work. Isn't it guided by (comparatively persistent) `fontified` properties?