zyedidia
Inconsistent behavior of cursor keys depending on whether selection mode is active (newlines) after upgrading to 2.0.14
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: 04c577049ca898f097cd6a2dae69af0b4d4493e1 OS: Alpine Linux Edge (rolling release) x86_64 Terminal: foot 1.18.1, also reproducible on wezterm 20240203.110809.
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.
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: https://github.com/zyedidia/micro/pull/3103. Idk if it is related or not but looks similar
@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 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. :wink:
Right now we're just busy with other tasks.
In case you're comfortable by testing unmerged PRs feel free to try out #3540.
Just a short question into the round regarding this example:
|meow
meow
meow
In case the first whole meow is selected (without the newline; maybe done with 4 times Shift-Right) where do you expect the cursor | to be placed when you press Down?
meow
meow|
meow
or
meow
meo|w
meow
Because we currently discuss this scenario in #3540.
Right now I'm not sure whether the press of an arrow key without Shift after something was selected should only leave the selection mode, or should leave the selection mode and perform a requested cursor move. For example, it seems that VS code reacts to "Left" as "Move to selection start and leave selection mode", to "Right" as "Move to selection end and leave selection mode", and to "Up" and "Down" as "Leave selection move and move Up or Down".
That is, right now I'm not sure whether in the scenario you describe it should be
meow|
meow
meow
or
meow
meow|
meow
But I do know that it shouldn't be
meow
meo|w
meow
because this option, for me, doesn't make a lot of sense. That's what I'd expect after selecting the first "meo" (by doing Shift+Right three times) and then pressing Down. But if I selected the first "meow", then the cursor is after the first "w", so why would it move Down and Left when I press Down?
For example, it seems that VS code reacts to "Left" as "Move to selection start and leave selection mode", to "Right" as "Move to selection end and leave selection mode", and to "Up" and "Down" as "Leave selection move and move Up or Down".
That's exactly what micro does too.
But I do know that it shouldn't be [...] because this option, for me, doesn't make a lot of sense.
And THIS IS exactly the ACTUAL behavior (try it out) and the reason why I've started the discussion in #3540.
so why would it move Down and Left when I press Down?
Seems like it was just a "cosmetic" reason to place the block-like cursor aligned below the last selected character (right edge of the block ends at the same edge where the selection ended). But this as well means, that the cursor...which is the edge on the left hand side of the block...will be moved one character to the left.