Npp v8.6 cursor oddity with copy paste into a 2x0 column

mkupper

This is also posted to github as Npp v8.6 cursor oddity with copy paste into a 2x0 column

I have two columns separated by tabs:

1111111111		AAAA
22222222222		BBBB
333333333333	CCCCCCCCCCC DDDD

I wanted to copy paste the CCCCCCCCCCCCC in front of the AAAA and BBBB to create

1111111111		CCCCCCCCCCC AAAA
22222222222		CCCCCCCCCCC BBBB
333333333333	CCCCCCCCCCC DDDD

Using the keyboard I selected the CCCCCCCCCCCCC (I included the space in the selection) on the 3… line
Ctrl-C to load the selected text into the copy/paste buffer
Left arrow which brought the text cursor back to the beginning of the CCCCCCCCCCCCC
Up-arrow once to move before BBBB
Shift+Alt+Up arrow to form a 2-row by 0 column selection/cursor that is now in front of both AAAA and BBBB
Ctrl-V to paste which creates CCCCCCCCCCC AAAA and CCCCCCCCCCC BBBB as desired and expected.

The v8.6 surprise and unexpected result is that the cursors moved backwards to column 2 of the 1… and 2… lines.

Also, while the cursors are on column 2 the status line says the cursors are on column 17. If I right arrow the cursors move to column 3 and the status line now says they are on column 3.

With v8.5.8 the cursors would be on column 17 just after the newly pasted CCCCCCCCCCC and which is also just before the AAAA and BBBB. This is what I’m used to and what I suspect most people expect.

Experimentation with v8.6 finds that the distance the cursor’s move backwards depends on the length of the CCCC... data I’m copying. If it’s a four character CCCC then the cursors move backwards four characters.

The 111... and 222... are slightly different lengths. Experimentation shows that changing these also changes the outcome but I did not experiment enough to detect the pattern.

While my previous example used tabs to separate the 111... and 222... from the AAAA and BBBB I get the same results had the starting data been what’s below though the cursors go backwards 12 characters to column 5.

While the cursors are on column 5 the status line says the cursors are on column 17. If I right arrow the cursors move to column 6 and the status line now says they are on column 6.

1111111111111111AAAA
2222222222222222BBBB
3333333333333333CCCCCCCCCCCC

Coises

@mkupper

Strange. I was about to write that I couldn’t reproduce this… then I happened to switch to a different tab and switch back. On switching back, I got the two-line cursor displayed at column 2 with the status line saying column 17.

mkupper

@Coises
I just did an edit at the bottom of my original post as I had

1111111111111111CCCCCCCCCCCCAAAA
2222222222222222CCCCCCCCCCCCBBBB
3333333333333333CCCCCCCCCCCC

at the bottom but intended to have

1111111111111111AAAA
2222222222222222BBBB
3333333333333333CCCCCCCCCCCC

I will use that pattern for this post.

I was not switching tabs but to make sure I’m running a reproducible of npp I fired up a copy of a barebones portable npp8.6 and got the same results as you.

After the paste the cursors looked good and was after the CCCCCCCCCCCC and before AAAA and BBBB. However, the status line said I was on column 17. I switched went to another tab in Notepad and went back and the cursors jump to column 5 but the status line still says they are on 17.

If I re-try the experiment then after the Ctrl-V paste I did a right arrow. The cursors went to column 30 and the status line says 30. Were someone just looking and testing they would say that npp 8.6 worked correctly other than that the status line was wrong for a moment.

As the only differences between my installed copy and bare bones are DSpellCheck (1.5) and PythonScript (2) I tried disabling those plugins.

The cause of the difference in results was PythonScript (2). When I have it disabled I get your results. I tried adding PythonScript (2) to the bare bones portable but that did not break npp 8.6 enough to match what I see on my installed copy.

mkupper

I did more testing and discovered that the version of misbehavior that @Coises observed also happens with npp 8.3.3 and 8.5.8 and thus it’s no longer just a npp 8.6 issue. I experimented more and discovered the reason my installed copy of npp shows the behavior right away, instead of when I switch tabs is that I had:

My plugins\config\PythonScriptStartup.cnf has SETTING/STARTUP/ATSTARTUP
My plugins\config\PythonScript\scripts\startup.py has:

from Npp import editor, editor1, editor2, SCINTILLANOTIFICATION, INDICATORSTYLE
def revert_url_indicator(args):
    editor1.indicSetHoverStyle(8, INDICATORSTYLE.TEXTFORE)
    editor2.indicSetHoverStyle(8, INDICATORSTYLE.TEXTFORE)

editor.callbackSync(revert_url_indicator, [SCINTILLANOTIFICATION.UPDATEUI])

Apparently as the UI gets updated Python is sweeping through all of the tabs which is why for me I did not need to switch to another tab and back to trigger the behavior I reported. That scriptlet came from this forum thread in July 2020.