Vim: Folded code unfolds if you spend some (unknown number) of ms idle in a fold

We just pushed out a new version, so enable vim.foldfix and tell us what you think!

It’s a hack and not a proper solution to this problem, so we’ll probably leave this issue open for now.

+1 for this. Having my folds open while I’m navigating is quite frustrating. I find myself having to use my mouse to reposition my cursor, which should make all of us sad.

+1 comments aren’t going to do anything but annoy the repo owners. Please use the 👍 reaction on the original post instead. Be kind to repo owners and other subscribed users.

😃 It’s okay. We generally use thumbs up as a measure of importance, but the extra signal we get from people who were so bothered they had to come and leave a comment is a little useful too. We’re definitely aware this one is painful - we’ll try to fix it as soon as we can!

I polished up my fix over here: https://github.com/VSCodeVim/Vim/pull/1552

It does some hackish stuff, but it seems to work great for me. Here’s a pretty bad demo:

I can confirm what @pizzooid has noted, that gj and gk correctly step over folded sections even without vim.foldFix enabled. If you want to use this as a workaround, you can add the following to your settings JSON:

"vim.normalModeKeyBindings": [
    {
        "before": ["j"],
        "after": ["g", "j"]
    },
    {
        "before": ["k"],
        "after": ["g", "k"]
    },
    {
        "before": ["$"],
        "after": ["g", "$"]
    },
    {
        "before": ["^"],
        "after": ["g", "$"]
    }
],
"vim.visualModeKeyBindings": [
    {
        "before": ["j"],
        "after": ["g", "j"]
    },
    {
        "before": ["k"],
        "after": ["g", "k"]
    },
    {
        "before": ["$"],
        "after": ["g", "$"]
    },
    {
        "before": ["^"],
        "after": ["g", "$"]
    }
]

Would it make sense to make this the default behavior for the plugin? Or would this be too unexpected for folks who are used to traditional vim behavior for j and k?

Update 2019-02-26: I’ve updated the settings to handle the $ and ^ movements correctly.

I agree with @Chillee . Maybe some one should reopen the issue with vscode? It has been a couple of years maybe it can be prioritized.

sorry to say, but this makes the extension useless for me.

greetz…

I have only "vim.foldfix": true, in my settings and it works fine, both with j, k and upArrow, downArrow.

with foldfix it works with j/k, but

• ctrl-u/ctrl-d
• {/} (shift-[/shift-])
• 10-/10+ (relative jump)

still open collapsed fold.

vscode just close Microsoft/vscode#22276, they will not consider this feature in the next 6-12 months roadmap.

I’ve created a new issue about it, go and vote! 😉

https://github.com/microsoft/vscode/issues/81498

As an alternative to CTRL-u & CTRL-d I’ve been using H & L which do not break the fold.

To add on this, you can use the following settings to make it more jump like:

"vim.normalModeKeyBindings": [
      {
        "before": ["<C-u>"],
        "after": ["H", "z", "z"]
      },
      {
        "before": ["<C-d>"],
        "after": ["L", "z", "z"]
      }
]

Its been almost two years since microsoft/vscode#22276, maybe it’s worth to try again?

after set foldfix, j/k works fine to skip fold, but ctrl-u/ctrl-d still break the fold.

We just pushed out a new version, so enable vim.foldfix and tell us what you think!

It’s a hack and not a proper solution to this problem, so we’ll probably leave this issue open for now.

Can you make this a default option, not everyone know about this, I just want to open an issue then when I search again on google, finally I landed on this, or at least the issue should be pinned down.

Thank you for brigging the foldfix, I really frustated with how the cursor open all fold

with foldfix it works with j/k, but

• ctrl-u/ctrl-d
• {/} (shift-[/shift-])
• 10-/10+ (relative jump)

still open collapsed fold.

As an alternative to CTRL-u & CTRL-d I’ve been using H & L which do not break the fold.

I can confirm what @pizzooid has noted, that gj and gk correctly step over folded sections even without vim.foldFix enabled. If you want to use this as a workaround, you can add the following to your settings JSON:

"vim.normalModeKeyBindings": [
    {
        "before": ["j"],
        "after": ["g", "j"]
    },
    {
        "before": ["k"],
        "after": ["g", "k"]
    },
    {
        "before": ["$"],
        "after": ["g", "$"]
    },
    {
        "before": ["^"],
        "after": ["g", "$"]
    }
],
"vim.visualModeKeyBindings": [
    {
        "before": ["j"],
        "after": ["g", "j"]
    },
    {
        "before": ["k"],
        "after": ["g", "k"]
    },
    {
        "before": ["$"],
        "after": ["g", "$"]
    },
    {
        "before": ["^"],
        "after": ["g", "$"]
    }
]

Would it make sense to make this the default behavior for the plugin? Or would this be too unexpected for folks who are used to traditional vim behavior for j and k?

Update 2019-02-26: I’ve updated the settings to handle the $ and ^ movements correctly.

I would suggest to use vim.normalModeKeyBindingsNonRecursive and vim.visualModeKeyBindingsNonRecursive to make sure we avoid nasty recursive loops. Other than that, I can only confirm this is a working workaround! Cheers! 😃

@gschintgen Unluckily, the best solution is to not set foldfix to true for most people 😕

I would say “partially fixed”. I can navigate over folds but if i initiate a fold from inside from anywhere but the top of of the folding block then it immediately unfolds. This is certainly better than before though. VSCode v1.12.2 Vim v0.8.4

I just found noticed that gj works properly without vim.foldfix enabled. Is that because of the fix, or would that be a different method for building foldFix?

@Phrohdoh for example 25gg will take you to 25th line not the beginning i meant end of the block by last line

@desprit The issue isn’t closed. As far as I know (it’s been a while since I’ve looked into this very closely), there’s nothing we can do unless VSCode expands its API to give us more information about folded regions.

The j to gj bind is undesireable, IMO. gj won’t “remember” which column you were at when pass an empty line.

gj will result in: line 1: column 45 line 2: column 0 (empty line) line 3: column 0

j will result in: line 1: column 45 line 2: column 0 (empty line) line 3: column 45

With foldfix enabled, relative jumping is no longer instant, and it is inaccurate when jumping over a fold.

there was a response here from a maintainer of vscode suggesting a solution to this.

Wouldn’t a good solution to this be a vscode api where cursorDown just has a new boolean argument that is something like openFolds: false. It seems like they are open to that

The biggest downside in theory is that it deviates from the expected vim behavior. gj/gk are the commands for move the cursor around wrapped lines, which means if you’re expecting to jump over wrapped lines the same way it jumps over folded lines, then it’ll be a bit confusing (since it effectively jumps into the middle of a wrapped line). This behavior is acceptable for me, but might be undesirable for vim purists (though tbh I also don’t know how the real vim handles folding 🤷‍♀️).

The other issue is that I’m not sure those keybindings are quite complete. For example $/^ aren’t modified, so they still treat wrapped lines like a single line, while j/k now treat wrapped lines as multiple different lines. I’ve also noticed that some cursor motions while working with wrapped lines don’t quite work as expected, though I haven’t yet figured out what’s going on there. I’ll update my comment if I find any other improvements 🙂

IDK, why VSCode team helping us out on this problem. There are more than 6M+ VIM users & I’m one of them cry, We love this extension but So helpless, hopeless.

PRs welcome

Hi, it’s a pity that I can’t really use code folding due to this issue.

I tried foldfix=true (which seems to work fine), but unfortunately it leads to very laggy behaviour: If I keep j or k pressed in order to move up or down in a source file, the cursor continues to move down or up even after I let go of the movement key. The cursor is playing catch-up.

This is 100% reproducible on my machine (4th gen. mobile i7) and even happens when I don’t have any folded code parts!

Do note that even though my comment may sound negative, I’m very grateful for the active development of this extension!

@rogersachan There’s been a significant amount of discussion on the VSCode repo, and it’s a very nontrivial task. Take a look at https://github.com/Microsoft/vscode/issues/22276

@meherranjan I agree. It’s an ugly hack, which is why it’s not enabled by default and why this issue remains open.

Good catch, @zwing99! I’m seeing the same thing on my end, as well.

Oops now I’m spamming (I didn’t mean to close this).

+1 for fixing this asap