Inconsistent cursor up/down moving after selecting with keyboard/mouse

Description of the problem or steps to reproduce

It isn't a problem (maybe the most minor bug ever).

When you select text with keyboard (Shift+) and after selecting press up/down the cursor will appear from the left side. It doesn't matter what direction of selecting was.

RRRRRRRRRR
RRRR🔴RRRRR

When you do the same with mouse the result will be different. (Only) if you started select from right to left, the up/down action will place cursor from the right side.

RRRRRRRRRR
RRRRRRRRR🔴

Specifications

Commit hash: v2.0.13 68d88b5
OS: Debian 12
Terminal: foot/gnome-terminal

Direction of text selection with mouse matters so it seems to me that it just "swaps" two coordinates in CurSelection or/and OrigSelection

https://github.com/zyedidia/micro/blob/2d82362a6695a7e898455ce016449167ac439ddd/internal/buffer/cursor.go#L19-L35

It looks like if you start select from end (with mouse) it will set the end coordinate to "start" part of CurSelection

https://github.com/zyedidia/micro/blob/2d82362a6695a7e898455ce016449167ac439ddd/internal/buffer/cursor.go#L146-L154

[vicencb]

I also have noticed some cursor placement inconsistencies after a selection: for example, this sequence
SelectDown: select text, keep cursor.X coordinate, expected.
CursorRight: deselect text, keep cursor.X coordinate, expected.
CursorDown: increase cursor.Y coordinate, expected, and change cursor.X coordinate, unexpected.
The cursor.X coordinate is decremented if possible, otherwise it is moved to the end of the line.

CursorDown: increase cursor.Y coordinate, expected, and change cursor.X coordinate, unexpected.

Do you mean that if I press down in this situation, the cursor will be in the end of 5 line and not straight below under selected a?

CursorRight: deselect text, keep cursor.X coordinate, expected.

1. It seems to me more convenient that cursor will be placed on the edge of selection whatever of four directions (up,down,left,right) you pressed
2. In general it is a matter of choice...
3. To be more precious it is consistent behavior. Look at https://github.com/zyedidia/micro/blob/2d82362a6695a7e898455ce016449167ac439ddd/internal/action/actions.go#L186-L188 and https://github.com/zyedidia/micro/blob/2d82362a6695a7e898455ce016449167ac439ddd/internal/action/actions.go#L211-L213
   They use the same logic. the same Deselect function. With true parameter itmoves cursor on deselection to the start of selection with false parameter to the end... But as I said it is in general a matter of choice...

[vicencb]

No, i was not referring to this use case.

Here is a concrete example to reproduce the issue i am referring to:

Given this text file:

1234
ABCD
EFGH
IJKL

Move the cursor to 1 if not already there, then SelectDown, then CursorRight and finally CursorDown.
After this, the cursor is expected to be at E but instead it is after the H.

I will try to rephrase and describe it in a bit another way. When you do SelectUp the current position becomes end of the selection and the position after doing up becomes start. If you do the same thing with mouse the start will be place from what you started selection but if you moved your mouse up, start will end up after end because micro won't swap them.

It isn't a big issue and it can be swapped very easily with 2-5 lines somewhere but now I don't know where it should be done. Alternatives that I see:

1. It deserves separate function something like AdjustSelection and should be checked in each operation that use Deselect
2. It should be a part of Deselect
3. It should be done in places where we create the selection
4. It should be part of SetSelectionEnd (which I prefer)