Update after review feedback (CodeRabbit + CI). Pushed three follow-up commits:

1. Nested-fold correctness bug (caught by CodeRabbit) — fixed.
Unfolding an ancestor heading revealed content owned by a still-folded nested heading. _applyFold now consults a pure hiddenByFoldedDescendant() helper so a block stays hidden when it belongs to a nested heading that is itself folded. Added a regression test (fold inner → fold ancestor → unfold ancestor) plus DOM-free unit tests for the helper.

2. A real regression the desktop E2E caught — fixed.
The … marker was set as element text (textContent = "…"), which polluted heading.textContent. The TOC/outline/search read that text, so headingIndexByText() returned -1 and the toc-scroll / toc-panel-content suites failed. The glyph is now drawn via CSS ::after — the element stays a clickable, focusable button but contributes no text to the heading. Added a regression test asserting a folded heading’s (normalized) textContent is unchanged. Desktop E2E is green again.

3. Lint + Sonar — fixed.
Replaced three as unknown as casts with a shared structural type guard isFoldableHeading(); fixed import-order / no-explicit-any in tests; and extracted a shared bootMuya test harness to remove the duplicated setup Sonar flagged (new-code duplication back under threshold).

Current CI: lint, muya e2e (chromium), desktop e2e, test, spec, unit, SonarCloud, and CodeRabbit all green. One unit run here flaked on src/utils/__tests__/deepClone.spec.ts (unrelated to this PR — untouched by the diff, passes locally and on the mirror PR with the identical commit); a re-run should clear it.

Full muya suite: 1509 tests pass; tsc --noEmit and lint clean. Still worth an eyeball across themes/narrow widths per the earlier note, but the silent-freeze class is covered by keeping the marker off the heading width. Thanks @coderabbitai for the nested-fold catch. 🙏

Please remove all design docs before I can take a review.

You can put design docs in PR comments.

Thanks for putting this together, @rkristelijn. I've only driven the UI so far — I haven't read the code yet — so this is first-impressions feedback on the interaction design.

1. The copy-anchor is no longer visible

Moving .mu-copy-header-link from left: -40px to left: -64px pushes it out of the text column. .mu-container has padding: 0 50px, so at -64px the 18px icon spans -14px … +4px relative to the container's border box — 14 of its 18 pixels sit outside the column, and the desktop editor wrapper (.editor-component { overflow: auto }) clips them.

Measured against this PR's CSS (headless Chromium, .mu-container inside the desktop editor wrapper). editorW is the width of the editor area, i.e. window width minus the sidebar:

editorW= 700  container=[0..700]   copyLink=[-14..4]  partly clipped   fold=[10..28]  visible
editorW= 780  container=[0..780]   copyLink=[-14..4]  partly clipped   fold=[10..28]  visible
editorW= 828  container=[14..814]  copyLink=[0..18]   visible          fold=[24..42]  visible
editorW= 920  container=[60..860]  copyLink=[46..64]  visible          fold=[70..88]  visible

So below roughly 828px of editor width — any normal window with the sidebar open — only a 4px sliver of the anchor is left. The chevron took over the one gutter slot that is actually inside the column (-40px) and the anchor was pushed into the clipped zone. The left gutter is 50px wide; it does not hold two affordances.

The right gutter is free and just as wide. I measured right: -40px in the same harness and it is visible at every width (rightGutter=[672..690] at 700px through [922..940] at 1100px), so the chevron can go there without evicting anything.

2. The front-menu fold items feel out of place

The block front menu operates on this block — change its type, duplicate it, delete it. "Fold all" / "Unfold all" / "Fold to this level" are document-wide view commands, so they read as out of place there, and they make the menu longer for something that will be reached for rarely. I'd drop them from this PR. If we want document-wide folding it belongs with the other view commands (app menu / command palette) and deserves its own PR and its own discussion.

3. The trailing "…" marker feels redundant

I understand the argument in the description — a section that just vanishes could be mistaken for an empty one. But the chevron already carries that signal: unlike the copy-anchor it stays visible while the section is folded, and it points right instead of down. A second indicator placed inside the text line means a folded heading no longer looks like the heading the user typed, and it adds a surface that has to keep behaving around wrapping, themes, selection, the TOC and export. I'd drop the marker and the HeadingFoldMarker block with it, and let the chevron own both the state and the click target.

What I'd like to see

Scope this down to the core of #1869: fold/unfold one section via the chevron plus Cmd/Ctrl+Shift+[. Leave .mu-copy-header-link at -40px and move the chevron to the right gutter. That drops the marker block, the front-menu changes and most of the new locale strings, and leaves the part people actually asked for. Document-wide folding can follow separately once this lands.

One merge-forward note for whatever survives: packages/muya/src/locales/ru.ts landed after this branch (#5496), so it has none of the fold strings.

I took a quick look at the code, and there are a few issues that need to be fixed: 1) Keep the code style consistent with the existing code. 2) Don't write too many comments; you need to judge for yourself where comments are needed（AI always write too much comments）. 3) If a function has only one line, don't wrap it in a function, as this makes the code harder to maintain.

Deep review of current head 69a6255b — changes requested before merging.

I reproduced the following against the current implementation (including real Chrome interaction checks):

1. P1 — Hidden content loses its recovery control when a folded heading is removed or converted. Fold # A, put the caret at offset 0, and press Backspace. A becomes a paragraph, but its former section retains mu-folded-content and has no toggle to reveal it. Newly inserted blocks also do not inherit the section's visibility. Fold visibility needs to participate in structural tree changes, rather than only toggleFold() (atxHeading/index.ts:111–153).
2. P1 — Keyboard navigation enters hidden content and subsequent typing goes to the wrong location. With # A, secret, # B, fold A with the caret at its end, then press ArrowRight. The active block and native selection enter the hidden secret paragraph. Typing X then produces X# B in Chrome. Cross-block navigation and selection placement need a defined policy for folded sections (atxHeading/index.ts:138–145, existing content navigation).
3. P2 — Setext headings do not terminate sections. In # A\n\nalpha\n\nB\n===\n\nbravo, folding A hides the same-level Setext B and bravo. collectSectionIndices() only recognizes atx-heading; Setext headings must still act as boundaries even if their own fold controls are out of scope (foldSection.ts:61–68).
4. P2 — Search results remain invisible inside folded sections. Searching for secret after folding its section returns one match and renders a highlight, but the highlight has no visible layout box and the section remains folded. Active search results should reveal their containing folded sections. TOC navigation to a hidden subheading needs the same treatment (blockSyntax.css:214–218, search/TOC navigation).
5. P3 — Expanded-toggle hover styling is overridden. The hN:hover > .mu-fold-toggle selectors override .mu-fold-toggle:hover, so expanded-button opacity stays 0.6 instead of the intended 1. This also introduces two new Stylelint no-descending-specificity errors (blockSyntax.css:177–190).

Maintainability/style follow-ups: remove the unused MU_FOLD_MARKER and production-unused isEmptySection, simplify single-use attachment/class wrappers, eliminate the unconditional Parent as AtxHeading projection and duplicate Parent import, and trim comments that restate code or refer to removed call sites. Keep Muya's package-specific four-space/semicolon conventions.

Validation: all 2,362 existing Muya unit tests pass; five added regression scenarios fail (heading conversion, insertion, keyboard navigation, Setext boundaries, search visibility). ESLint has no errors and circular dependency checks pass. Type checking fails identically on the merge base and PR at the pre-existing items.spec.ts Array.at/lib mismatch. Tests reused the workspace's installed dependencies, rather than reinstalling the PR lockfile.

Fixed the review findings in e935e2f.

• Recompute fold visibility when blocks are inserted, removed, or converted, preserve nested folds, and respect Setext heading boundaries. Capture the section tail while folded so a new paragraph created after the section stays visible.
• Ordinary arrow navigation skips hidden content. Folding moves an existing caret out of the hidden section. Programmatic selection and TOC/anchor navigation reveal their destination before selection or scroll measurement.
• Match the Feishu Docs editing behavior checked in a temporary document: Enter at the start inserts a paragraph before the folded heading; Enter in the middle/end creates a same-level heading after the whole section; a second Enter creates an editable paragraph outside the fold. Shift+Enter uses an inline <br/> to preserve the single-line ATX Markdown representation. Backspace conversion restores the body; Delete at the title end expands and merges the first paragraph.
• Find-in-document expands all sections. For Shift+arrow selection across a folded boundary, expose the destination immediately so the selection cannot silently edit invisible content; this is an intentional adaptation of Feishu's delayed reveal.
• Keep the copy-link control in the left gutter and move the fold control to the right gutter. Fix hover specificity in both states and verify both controls remain within a narrow viewport.
• Centralize fold visibility/navigation, use a typed toggle attachment, remove unused helpers/constants and redundant comments, and avoid sibling scans in containers without active folds.

Validation passed:

• Muya: 2,380 unit tests across 275 files.
• Chromium: 35 new folding interaction tests, plus 8 existing search and undo/redo tests. The matrix covers Enter/Shift+Enter, Backspace/Delete, all four arrows and Shift+arrows, line navigation, Tab/Shift+Tab, copy/cut/paste, select-all deletion, undo/redo, search, TOC reveal, and keyboard activation of the fold control.
• Desktop TOC navigation/key tests: 13 passed.
• Muya ESLint (zero errors), declaration build, desktop typecheck, circular-dependency check, and Muya typecheck with ES2022 libraries.

Local verification used the installed workspace dependencies, which are newer than this PR's lockfile, and temporary configs to allow the isolated worktree to access those dependencies. The root lint command remains blocked by the existing ESLint/@Stylistic configuration incompatibility; the changed Vue file passes using the current workspace ESLint config. Default Muya typechecking retains the existing test Array.at/library-target error, and Stylelint retains one pre-existing .mu-content specificity error. The new fold-control Stylelint errors are resolved. CI results are still pending.

Fixed the CI failure in 0cd6f8b.

The folding navigation test used Ctrl+Right as “line end” on Linux, where it moves by word. The test now uses platform-specific line-start/end keys and checks the destination block and caret before typing.

Also corrected the intermittent #5355 scroll assertion: it now captures the scroll position after Undo settles, so it checks whether the stale table-picker click moves the viewport rather than including Undo's own caret restoration. The document and exact scroll-position assertions remain intact.

Local verification: the full Chromium suite passed (530 passed, 3 platform skips); the long-document scroll case passed 30 consecutive runs. Lint and desktop typechecking passed.

The new Linux Chromium CI run is green: https://github.com/marktext/marktext/actions/runs/39189762054.