Pasting a block selection has different performance depending on the paste postion.
This isn't an issue for smaller blocks. In the attached gif you can see the delays.
I copied a block of 26 x 254 and pasted it into another document a different column positions.
This is the same on Windows 10 and Debian.

When performing a rectangular paste, the code finds where on each pasting line the paste goes based on the x position of the initial caret. If there is no position on the line for that x then spaces are added, one by one, until there is a position to place the text. After each space is added, the line has changed so its layout has to be fully recalculated which becomes progressively heavier as there are more characters on the line to measure. To some extent, this is O(n ^ 2).
An approximation of the number of spaces needed could be tried but there is a potential to overshoot in some circumstances. More than 1 space could be added at a time.
I tried Neil's suggested approach: add more than one space at a time, but conservatively.
The patch only changes end-of-line padding in rectangular paste. If the target x position is beyond the line end, it estimates the missing spaces from the current style's space width, inserts slightly fewer spaces than estimated, measures again, and then lets the existing one-space loop finish exactly.
This should avoid overshoot because the final alignment still uses the existing XFromPosition loop.
The maximum single batch size is limited to 8192 spaces. Larger gaps are handled by multiple batches.
This also fixes cases where pasting a large rectangular UTF-8 block at the end of a long mixed Japanese text line made the UI unresponsive for a very long time.
Paste text handling and CR/LF handling are unchanged. I also tested the patch with different code pages and compared the resulting document content against the previous version. The results were identical.
Last edit: RealMalWare 2 days ago