npp v8.6 reverses the order of lines on column copy/paste
-
@astewart77 said in npp v8.6 reverses the order of lines on column copy/paste:
@astewart77 said in npp v8.6 reverses the order of lines on column copy/paste:
I updated my main n++ to a master on github from two weeks ago, entitled
Fix visual glichy on multi-paste and make shortcut commands more coherentAfter I copied the .exe from that master to my portable dir, no plugins, default settings, the portable behaved as I have been seeing. The master still says 8.6 in the windows file properties, but the ordering of rectangular pasting is different from the 8.6 release.
More difference - with 8.6, after the paste there a single caret top left. With the change in the master commit, after the paste, there are zero width multi-carets on the right and status bar shows Sel : 3x0. A bug that was mentioned elsewhere - if you switch to another tab and back, the carets are on the left, full rectangular selection, status is Sel : 3x4.
-
@astewart77 said in npp v8.6 reverses the order of lines on column copy/paste:
More difference - with 8.6, after the paste there a single caret top left. With the change in the master commit, after the paste, there are zero width multi-carets on the right and status bar shows Sel : 3x0. A bug that was mentioned elsewhere - if you switch to another tab and back, the carets are on the left, full rectangular selection, status is Sel : 3x4.
Ugh. This sounds like paste into rectangular selection is, in the updated build, being treated as paste into multiple selection.
I haven’t (yet) managed to identify what changed to cause this, but I’d guess that either Notepad++ is processing paste differently, or it took over from letting Scintilla process it natively and isn’t duplicating Scintilla’s process accurately.
-
@astewart77 said in npp v8.6 reverses the order of lines on column copy/paste:
After I copied the .exe from that master to my portable dir, no plugins, default settings, the portable behaved as I have been seeing. The master still says 8.6 in the windows file properties, but the ordering of rectangular pasting is different from the 8.6 release.
I found out what happened.
In 8.6, your test does not show reversal. However, still in 8.6, if you do the same test except for using the Edit | Paste menu command instead of Ctrl+v, the text is pasted in reverse order.
In 8.6, Ctrl+v was associated with the Scintilla command SCI_PASTE. The menu command, however, is processed directly by Notepad++.
In the current master, Ctrl+x/c/v are mapped to the menu commands instead of the Scintilla commands. Menu cut and copy, as far as I can tell, do not behave differently than Scintilla cut and copy for rectangular selections in 8.6; it’s just menu paste.
The change happens in #0978b2e.
-
@Coises said in npp v8.6 reverses the order of lines on column copy/paste:
In the current master, Ctrl+x/c/v are mapped to the menu commands instead of the Scintilla commands.
So it’s a feature if you like having keyboard access to the menu paste method, but a bug if you don’t, because SCI_PASTE is no longer available for remapping back to Ctrl+v.
-
@astewart77 said in npp v8.6 reverses the order of lines on column copy/paste:
So it’s a feature if you like having keyboard access to the menu paste method, but a bug if you don’t, because SCI_PASTE is no longer available for remapping back to Ctrl+v.
Removing SCI_COPY, SCI_PASTE, etc. seems like it would create problems for people who already have macros that use those SCI codes. For example, this person’s macro uses 2178 which is SCI_COPY though in his case it’s also followed by 42002 IDM_EDIT_COPY
-
@mkupper said in npp v8.6 reverses the order of lines on column copy/paste:
@astewart77 said in npp v8.6 reverses the order of lines on column copy/paste:
So it’s a feature if you like having keyboard access to the menu paste method, but a bug if you don’t, because SCI_PASTE is no longer available for remapping back to Ctrl+v.
Removing SCI_COPY, SCI_PASTE, etc. seems like it would create problems for people who already have macros that use those SCI codes.
SCI_PASTE still exists. I meant it’s just no longer listed in the Shortcut Mapper for easy remapping. I made an NppExec macro with SCI_PASTE and mapped that to Ctrl+v. That works.
-
Is this going to get fixed now?
I am facing the same issue with 8.6.
It’s really annoying…
No plugins at all. -
@Theo-Pavloudis said in npp v8.6 reverses the order of lines on column copy/paste:
Is this going to get fixed now?
I am facing the same issue with 8.6.
It’s really annoying…It sure seems like you should try the latest version as of this writing (8.6.4).
-
@Theo-Pavloudis said in npp v8.6 reverses the order of lines on column copy/paste:
Is this going to get fixed now?
I am facing the same issue with 8.6.
It’s really annoying…
No plugins at all.It is fixed in v8.6.4 but you need to disable
Column Selection to Multi-Editingin the Preferences / Editing 2 tab. This setting, and the Enable Multi-Editing one in the same Preferences section were added as part of v8.6 and enabled by default. To restore the classic “normal” Notepad++ behavior people need to disable both settings. You only need to disable theColumn Selection to Multi-Editingpart if you are only interested in the order-of-lines issue reported in this forum thread.
-
@Alan-Kilborn @mkupper it’s still there in 8.6.8 either with Column Selection to Multi-Editing on or off.
First image is the original, second image is what happens when I paste it.
The order is reversed…
-
@Theo-Pavloudis said in npp v8.6 reverses the order of lines on column copy/paste:
@Alan-Kilborn @mkupper it’s still there in 8.6.8 either with Column Selection to Multi-Editing on or off.
This was fixed in 8.6.9 (item 13 in the announcement).
-
I am having the same problem. I tried with versions v8.8.3 and v8.7.7, can somebody else reproduce this?
-
@notdodgeball said in npp v8.6 reverses the order of lines on column copy/paste:
I am having the same problem. I tried with versions v8.8.3 and v8.7.7, can somebody else reproduce this?
Yes. However, it is not a bug, but a “feature.”
Column selections are expected to retain their physical order regardless of the direction in which they were selected. That’s what the earlier part of this thread concerned.
You made a zero-width column selection, but then (I think) you pressed Shift+End. That converted the column selection to a multiple selection. You can see that because the carets at the end of each line are not lined up. A column selection would be a rectangle that included the empty space at the end of shorter lines and had all the flashing carets lined up.
Multiple selections regard the order in which the selections were made. Even though you started as a column selection, the fact that you started at the bottom and extended to the top is “remembered” when you change it to a multiple selection. So the bottom line is “first,” and that’s how it’s pasted.
If you wanted to extend your zero-width column selection to the right, you would have had to use Alt+Shift+right arrow until you got it as wide as desired (or just make the original selection by doing a click at one corner and an Alt+Shift+click at the diagonally opposite corner).
-
Further to what @Coises said (regarding “(I think) you pressed Shift+End. That converted the column selection to a multiple selection”), turning off the Settings > Preferences > Editing 2 > ☐ Enable Column Selection to Multi-Editing would have prevented that switch from Column mode to Multi-Edit mode. That would have made it more obvious.
Even with that option enabled, there are ways to fix it:
- Like @Coises said, use
Alt+Shift+RightArrowto extend to the right - You could also use
Alt+Shift+Endinstead ofShift+End, which would extend the selection to the end of the active line’s width, but keep it a column (rectangle); you could then useAlt+Shift+RightArrowto finish extending it if the active line wasn’t the widest line.
Here’s a screen recording of me using the keyboard (even for the initial column selection) to do all that. Hopefully, you can follow along with my notes in the recording to understand it. (Recorded in v8.7.7, because I had gone back there to verify the option existed in the older version you listed.)
Unlike @Coises , I don’t consider it a “feature” (ie, a bug masquerading as a feature), I think it’s a reasonable compromise between all the different opinions on what the “right” behavior should be when mixing between column and multi-select mode.
- Like @Coises said, use
-
@PeterJones said in npp v8.6 reverses the order of lines on column copy/paste:
Unlike @Coises , I don’t consider it a “feature” (ie, a bug masquerading as a feature), I think it’s a reasonable compromise between all the different opinions on what the “right” behavior should be when mixing between column and multi-select mode.
I agree — perhaps the scare quotes were a bit excessive. For certain, it’s intended behavior; it was never a bug that was presented as a feature to avoid dealing with it.
I think that for users like me, who use rectangular selections frequently and multiple selections rarely, the improvements to multiple selection in the early 8.x releases felt like a degradation in user experience. Some of that has been mitigated by the Multi-Editing options (though, for example, turning off the ability to create multiple selections when you do want them is an unfortunate trade-off for not breaking normal drag-copy conventions… but if I recall correctly, that binary choice is baked into Scintilla, so it would be fragile at best for Notepad++ to attempt something different).
I imagine it appears exactly reversed to people who use multiple selections often and rarely want rectangular selections: they probably wish the distinction could be eliminated so they didn’t have to keep track of different behaviors when a rectangular selection hasn’t been changed to a multiple selection.
