cursor up/down is confused by selection

[zeromus]

• VSCode Version: 1.24.0
• OS Version: Windows 7

Steps to Reproduce:

1. Create the following document

dorfus
hamnut

2. Place the cursor at the d and go right three. Then go down. The cursor is at the n. Good.
3. Place the cursor at the end of dorfus and go left three. Then go down. The cursor is at the n. Good.
4. Place the cursor at the d and hold down shift while going right three. Release shift. Go down. The cursor is at the n. Good
5. Place the cursor at the end of dorfus and hold shift while going left three. Release shift. Go down. The cursor is at the end of hamnut? <--- BUG

I expect the cursor to be at n in every case

Other applications, for reference:
visual studio: good
wordpad: good
notepad: good
firefox: good
IE: good
chrome: mysteriously works today, but didn't when I wrote this bug
gedit: "broken" also, but on second thought, maybe it's sensible to some people.

In any event, it's also senseless to some people.

Does this issue occur when all extensions are disabled?: Yes

[killerkalamari]

I believe test 4 should read:

Place the cursor at the d and hold down shift while going right three. Release shift. Go down. The cursor is at the n. Good

Also, for test 5 the well-established Gnome editor 'gedit' also ends with the cursor at the end of hamnut...

[zeromus]

Edited.
As for gedit, I suppose this is "sensible" and must make sense to someone, and likely makes a whole lot of sense for some workflows, and even likely programmery workflows which vscode is trying to adopt and improve on. However, I don't want it. So maybe someone should dig into the rationale behind this, but it needs to be an option regardless. I'd suggest something like CursorWarpEndOfSelection and default it to whatever you folks want.

[alexdima]

SublimeText also ends with the cursor at the end of hamnut. At least in our implementation, the idea is that left and up refer to the beginning of the selection and right and down refer to the end of the selection.