Skip to content

馃悰 Use the target's title for [](doc.md#label) links - #1207

Open
dstrodtman wants to merge 1 commit into
executablebooks:masterfrom
dstrodtman:djs-261001-explicit-target-link-text
Open

dstrodtman wants to merge 1 commit into
executablebooks:masterfrom
dstrodtman:djs-261001-explicit-target-link-text

Conversation

@dstrodtman

Copy link
Copy Markdown

A path link with empty text to an explicit target in another document resolves to the right anchor but renders no link text:

<!-- other.md -->
(my-label)=
## Labelled heading

<!-- index.md -->
[](other.md#my-label)

On master this renders <a href="other.html#my-label"><span class="std std-ref"></span></a>. Since #1158, which fixed the false-positive myst.xref_missing warning reported in #1151, the link no longer warns, so a build with -W passes with an invisible link. On v5.1.0 the same link warned, so the empty text was visible as a failing build rather than silent.

Cause

resolve_myst_ref_doc sets implicit_text only when the fragment matches a heading slug. The two later branches added in #1158, a section's docutils id and a std-domain label referenced by id or name, set targetid but leave implicit_text empty.

Fix

  • The section-id branch takes the title already stored alongside the id in myst_slugs.
  • _std_label_id_in_doc becomes _std_label_in_doc and returns the label's section title with its id. Named labels carry a title. Anonymous labels don't.
  • When there's still no title, as for an anonymous label on a paragraph or an unresolved id, the link shows the target id as a literal instead of rendering empty. That matches the existing fallback for unresolved [](#target) links in MystReferenceResolver.run.

Explicit link text is unchanged.

Link master This PR
[](other.md#my-label), label on a heading empty Labelled heading
[](other.md#colon:label), label by name empty Colon heading
[](other.md#colon-label), label by id empty Colon heading
[](other.md#para-label), anonymous label empty para-label
[custom](other.md#my-label) custom custom

Tests

  • New test_doc_with_target_link_text covers the rows above across two documents with myst_heading_anchors on. Four of its five cases fail on master. The explicit-text case passes on both, as a guard.
  • The existing doc_with_target_id and doc_with_target_name fixtures recorded the empty <inline>. They're regenerated and now contain Title.
  • Full suite: 1242 passed, 3 failed. The same 3 fail on unpatched master in the same environment: test_cmdline[40-linkify], test_extended_syntaxes, and test_extended_syntaxes_text.
  • pre-commit run (ruff, ruff-format, mypy) passes on the changed files.

I didn't add a CHANGELOG.md entry because there's no unreleased section since v5.1.0. Happy to add one if you'd like.

Found while evaluating path links with hand-assigned anchors, [](/page.md#label), as a cross-reference convention for a large Sphinx project mixing MyST and rST.

馃 Generated with Claude Code

A path link with empty text to an explicit target in another document,
such as `[](other.md#my-label)` where `other.md` has `(my-label)=` above
a heading, resolved to the right anchor but rendered no link text. Since
executablebooks#1158 the link no longer warns, so the build passed with an invisible
link.

`resolve_myst_ref_doc` set the implicit text only on the heading-slug
path. The section-id and std-label paths now carry the section title
too. When no title exists, as for an anonymous label on a paragraph,
the link shows the target id instead of rendering empty, matching the
fallback for unresolved `[](#target)` links.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@dstrodtman

Copy link
Copy Markdown
Author

@chrisjsewell PR here is coded by Claude but reviewed by a human. This behavior allows Sphinx MyST to read closer to standard markdown while auto-parsing section/page headers. Motivation is maintainability and making sure raw .md files are friendly to agents.

Please let me know what else I can do to push this forward. Currently in process of converting all OSS Ray docs to MyST, and this would keep me from rigging up my own custom solution there.

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