word wrap is broken

[ssoroka]

Issue Type: Bug

Summary: word wrap doesn't work as expected with the cursor when moving to the end of the line or selecting the entire line. Selecting a line should select all of the line, regardless of where the line visually wraps. VSCode's behavior is inconsistent with other editors, and the current behavior is not useful.

Steps to reproduce

1. turn on word wrap
2. type enough text to wrap to the second line.
3. go back to the start of the first line
4. type command+right_arrow, or move to end of line via any shortcut.

Expected: cursor moves to the end of the line regardless of word wrap
actual: cursor moves to the position where the line is wrapped.

Why this is a problem:
This causes super weird behavior when trying to work with multiple cursors. Imagine a large list of file names where one line happens to wrap. You'd expect to be able to select all, split the selection into cursors, move to the end of the line, and delete the last 3 characters to change the extension, however this doesn't work on the line that wraps.

This also creates weird behavior with "select this line" shortcuts.
I can't think of any cases where it's valid to select a line only up to the point where it wraps to the next line.

Treating a "line" as "a line of text post-wrap" rather than "a line of text pre-wrap" like this is also causing these related multi-cursor bugs:

#65815
#26393

VS Code version: Code 1.30.2 (61122f8, 2019-01-07T22:48:31.260Z)
OS version: Darwin x64 16.7.0

Extensions (22)

Extension	Author (truncated)	Version
npm-intellisense	chr	1.3.0
path-intellisense	chr	1.4.2
vscode-eslint	dba	1.8.0
vscode-npm-script	eg2	0.3.5
json-tools	eri	1.0.2
search-node-modules	jas	1.3.0
string-manipulation	mar	0.3.1
terraform	mau	1.3.7
goto-symbol-stack	mic	1.1.2
vscode-kubernetes-tools	ms-	0.1.14
Go	ms-	0.8.0
sublime-keybindings	ms-	4.0.0
vsliveshare	ms-	0.3.1100
proto	pet	0.0.2
vscode-docker	Pet	0.5.1
vscode-yaml	red	0.2.1
markdown-preview-enhanced	shd	0.3.11
code-spell-checker	str	1.6.10
gitblame	wad	2.6.3
nodejs-extension-pack	wad	0.1.9
JavaScriptSnippets	xab	1.7.2
sublime-commands	Zar	0.1.0

[vscodebot]

(Experimental duplicate detection)
Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:

• Expand line selection does not select all of wrapped line (#21450)
• When a line is wrapped selecting the whole line just selects the first line of the wrapped ones (#30757)
• Column select doesn't to account for wrapped lines (#34331)
• Multi-line paste while zoomed inserts clipboard into wrapped lines more than once (#41152)
• Multi-line caret affects wrapped lines (#61132)

[rioj7]

What I use is press "move to end" twice.
For wrapped lines at the first press the cursor moves to the first wrapped position after the cursor or the end of the line if not found, at the second press the cursor moves to the end of the line.
For non-wrapped lines at the first press the cursor moves to the end of the line, at the second press the cursor stays at the end of the line.

[ssoroka]

Thanks, this is helpful. I think the issue still stands, though, and shows other people have work-arounds for this odd behavior. "Move to line start" is still awkward with moving to the start of the line on multiple lines when some are indented and wrapped and some are indented and not wrapped (You can never get these cursors in sync).

[alexdima]

I have just tried Sublime and they behave the same way. Out of the box, cmd+right moves first to the end of the visible line and on second keypress moves to the end of the logical line also in Sublime.

But if you don't like this out of the box behaviour, you can easily customize your keybindings (e.g. in your keybindings.json):

    {
        "key": "cmd+right",
        "command": "cursorLineEnd",
        "when": "textInputFocus"
    },