npp v8.6 reverses the order of lines on column copy/paste
-
@Coises 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:
What I see is the selection direction before copy doesn’t matter, but the selection direction of the target rectangular or thin selection does. Select up, copy, select down -> results are down. Select down, copy, select up -> results are up.
Are you sure both selections — the one at the time you copy, and the one at the time you paste — are rectangular selections and not multiple stream selections?
I think I’m sure :)
Starting with
abcd efgh ijkl qwer tyui opklI select the top block with Shift-Alt Down and Right arrows, Ctrl-c, select the bottom block upward with Shift-Alt Left and Up arrows. Status bar for both selections is Sel : 3x4 = 12
After Ctrl-V I have
abcd efgh ijkl ijkl efgh abcdI get the same result if the second selection is a zero width Sel : 3x0 at the left of the second block.
As far as thin selections, from the same starting set, I copy the first block, upward rectangular select the first letter of the second block and type x in to it.
abcd efgh ijkl xwer xyui xpklScintilla says this makes a thin selection,
but I think the new n++ code immediately converts it to a multi-selection, with the carets after the x, which shows as Sel 3 : 0 | 3, and the paste is in reverse order.abcd efgh ijkl xijklwer xefghyui xabcdpklI think the n++ code has some changes to auto switch from column to multi-edit for actions that don’t continue/extend a column selection.
SCI_GETSELECTIONMODE tells me the carets after the x were thin mode. -
@Coises said in npp v8.6 reverses the order of lines on column copy/paste:
I’m thinking, at least, since rectangular selections are always treated as top-down regardless of how they are made, if they must convert to empty multiple selections on arrow keys, at least the multiple selection should be top-down, regardless of how the rectangular selection was made. But I suspect those who use multiple selections more than rectangular selections will disagree.
As a multi-edit user, I rarely move a bunch of carets together with up or down arrows. Odd things happen at the end of lines/file. The appearance of vertically aligned carets as a unit is misleading. Better to create a new zero-width selection at the target location.
I have a hotkey to rotate the main selection through a set of multi-edit carets for review and I see that it also rotates line by line through a rectangular selection, with order depending on selection direction. So it seems that Scintilla simply converts a rectangular selection “line-by-line” to multi-edit carets, in the same order. The main selection is the “last” caret . In the OP, the main caret was the top most after the upward copy and still top most after the down arrows.
-
@astewart77 said in npp v8.6 reverses the order of lines on column copy/paste:
After Ctrl-V I have
abcd
efgh
ijklijkl
efgh
abcdAnd doing the same thing, I got:
abcd efgh ijkl abcd efgh ijklI removed all plugins, just in case that was the cause. Debug info:
Notepad++ v8.6 (64-bit) Build time : Nov 23 2023 - 16:58:44 Path : C:\Program Files\Notepad++\notepad++.exe Command Line : Admin mode : OFF Local Conf mode : OFF Cloud Config : OFF OS Name : Windows 10 Pro (64-bit) OS Version : 22H2 OS Build : 19045.3693 Current ANSI codepage : 1252 Plugins : noneI don’t have a guess as to why your results are different.
As far as thin selections, from the same starting set, I copy the first block, upward rectangular select the first letter of the second block and type x in to it.
If I do that and paste, I get:
abcd efgh ijkl xabcdwer xefghyui xijklpklIf, instead of typing an x, I press the right arrow key, then I get:
abcd efgh ijkl qijklwer tefghyui oabcdpklThe right arrow converts to an empty multiple stream selection — that’s intentional new behavior in 8.6 — and then the selection direction matters, because it preserves the selection order that was used to make the rectangular selection.
-
@Coises said in npp v8.6 reverses the order of lines on column copy/paste:
I removed all plugins, just in case that was the cause. Debug info:
Notepad++ v8.6 (64-bit) Build time : Nov 23 2023 - 16:58:44 Path : C:\Program Files\Notepad++\notepad++.exe Command Line : Admin mode : OFF Local Conf mode : OFF Cloud Config : OFF OS Name : Windows 10 Pro (64-bit) OS Version : 22H2 OS Build : 19045.3693 Current ANSI codepage : 1252 Plugins : noneI don’t have a guess as to why your results are different.
OK. I tried a portable minimalist n++ and I see what you see.
My usual plugin load is:
Notepad++ v8.6 (32-bit) Build time : Nov 29 2023 - 22:23:02 Path : C:\Program Files (x86)\Notepad++\notepad++.exe Command Line : Admin mode : ON Local Conf mode : OFF Cloud Config : OFF OS Name : Windows 7 Home Premium (64-bit) OS Build : 7601.0 Current ANSI codepage : 1252 Plugins : AnalysePlugin (1.14.54) ColumnsPlusPlus (1) DSpellCheck (1.5) ExtSettings (1.3.1) GotoLineCol (2.4.3) HTMLTag_unicode (1.4.1) JSMinNPP (1.2308) MarkdownViewerPlusPlus (0.8.2) mimeTools (2.9) NppConverter (4.5) NppEventExec (0.9) NppExec (0.8.7) NppExport (0.4) NppMenuSearch (0.9.6) NppToolBucket (1.10.6622.41336) NppUISpy (1.2) RandomValuesNppPlugin (0.2.1) SurroundSelection (1.4.1) _CustomizeToolbar (5.3)I’ll narrow it down, but I kinda like it the way it is.
-
@astewart77 said in npp v8.6 reverses the order of lines on column copy/paste:
@Coises said in npp v8.6 reverses the order of lines on column copy/paste:
I don’t have a guess as to why your results are different.
OK. I tried a portable minimalist n++ and I see what you see.
Well, not a plugin or a setting! The portable minimalist I used is an 8.6 release. I forgot that 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.
Whether this is an upcoming 8.6.1 bug or a feature is probably a personal pref.
-
@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).
