vH and vL is not work as expected when $ and ^ is remapped to L and H respectively.

[w93163red]

Describe the bug
When I remapped the $ and ^ to L and H on visual mode, it will not behave as Vim does.
In Vim, if I want to select to end of line, I did vL,
but in vsvim, I need to vlL.
To Reproduce
Steps to reproduce the behavior:

1. remap $, ^ to L, H.
2. type vL.

Expected behavior
should select to line end.
Screenshots
If applicable, add screenshots to help explain your problem.

Environment (please complete the following information):

• Extension (VsCodeVim) version:1.14.5
  Version: 1.46.1
  Commit: cd9ea6488829f560dc949a8b2fb789f3cdc05f5d
  Date: 2020-06-17T21:17:14.222Z (2 wks ago)
  Electron: 7.3.1
  Chrome: 78.0.3904.130
  Node.js: 12.8.1
  V8: 7.8.279.23-electron.0
  OS: Darwin x64 19.5.0

[sql-koala]

This should work / be possible.
Can you post your exact mapping config?

[berknam]

Currently there is an issue in visual mode that if you type a key right after going into visual mode it will send that key to the remapper along with the key used to go into visual mode. Example: in this issue case if you press vL without waiting the timeout between both keys it will check for a visual remap of vL instead of L. If you wait for timeout between those keys then it will work normally. This will be fixed with PR #4735. Now as a quick and dirty workaround you can either wait for timeout or you can repeat the same remaps with 'v' before, in your case you can do:

"vim.visualModeKeyBindings": [
    {
        "before": ["H"],
        "after": ["^"],
    },
    {
        "before": ["v", "H"],
        "after": ["^"],
    },
    {
        "before": ["L"],
        "after": ["$"],
    },
    {
        "before": ["v", "L"],
        "after": ["$"],
    },
]

@J-Fields I don't know what is the ETA to merge PR #4735? If you think it will still take some time and if it is worth it I can try to fix the current remapper just for this issue.

[J-Fields]

@J-Fields I don't know what is the ETA to merge PR #4735? If you think it will still take some time and if it is worth it I can try to fix the current remapper just for this issue.

Hard to say, it's become such a thick PR 🙃 I think I can do another review soon, currently trying to decide whether to put it off til 1.16.0 or delay 1.15.0 to include it.

[J-Fields]

If it's easy enough to peel this fix off of that PR, I'd say go for it - that would certainly make everything a bit more manageable. If it's not trivial, though, probably no sense

[w93163red]

Currently I just manually build a version with this PR, and it works. Jason Fields <notifications@github.com>于2020年7月7日 周二15:34写道：

…

If it's easy enough to peel this fix off of that PR, I'd say go for it - that would certainly make everything a bit more manageable. If it's not trivial, though, probably no sense — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#4991 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABXYLOBXZ5OYEXK5PUYRW4DR2N2FDANCNFSM4OQ33DHA> .

[sql-koala]

Currently there is an issue in visual mode that if you type a key right after going into visual mode it will send that key to the remapper along with the key used to go into visual mode.

Ah, I see. I am not 100% sure, but I think ran into that bug, too. In my case I found a fix by accident:

nnoremap v v

Then first motion after that works as expected.

[berknam]

Ah, I see. I am not 100% sure, but I think ran into that bug, too. In my case I found a fix by accident:

nnoremap v v

Then first motion after that works as expected.

Yep that also fixes it.

If it's easy enough to peel this fix off of that PR, I'd say go for it - that would certainly make everything a bit more manageable. If it's not trivial, though, probably no sense

Its not really a peel off, because this issue is created by a part of code that no longer exists in my PR but is still a quick fix. So I will push it in a moment. Although the fix will be just for the specific situation of this issue, all the other problems with the remapper will still be there.

Hard to say, it's become such a thick PR 🙃 I think I can do another review soon, currently trying to decide whether to put it off til 1.16.0 or delay 1.15.0 to include it.

Yeah I know. I'm sorry! 😅 That's why I put #4995 into another PR. I really think this refactor will improve the experience for a lot of people!

I know it's quite a lot to review but any questions you have feel free to tell me and I'll do my best to help. I tried commenting every piece of code that wasn't obvious. I think I might even have gone overboard with too many comments! 😆 But I think its best to have too much comments than the alternative, specially since there are some pieces of code that might seem simple to understand now I'm working on them but I now that in the future if the comments weren't there it would take a while to figure it out again. I've been using and testing that PR, and some of the latest commits have been some small bugfixes that I already found and fix. I know that after a lot more people start using it there will be more issues coming up that I can't even imagine right now but I'm here to help fix those too when they come.

[J-Fields]

No worries at all, sorry I've taken so long to get to it! I'm super excited to actually get it merged, I think the endless list of issues it'll fix speaks for itself lmao.

I think I might even have gone overboard with too many comments!

This is always better than the alternative imo

I know that after a lot more people start using it there will be more issues coming up that I can't even imagine right now but I'm here to help fix those too when they come.

Yeah this is pretty inevitable with such a large refactor. I'm sure it'll fix more than it causes, though. Since nobody dies or loses large sums of money when a bug is introduced to this project, my attitude is generally "fix the known issues, and wait for people to complain" 🙃