Move Line Up/Down incorrectly moves the line below selected line(s)

[jzniu]

Environment

• TeXstudio: 4.5.2
• Qt: Qt6
• OS: Windows10
• TeX distribution: miktex

Expected behavior

Select one or multiple lines (from start of line N to start of line N+m), then use Move Line Up/Down to move the selected line(s) up and down. Only those selected lines (line N to line N+m-1 exactly, inclusive at both ends) move, not including line N+m.

Actual behavior

Line N+m moves along as well.

If the selection ends at the end of line N+m-1, then line N+m doesn't move along. It seems that the EOL character in line N+m-1 leads to the inclusion of line N+m. This may relate to the way of implementation regarding how many lines are considered.

Popular text editors, such as vscode, behave consistently regardless whether the EOL is included or not.

[octaeder]

I think this is a result of working with selections, s. LatexEditorView::getSelectedLineBlocks:

When a cursor is found with a selection then the indices of all lines from selection.startLine to selection.endLine are added to a list of lines being moved. But the last line should only be added if the selection doesn't end in column 0.

[jzniu]

Just tested in texstudio 4.6.0. This bug doesn't seem to be fixed, at least not fixed for demonstrated scenario shown below:

(select multiple lines and then move line up/down)

[octaeder]

TeXstudio 4.6.3 (git 4.6.2-8-gfe43e18c2) moves line 5 even so there's no real selection because the selection started in line 2 column 0 and ended in line 5 column 0 (blue selection highligting ends at end of line 4):

\documentclass[10pt,a5paper]{article}
\begin{document}
1
3
4
5
2
6
\end{document}

[octaeder]

The question is, what exactly is selected here? When you move the cursor at the beginning of line 5 one to the left then it works. And the blue highlighting is different:

after moving cursor left:

The difference in selection is the newline character.
Is this a natural/expected behavior in practice?

[octaeder]

Look at notepad++. Line 5 is not moved, but some changes appear:

select:

move up (look at cursor, probably anchor and cursor are interchanged):

Since highlighting doesn't look similar to the next image, I assume that anchor is located before number 2 (newline is selected) not after 4.

select:

move up:

[jzniu]

Several popular text editors, including vscode, notepad++, and sublime text, move the lines selected, including all text and eol characters on the lines that are even partially selected, regardless where the cursor is located, but not including the line where nothing is selected and only has the cursor at the start. For example, giving the following content:

1
2
33
444
5

If you have the following selected (in [])

3[3
44]4

The entire two lines will still move.

However I do notice that notepad++ somehow changed the selected scope when you move the lines to include the entire two lines, but vscode and sublime text don't do that although the entire lines move together. Obviously the latter is more reasonable and expected.