Inconsistent behavior of cursor keys depending on whether selection mode is active (newlines) after upgrading to 2.0.14

[inga-lovinde]

Description of the problem or steps to reproduce

Create a new file with the following content:

123
456789
abc
def

Position cursor to 1, press arrow down, observe that the cursor is currently at 4, as expected.
Position cursor to 4, press arrow down, observe that the cursor is currently at a, as expected.

Now position cursor to 1, press Shift + arrow down, observe that the entire line 123 is selected (including the trailing newline), as expected. Press arrow down again to clear the selection and move to the next line, observe that the cursor is currently at 7, which is not expected and not how other similar text editors typically work (expected would be the cursor at 4 or a).
Position cursor to 4, repeat the same steps, observe that the cursor is now on abc line after c (expected would be the cursor at a or d).

Basically the problem is that after selection with Shift+down, the cursor seems to move to the newline character of the selected line, rather than the place immediately below the originally focused character (or the rightmost place of the line below if it's too short and doesn't reach the originally focused character).

This breaks patterns like: "Ctrl+Home, Shift+down, Ctrl+C, down, down, Ctrl+V" which used to insert a copy of the first line as the new line between two other lines, but now instead appends a copy of the first line (including the newline character) to the other line.

In 2.0.13 this used to work as expected, producing for the document

meow
meow
meow
meow
meow

the new content

meow
meow
meow
meow
meow
meow

But the behavior changed in 2.0.14, and the same commands now produce

meow
meow
meowmeow

meow
meow

Specifications

Commit hash: 04c5770
OS: Alpine Linux Edge (rolling release) x86_64
Terminal: foot 1.18.1, also reproducible on wezterm 20240203.110809.

[dmaluka]

The PR that caused this regression: #3091.

@dustdfg FYI.

The intention of #3091 was to provide consistent cursor movements after a multiline selection: make sure that moving cursor down moves it to the next line after the last line of the selection, not after the first line of the selection. And as side effect, it also caused the cursor position within the line to move to the character below the end of the selection, not below the start of the selection.

AFAICS gedit editor behaves similarly to micro with #3091 in this regard, but at the same time doesn't have this issue with newlines. IOW when moving cursor down, gedit moves to the character below the end of selection (like micro with #3091), however in the case when the selection end at a newline, gedit moves the cursor to the beginning of the next line (unlike micro with #3091). So to fix this regression, we might want to mimic gedit behavior.

[dustdfg]

I am not much interested in micro and busy with other things for now so I didn't thoroughly read and investigated but it somehow remembered me about this: #3103. Idk if it is related or not but looks similar

[JoeKar]

@dmaluka is right, this was introduced with #3091.

Before going down...

...and after going down...

...where the weirdest thing is that line 2 is already marked as the current one, while the cursor still stays in the first.

So to fix this regression, we might want to mimic gedit behavior.

Currently I can't directly compare to gedit, but the gnome-text-editor on the other hand does seem to do more or less the same. In the particular scenario it moves the cursor to the first position of line 3.
So yes, I vote to mimic the already "common" behavior for this special case. The rest seems to fit to the others.

[plyght]

@JoeKar any updates on this?

[JoeKar]

@plyght No one had time so far to take care of it, but it is scheduled for the v2.0.15 release.
So we wont forget it. 😉

Right now we're just busy with other tasks.

[JoeKar]

In case you're comfortable by testing unmerged PRs feel free to try out #3540.