The editor lands where the preview does, and the outline follows from the same line - #751
Merged
Merged
Conversation
…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.
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
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 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:revealSourceRangetakes a placement, and only the outline asks fortop.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 oneeditorReadingPositionuses. 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.tsandtocFollowsEditor.test.tsare 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 oldtoRendererLine(position.line).Verification
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.