$ command takes newline in visual mode

[pattersongp]

Describe the bug
When in visual mode, using the $ command should take you to the last character of a line, not including the new line, if present.

To Reproduce
Steps to reproduce the behavior:

1. Go into visual mode.
2. Use $ to go to the end of line, but end with the cursor on the next line.

Expected behavior
The expected behavior is stopping at the last character, that is not a new line.

Environment

• Extension (VsCodeVim) version: v1.9.0
• VSCode version: 1.36.1
• OS: macos x 10.14.5

[pattersongp]

A note: this feature works in normal mode. This issue is only with respect to visual mode.

[renodubois]

Just wanted to second that I've seen this issue as well. Same circumstances, same behavior.

Environment

• Extension (VSCodeVim) version: v1.9.0
• VSCode Version: 1.37.0
• OS: macOS 10.14.5

[stevenguh]

@J-Fields Seems like your change broke some tests
https://travis-ci.org/VSCodeVim/Vim/builds/579332258?utm_source=github_status&utm_medium=notification

[J-Fields]

@stevenguh You're right, thanks for pointing that out. I'll fix that this afternoon.

[J-Fields]

@pattersongp I swear I replicated this in vanilla vim the other day, but now when I try v$ in vim, it does include the EOL. We have tests for this case. Can you verify that this isn't actually how vim behaves?

[stevenguh]

v$ will include the EOL character for me in vanilla Vim

[pattersongp]

This is vanilla vim:
https://asciinema.org/a/xrzqlrtqiAZwZeIUvfnPI47rp

[stevenguh]

That video is already showing v$ including the new line character. Try using vg_ to see the difference.

You can see the difference if you enter two lines of text.
ggv$y and paste it somewhere
This will include a EOL
vs
ggvg_y and paste it somewhere
This will not include a EOL

[Ashymad]

Indeed, v$ will select the EOL as well (checked in neovim). The difference is only visual, in vim the cursor doesn't appear in the next line after v$, while in VSCodeVim it does.

[pattersongp]

I agree that the EOL is taken into the clipboard, but the cursor should not appear on the following line. Sorry-- the issue should be cursor appears on next line after v$

[stevenguh]

I think that's the limitation of VS Code, but I don't know enough to say for sure.

[J-Fields]

Yes, I believe this is not possible in VSCode. Another rendering limitation is that the block cursor is wider when on top of a tab character.

[wandaud]

hey, so this bug still can't be fixed?

[CanonRouge24]

At least, as mentioned, there exists an alternate motion g_ that does work as we want.

You can rebind $ to g_ (I personally swapped the two, as follows):

(in settings.json)

"vim.visualModeKeyBindingsNonRecursive": [
    {
        "before": ["$"],
        "after": ["g", "_"]
    },
    {
        "before": ["g", "_"],
        "after": ["$"]
    }
]

[tekboart]

At least, as mentioned, there exists an alternate motion g_ that does work as we want.

You can rebind $ to g_ (I personally swapped the two, as follows):

(in settings.json)

"vim.visualModeKeyBindingsNonRecursive": [
    {
        "before": ["$"],
        "after": ["g", "_"]
    },
    {
        "before": ["g", "_"],
        "after": ["$"]
    }
]

Thank you CanonRouge24, your solution solved the aforementioned problem for me. I've been entangled with this problem for over 2 years now, but now thanks to you it's resolved for good.

[darianmorat]

At least, as mentioned, there exists an alternate motion g_ that does work as we want.

You can rebind $ to g_ (I personally swapped the two, as follows):

(in settings.json)

"vim.visualModeKeyBindingsNonRecursive": [
    {
        "before": ["$"],
        "after": ["g", "_"]
    },
    {
        "before": ["g", "_"],
        "after": ["$"]
    }
]

But this is modifying a DEFAULT VIM behavior. I wouldn't do that, the only problem is visual, cause it shows the cursor in the second line. But actually that is going to give a better understanding to people who don't know that much about VIM, about how it actually works