Treat folds the same as normal lines for cursor movement

[calebmeyer]

• VSCode Version: 1.11.2
• OS Version: Windows 10 Anniversary Update

The bug I'm experiencing has two parts:

1. When moving down using the down commands (vim j in normal mode, or keyboard down arrow in insert mode), the cursor is moved to the end of the line (the fold marker) for lines which have a fold.
2. When the cursor is left on a fold marker for longer than a few hundred milliseconds, the fold expands.

Steps to Reproduce

1. Create a fold
2. Starting from the top line of the fold, move the cursor down with the keyboard (I moved it down twice in the gifs)

Expected Result

The cursor treats folded lines as it treats any other lines (you can move up, down over a folded group as though they were all a single line)

Here's the expected behavior, in atom (I apologize for my poor gif quality):

Actual Result

Hitting down moves the cursor to the end of the line, atop the fold indicator.
The fold expands.

Here's the actual behavior, in VS Code:

Notes

I'm using the vim extension in VS Code and vim-mode-plus in Atom. In both cases, it doesn't matter whether I use j or down arrow.
I'd love to see a setting to disable the auto fold expansion, assuming it's working as designed. I'd much rather toggle the fold myself with a keybinding.
I'd also love to see a toggle fold command. It appears VS Code only has expand and collapse commands.

[alexdima]

@calebmeyer This works as you describe out-of-the-box (i.e. with the vim extension disabled).

I can only recommend that you create an issue on the vim extension. They could perhaps implement more of their motions by invoking core editor commands, in this case for j it would be: "move" with the args { "to": "down", "by": "wrappedLine", "value": 1 }.

[calebmeyer]

Turns out there is already an issue: VSCodeVim/Vim#1004
and a request back to this repository: #22276

[Chillee]

The issue we have in VSCodeVim is that we want to move by "line", normally, but we also don't want to open up folds automatically.

Doing move with "line" satisfies the first part, while doing move with "wrappedLine" satisfies the second part.

Is there some solution I'm unaware of that allows us to have the desired behaviors of both?

[calebmeyer]

The solution atom and unmodified vs code uses (which works fine for me), is to treat movement by visible line instead of by actual line.

Thus moving down on a fold jumps to the end of the fold instead of the next line (which is inside the fold).

I'd argue (from a vim standpoint) that the motion is more useful if it treats the entire fold as one line. Thus yy would copy the entire folded bit, 2j would move two visible lines, d2d would cut the entire fold and the line below it, etc. This means you don't have to unfold the fold to operate on it as a unit. It's pretty rare that I'd want the first line or two of a fold without being able to see what I'm doing (unfolding it).

@Chillee can you explain why you would want to move by "line" for folds?

Edit: Just checked actual vim, movements treat folds as a single line there.

[Chillee]

The issue isn't that I want to move by "line" for folds, it's that moving by "line" automatically expands the fold.