fix: zC only closes the innermost fold, not enclosing ones - #10062
Open
edsattar wants to merge 1 commit into
Open
fix: zC only closes the innermost fold, not enclosing ones#10062edsattar wants to merge 1 commit into
edsattar wants to merge 1 commit into
Conversation
zC dispatches editor.foldRecursively, which closes the single fold directly containing the cursor (plus any of its own descendants), but never climbs through the folds enclosing it. Vim's zC is supposed to close every fold level containing the cursor, from innermost out to the outermost. zc already handles this correctly via editor.fold with direction 'up' and a count-based levels arg; this applies the same mechanism to zC with an effectively unlimited level count instead of relying on foldRecursively.
edsattar
added a commit
to edsattar/Vim
that referenced
this pull request
Jul 14, 2026
Same root cause as the zC bug in VSCodeVim#10061: the close branch dispatched editor.foldRecursively, which only closes the fold directly containing the cursor and does not climb through enclosing folds. Switched to the same editor.fold with direction 'up' and an unlimited levels approach used to fix zC in VSCodeVim#10062, so zA's close direction now climbs all enclosing folds from the cursor's position, not just the innermost one.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this PR does / why we need it:
zCis meant to close the fold under the cursor and every fold enclosing it, all the way out to the outermost level. Instead it only closes the single innermost fold directly containing the cursor, folds enclosing it stay open. This is becausezCdispatches VS Code's nativeeditor.foldRecursively, which recurses into descendants of the fold at the cursor, not ancestors.zc(lowercase) already avoids this problem by usingeditor.foldwithdirection: "up"and a count-basedlevelsargument, which correctly climbs outward through enclosing folds. This PR applies the same mechanism tozC, with an effectively unlimited level count instead of a count prefix, sincezC(unlikezc) isn't meant to take a count, it always means "all levels."Which issue(s) this PR fixes
Fixes #10061
Special notes for your reviewer:
zC.zOdoesn't have the equivalent problem: closing a fold already hides everything nested inside it regardless of descendants' own state, so "recursing into descendants" is meaningless for close, but opening genuinely needs to cascade into nested closed folds, whicheditor.unfoldRecursivelyalready does correctly.zCnow collapses all three levels in one press, matching the fixed result exactly.levels: 999is a pragmatic "effectively unlimited" sentinel, VS Code'seditor.foldnaturally clamps to however many enclosing levels actually exist, verified directly rather than assumed.