feat(preview): Edit jumps to the fragment you right-clicked

[PathGao]

Fixes #90.

Selecting text or an image in the preview and choosing Edit now opens the editor scrolled to that fragment, with its source lines selected. ⌘E and the toolbar buttons do the same thing, so the reader does not have to know which entry point carries them there.

Two pre-existing bugs surfaced while testing this by hand and are fixed here too — both live in the paths this change makes people exercise.

The mapping already existed

comrak runs with options.render.sourcepos = true, so every rendered element already carries the source range it came from, and previewAnchor.ts is already the module that reads those ranges (for the tab's reading position and for split-view scroll sync). This is a third consumer of the same attribute, not a third mapping.

Two facts about data-sourcepos that decide the shape of the feature, both measured against the real renderer rather than assumed:

Inline nodes carry a range, not just blocks.

<p data-sourcepos="3:1-3:67">A paragraph with
  <strong data-sourcepos="3:18-3:30">bold text</strong> and an
  <img data-sourcepos="3:39-3:53" src="img.png" alt="alt" /> inline image.</p>

That is what makes "jump to the selected image" land on the image's own line instead of the whole paragraph.

Only the line numbers are usable. comrak parses the output of convert_markdown's preprocessing, and that pipeline is line-preserving, not column-preserving. For the raw line Math $a+b$ then ![alt](img.png) here. the image really starts at column 18, and comrak reports 3:24-3:38 — the math mask substitutes a token longer than $a+b$ and every column after it drifts. So the jump selects whole lines and nothing reads a column. A column-precise highlight would point at the wrong span in any document containing maths.

Extended, not added

• previewAnchor.ts gains findSourceLineRange (climb to the narrowest annotated ancestor) and mergeSourceLineRanges, on top of the parseSourceposLineRange it already had.
• Editor.revealHeader already revealed and selected a source line for the outline; its line branch now delegates to a shared revealSourceRange, so the outline and the context menu cannot drift apart.
• The existing menu.edit context-menu entry changed behaviour rather than gaining a sibling — no new i18n keys, so all 26 locales are already correct.

The highlight is Monaco's own selection: drawn in the theme's colour, no decoration, no CSS, no timer, and it clears itself on the reader's next click or keystroke — exactly when it stops being useful.

Two pre-existing bugs, fixed

1. Every jump landed short in a document with front matter.

renderMarkdownPreview hands comrak getMarkdownBodyWithoutFrontMatter(raw), so every data-sourcepos counts from the first line of the body, while the editor holds the whole file. Nothing in the attribute says which of the two it means, and the difference is invisible in a document without front matter — which was every fixture in the suite.

The outline has had this bug for as long as both have existed. Toc.svelte reads the same attribute and passes it to revealHeader untouched, so clicking a heading in a document with front matter has always landed short. It went unnoticed because revealHeader falls back to a text search when the line is null, and that path is correct. In samples/stress-test.md the error is 11 lines.

Both now go through toBufferRange. The task-checkbox write-back is not affected: it counts lines in the body as well, so both sides of that comparison share one numbering.

2. ⌘E did nothing in split view, and meant something different from "Edit".

They were two implementations of one intent. toggleEditView is now what the chord means, and the hotkey, the toolbar, the title bar and Monaco's own command all route through it:

reading             → editor, on the selected fragment
editor (alone)      → back to reading
split + selection   → jump to it; the layout does not move
split, no selection → nothing

The inert case is deliberate. Split view already grants what ⌘E asks for — the editor is on screen — and with no selection there is no fragment to travel to, so every remaining reading of the chord is a layout change nobody requested. A mistyped ⌘E would cost the reader the preview pane and a keystroke to get it back; doing nothing costs nothing. ⌘\ opens and closes the split and stays the only way.

formatShortcutKeymap.test.ts holds the two layers together and caught the divergence while this was being written.

3. The outline's jump highlight could not be dismissed. A temporary emphasis whose only removal path was a scroll event on the preview — and the jump's own smooth scroll is swallowed by clickLock, so unless the reader scrolled again it stayed until the document was re-rendered. A pointerdown in the preview and a keydown anywhere now end it too, both bypassing clickLock: that lock exists to ignore scrolling the app itself caused, and a deliberate action by the reader is never that.

Selection cases

range across several blocks	union of both ends; direction-independent
one end outside the document	the other end wins
caret / nothing selected	falls through to the element under the pointer
click on an image	the image's own line
right-click outside rendered content	null — "Edit" behaves exactly as before
already in split view	jumps, does not toggle edit mode off

Validation

• npm test 871 · npm run check 0 errors · cargo test 141
• Tested by hand on macOS across all four ⌘E states, the context menu, the toolbar and title-bar buttons, the outline jump, and the highlight dismissal.
• Rebased onto current master, which picked up eca4f1b (media players inherit the source range they replaced) — so right-clicking a video or audio embed now resolves too.

Not verified: no run on Windows or Linux. The two timing assumptions — that the $effect fires once editorPane is bound, and that pendingReveal survives the mount-time view-state restore — are asserted structurally and confirmed by hand on macOS, not observed under test.

🤖 Generated with Claude Code