Moving cursor across folded code should not automatically unfold

[rodrei]

VSCode Version 1.14.1 (1.14.1)
macOS Sierra 10.12.5

Reference: microsoft/vscode#16858

[skube]

While this issue is super annoying, a workaround I've noticed on macOS is jacking up key repeat in settings, allows one to skip across folded regions. Though it's still traversing the folded code, it doesn't unfold it.

[aioutecism]

@skube
Yes, but this only work if you go pass a short folded code.

This is really an annoying issue that I'll try to fix soon.

[skube]

It works in long-folded code too, you just have to wait longer for it to come back out. ⏳

I agree though, it's super annoying.

[JulianGindi]

Is there a non-mac workaround? This is extremely annoying.

[PZ01]

Currently, I use relative line numbers and skip ahead by multiplying my cursor movement by the number of lines indicated after a fold. It's far from ideal.

[teddyknox]

+1

[markovicdenis]

Fixing this issue would make this plugin perfect. Could the solution from vscodeVim be implemented in this plugin?

VSCodeVim/Vim#1004

[waynchi]

Edit: This has unfortunate side effects (e.g. 10j now shifts the cursor 1 line by 1 line rather than all at once). Leaving the comment here in case anyone wants to try it.

For those using VSCodeVim and still searching,

"vim.normalModeKeyBindingsNonRecursive": [
        {
            "before": ["j"],
            "after": ["g", "j"]
        },
        {
            "before": ["k"],
            "after": ["g", "k"]
        }
]

Fixes the issues for me

[sabetAI]

VSCodeVim/Vim#1004 (comment)
Set vim.foldfix = true in settings.json.

[xytxxx]

VSCodeVim/Vim#1004 (comment)
Set vim.foldfix = true in settings.json.

It works, thanks !

[ceyhunsony]

It works great! But, shouldn't this be the default behavior? I really was fed up with the current behavior and at long last searched for it and found above two comments, which helped. Is the vim.foldfix = true too hacky to be set as default?

[b-ssr]

Ctrl-d / Ctrl-u still unfolds the code.

Moreover when "foldfix=true" is set moving with those shortcuts is very weird and works as not as expected.

[ceyhunsony]

I see, indeed ctrl+d and ctrl+u can still unfold, even though j/k works fine. This issue still needs a fix.

[kola-web]

试一下这个设置
{ "key": "k", "command": "cursorUp", "when": "editorTextFocus && amVim.mode != 'INSERT' && amVim.mode != 'VISUAL'" }, { "key": "j", "command": "cursorDown", "when": "editorTextFocus && amVim.mode != 'INSERT' && amVim.mode != 'VISUAL'" }

[alireza-mh]

This is still open and vim.foldfix = true works on vim extenstion not amvim

[notiv-nt]

There is a native vscode's command:

{
  "key": "<>",
  "command": "cursorMove",
  "when": "editorTextFocus && amVim.mode == '<>'",
  "args": {
    "to": "prevBlankLine" || "nextBlankLine",
    "by": "wrappedLine",
    "select?": true
  }
}

Example:

{
  "key": "shift+h",
  "command": "cursorMove",
  "when": "editorTextFocus && amVim.mode == 'NORMAL'",
  "args": { "to": "nextBlankLine", "by": "wrappedLine" }
},
{
  "key": "shift+t",
  "command": "cursorMove",
  "when": "editorTextFocus && amVim.mode == 'NORMAL'",
  "args": { "to": "prevBlankLine", "by": "wrappedLine" }
},
{
  "key": "shift+h",
  "command": "cursorMove",
  "when": "editorTextFocus && amVim.mode == 'VISUAL'",
  "args": { "to": "nextBlankLine", "by": "wrappedLine", "select": true }
},
{
  "key": "shift+t",
  "command": "cursorMove",
  "when": "editorTextFocus && amVim.mode == 'VISUAL'",
  "args": { "to": "prevBlankLine", "by": "wrappedLine", "select": true }
},
{
  "key": "shift+h",
  "command": "cursorMove",
  "when": "editorTextFocus && amVim.mode == 'VISUAL LINE'",
  "args": { "to": "nextBlankLine", "by": "wrappedLine", "select": true }
},
{
  "key": "shift+t",
  "command": "cursorMove",
  "when": "editorTextFocus && amVim.mode == 'VISUAL LINE'",
  "args": { "to": "prevBlankLine", "by": "wrappedLine", "select": true }
}

[alisonatwork]

In the upcoming release of amVim extension gj and gk are supported, which will allow you to move over a fold without popping it open. We are also looking into a better way to configure normal arrow keys and j/k to move over a fold, see #303. Please weigh in on the pull request if you have some thoughts. I hope to be able to get a new release out to address this sometime this week.

[alisonatwork]

I have just merged the functionality to publish amVim.waitingForInput context (see #303), which will allow those of you using solutions like the one @kola-web provided to more specifically target navigation only and not hijack longer vim commands. This will be released in the upcoming 1.36.0 version. In the mean time, gj and gk are already released in 1.35.0.

I will close this issue for now. Thank you all for the patience and please let us know if you have any further issues.