[BUG] Copying a rectangular selection and pasting into another rectangular selection that contains half as many lines, or fewer, produces unexpected results.

[Coises]

Is there an existing issue for this?

• I have searched the existing issues

Description of the Issue

Copying a rectangular selection then pasting into another rectangular selection behaves unexpectedly if the number of lines in the source is greater than or equal to twice the number of lines in the target.

The result copies multiple lines, including line ending characters, into each line of the target space, destroying any column layout that was present. (If a user is pasting a rectangular selection into another rectangular selection, it is likely that a column layout is present.) Also, the carets are strange: one caret is shown after each pasted section (making it look like it is a multi-selection); but if you switch to another tab and switch back, a rectangular selection is shown.

Steps To Reproduce

1. Copy this text into a new tab:

abc 123
def 456
ghi 789
jkl 321
mno 654
pqr 987
stu 024
vwx 135

ABC
DEF
GHI
JKL
MNO
PQR
STU
VWX

2. Make a rectangular selection around the first two characters of the eight lines with capital letters (AB|DE|GH|JK|MN|PQ|ST|VW)..
3. Copy to the clipboard.
4. Make a rectangular selection around the middle digits in the first four lines (2|5|8|2).
5. Paste.
6. Note the broken-up structure and note the four flashing cursors on lines 2, 4, 6 and 8.
7. Open a new tab.
8. Switch back to the original tab.
9. Note that there is now a rectangular selection from lines 2 to 7.

Current Behavior

The result of copying a rectangular selection and pasting it into another rectangular selection is unexpected (and, it appears to me, useless) when the number of lines in the target selection is less than or equal to half the number of lines in the source.

Expected Behavior

Pasting one rectangular selection into another should paste only as many lines as will fit, then stop. This happens when the number of lines in the target is more than half the number of lines in the source, but it shouldn’t change when it isn’t.

Debug Information

Notepad++ v8.6.7   (64-bit)
Build time : May 12 2024 - 20:04:00
Path : C:\Program Files\Notepad++\notepad++.exe
Command Line : 
Admin mode : OFF
Local Conf mode : OFF
Cloud Config : OFF
Periodic Backup : OFF
OS Name : Windows 10 Pro (64-bit)
OS Version : 22H2
OS Build : 19045.4291
Current ANSI codepage : 1252
Plugins : 
    mimeTools (3.1)
    NppConverter (4.6)
    NppExport (0.4)

Anything else?

This behavior exists in 8.6.1-8.6.7. Version 8.6 behaves differently (it always pastes everything that was copied; when the target is short, it just inserts into the following lines — not as desirable as the new behavior when the number of target lines is more than half the number of source lines).

Even when pasting into enough space, there is something strange with the carets. If, in the sample data, you select eight lines of numbers and paste the copied eight lines, everything looks right, with no selection and the carets at the right of the inserted data; but if you then switch to another tab and back, you see a column selection of the inserted data with the carets at the left.

[Coises]

The current behavior comes from calling pasteToMultiSelection here when pasting into rectangular selections as well as multiple selections.

Changing:

if (nbSelections > 1 && !isRO)

to

LRESULT selectionMode = _pEditView->execute(SCI_GETSELECTIONMODE);
if (nbSelections > 1 && !isRO && selectionMode != SC_SEL_RECTANGLE && selectionMode != SC_SEL_THIN)

would restore the old, Scintilla-defined behavior when pasting into rectangular selections (deletes the rectangular selection, pastes everything that was copied, and leaves a single cursor at the beginning of the inserted lines). That would at least be consistent — it doesn’t break the line structure, it doesn’t leave a “ghost” rectangular selection that appears when changing tabs away and back, and it is what people used to using rectangular selections would expect (since it always worked that way before 8.6.1).