Link resolution reported byte offsets relative to a section's raw
content region (headline end), but the GUI renders /body, which strips
the planning line, property drawer, and surrounding blank lines. An
offset into raw content therefore did not line up with the body the
GUI shows, so scrolling to a link target landed in the wrong place.
Server:
- Extract section_body_text() as a shared helper so section_body() and
resolve_target() derive offsets from the exact same rendered string.
- Rewrite the dedicated-target, named-element, and plain-text branches
of resolve_target() to search section_body_text() and report a
/body-relative offset.
- Replace the affiliated-keyword lookup with find_name_line(), a text
scan over /body: the parser only attaches #+NAME to some element
kinds (not tables), so scanning the rendered body is more reliable.
- Drop the now-unused section_content() helper.
- Update tests with concrete /body-relative offset assertions
(<<target>> at 22, blank-stripped at 5, #+NAME at 44).
GUI:
- sectionRevealed gains a bodyOffset argument, threaded from the
resolve response through revealSection into the QML Connections.
- OutlineView positions the row at Beginning when the match lies inside
the body (offset > 0) so the body is visible, else just Contain.
Scroll granularity is section-top: the row is scrolled into view, not
the exact character. True char-precise scrolling needs a single
addressable body text widget; /body is currently segmented into
text/code/table/list parts. Deferred.
66a1ca11b5