Cursor movement (not jump) opens newly folded range
Describe the bug Cursor movement across folded ranges unfolds the lines, instead of move over the folded range like a single line (which is what this was intended to be in vim).
To Reproduce Steps to reproduce the behavior:
- zf
, e.g. zf3j - j (to go to next line)
Expected behavior
In VIM, cursor will be moved to the next line after the newly created fold in step 1
In VSCodeVim, moving cursor (j/k) will unfold and move the cursor into the unfolded, "physical" line.
Screenshots If applicable, add screenshots to help explain your problem. If remapping-related, please attach log output: https://github.com/VSCodeVim/Vim#debugging-remappings.
Environment (please complete the following information):
- Extension (VsCodeVim) version: 1.27.2
- VSCode version: vscode.dev, 1.87.2
- OS: macOS, Chrome
Additional context Add any other context about the problem here.
I think what you described is the expected behaviour in VSCodeVim and you can use gj and gk instead of j and k to achieve what you expected.
You can create a remap in your settings.json with something like this:
"vim.normalModeKeyBindingsNonRecursive": [
{
"before": [
"j",
],
"after": [
"g",
"j"
]
},
{
"before": [
"k",
],
"after": [
"g",
"k"
]
}
],
So if I'm understanding you correctly, this difference in behaviour from vim is expected? And why this change? If I'm creating a fold it generally means I know I don't want to look at them unless specifically to, but now that in VSCodeVim the most frequently used cursor moving keys (j/k) will simply expand this. Why is the default behaviour here instead of what vim is doing?
I can't say for certain why it's implemented this way in VSCodeVim as I didn't write it, but anyway you can always remap it.
you can add this settings:
"vim.foldfix": true,
to fix the fold bug