Summary

Follow-up to #907 / #909 (shipped in v0.34.0 — thank you!). --chips fixed the smart-chip classes (person, date, richLink), but the closely related case of hyperlinks on ordinary text runs is still dropped in every output mode: plain, --plain, --json, and --chips. A text run whose textStyle.link.url is set renders as bare anchor text with the target URL silently lost.

For agent/scripting use this is the same failure shape as #907: the output looks complete, but a doc that says Ticket-123 (linked to https://tracker.example.com/browse/Ticket-123) reads back as just Ticket-123 — the reader has no idea a link was there, and no way to recover the URL short of re-fetching with --raw.

Repro

Any doc with hyperlinked text, e.g. a paragraph or table cell containing the text Ticket-123 linked to an external URL (Insert → Link in the Docs UI):

gog docs cat <docId>            # Ticket-123        (URL lost)
gog docs cat <docId> --plain    # Ticket-123        (URL lost)
gog docs cat <docId> --chips    # Ticket-123        (URL lost)
gog docs cat <docId> --json     # text only, no link metadata
gog docs cat <docId> --raw      # textRun.textStyle.link.url present

Verified on v0.34.0 (83637875).

Root cause

Both text extractors in internal/cmd/docs_read.go write TextRun.Content verbatim and never consult TextRun.TextStyle.Link:

• appendDocsElementText (internal/cmd/docs_read.go:375) — plain path: skips every non-TextRun element and appends p.TextRun.Content only.
• appendDocsElementRenderedText (internal/cmd/docs_read.go:417) — the Support Docs smart chips in cat output #909 chips path: the p.TextRun != nil branch appends p.TextRun.Content and continues before any link inspection; only non-TextRun elements reach renderDocsSmartChip (internal/cmd/docs_read.go:471).

There is no reference to TextStyle.Link anywhere in the read path.

Suggested behavior

Mirroring the #909 approach (opt-in, default text output unchanged):

• Under --chips (or a sibling --links flag if you'd rather keep chips scoped): render linked runs as Markdown, [Ticket-123](https://tracker.example.com/browse/Ticket-123), when textStyle.link.url is set and differs from the visible text. Runs whose visible text already equals the URL can stay as-is to avoid [url](url) noise.
• In --json: include the link target alongside the text (either per-run metadata or in the structured sidecar introduced by Support Docs smart chips in cat output #909).

headingId / bookmark-style internal links (textStyle.link.headingId) could reasonably be out of scope; the external url case is the one that loses information irrecoverably.

Workarounds today

• gog docs cat --raw and walking textRun.textStyle.link.url client-side.
• gog docs export --format md preserves hyperlinks (server-side Drive export), but exports the whole document to a file rather than streaming a tab to stdout, so it's not a drop-in for cat in pipelines.