Skip to content

The editor lands where the preview does, and the outline follows from the same line - #751

Merged
PathGao merged 1 commit into
masterfrom
fix/outline-jump-placement
Sep 2, 2026
Merged

The editor lands where the preview does, and the outline follows from the same line#751
PathGao merged 1 commit into
masterfrom
fix/outline-jump-placement

Conversation

@PathGao

@PathGao PathGao commented Sep 2, 2026

Copy link
Copy Markdown
Collaborator

What this is

Follow-up to #748, which I pushed to that branch after it had been merged, so it never landed. Two things found testing the split-view jump on a build (ref #744).

Mechanism

Where a click lands. The preview puts the clicked heading just under its top edge; the editor centred it. With scroll sync off the two panes showed different places (with it on, the editor's scroll then dragged the preview into agreement, which is why it looked fine there). The editor now reveals the heading near its top too (revealLineNearTop, a gap of five lines or 20% of the viewport). The context menu's Edit keeps centring: revealSourceRange takes a placement, and only the outline asks for top.

Following the editor. The outline was one entry behind whenever a heading was the first line on screen: it was handed Monaco's top line, the one the viewport cuts in half. It now gets the line the tab records as its reading position, through tabAnchorForEditorTopLine — the one crossing from a Monaco top line into the outline's numbering, the same one editorReadingPosition uses. The preview side already fed the outline from its anchor line; now both panes do.

Scope

The second half of #744, "scrolling the editor does not move the outline highlight", was checked on a build and is not broken: the highlight follows the editor's scroll with sync off and on. It follows the scroll position, not the caret. Not changed.

At the exact boundary the two panes can disagree by one entry (the preview's anchor is 60px down, the editor's two lines down); whichever scrolled last wins. Inherent to two anchors, unchanged.

The source assertions in jumpToSelectedFragment.test.ts and tocFollowsEditor.test.ts are updated to the new contract; the latter's conversion fixture now pins the anchor-line case (top line one short of a heading → the heading's entry), which fails against the old toRendererLine(position.line).

Verification

npm run check       830 files, 0 errors
npm test            1028 pass
npm run test:vitest 434 pass

On a build, driven by script: click an entry with sync off → editor at the heading (selected, five lines from the top), preview at the heading. Wheel-scroll the editor with sync off → outline follows while the preview stays; with sync on → preview follows, outline agrees. Caret walked across a heading without scrolling → outline unchanged.

…om the same line (#744)

Two follow-ups from testing the split-view jump on a build.

A click on the outline put the heading just under the preview's top edge
and in the centre of the editor, so with scroll sync off the two panes
showed different places. The editor now reveals the heading near its
top too; the context menu's Edit keeps centring.

Following the editor, the outline was one entry behind whenever a
heading was the first line on screen: it was handed Monaco's top line,
the one the viewport cuts in half. It now gets the line the tab records
as its reading position, through tabAnchorForEditorTopLine — the same
crossing the preview's handler already feeds it.
@PathGao
PathGao merged commit 90efe5a into master Sep 2, 2026
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant