[paulscan]

NativeTextViewWrapper.onLinkClick already covers [[Name]] clicks. A click on a regular [label](href) link falls through to AppKit's NSWorkspace.open with no seam for the embedder to intercept.

An embedder whose Markdown URLs mean something outside of the web has no way to route the click. Relative paths against a base directory, opaque ids, and custom schemes all require intercepting textView(_:clickedOnLink:at:) from outside the engine. The current workaround is to walk the view tree, find the underlying NSTextView, and install a proxy delegate that steals the method.

What's added

NativeTextViewWrapper.onURLLinkClick: ((URL, NSRange) -> Bool)? closes the gap. The closure receives the URL that the styler wrote onto the label's .link attribute and the label's range in the current display text. The return value decides who handles the click. Returning true consumes it and skips AppKit's default handler. Returning false (or leaving the hook nil) falls back to the previous behavior. The closure runs synchronously because the delegate's return value has to travel back into AppKit on the same call.

updateNSView refreshes the hook alongside the other coordinator callbacks, so an embedder can swap it between updates without remounting.

Wiki links still route through onLinkClick. The URL hook only fires on [label](href).

Tests

Tests/MarkdownEngineTests/URLLinkClickCallbackTests.swift covers four behaviors:

• Returning true consumes the click and reports the URL plus the
  label range.
• Returning false hands the click back to AppKit.
• An unset hook preserves the previous behavior.
• A wiki-link click bypasses the URL hook and still routes through
  onLinkClick.

swift build and swift test are green.

[yvos]

Hi @paulscan, I ran into the same problem from a different angle: relative .md paths that my app resolves to its own records. I've opened #190 proposing a single "host decides" activation seam that covers this PR and #165 together. It passes the destination as written, the source range and the modifiers, and lets the host return whether it handled the click. Would that shape work for your case? If so, I'd be glad to combine efforts and credit you in the PR.

[paulscan]

Hi @paulscan, I ran into the same problem from a different angle: relative .md paths that my app resolves to its own records. I've opened #190 proposing a single "host decides" activation seam that covers this PR and #165 together. It passes the destination as written, the source range and the modifiers, and lets the host return whether it handled the click. Would that shape work for your case? If so, I'd be glad to combine efforts and credit you in the PR.

@yvos - yep, your approach is better than mine. I'll close #165 and #166 once your PR is open. Passing the destination as written removes the need for #165, and it fixes angle-bracket and titled destinations, which reach #166's hook mangled today. Running the edit zone before the callback is good.

One change I'd ask for: markdownLinkDestination stops at the first whitespace, so [x](my file.md) yields my and [x](../Foo Bar/) yields ../Foo. The engine still renders both as links, and they route with the full text today. Please strip a title only when what follows the whitespace is a quoted or parenthesized title, and otherwise return the whole trimmed destination, with a test for that case.

Minor, take it or leave it: the autolink path runs NSDataDetector over the whole document on each click, and limiting it to the clicked paragraph would be more efficient.

[paulscan]

Superseded by #192

[yvos]

Thanks @paulscan! Both points are in #192 now: destinations keep interior spaces and only a quoted or parenthesized title is stripped (with tests for my file.md and ../Foo Bar/), and the autolink detector only scans the clicked paragraph. I've credited you in the PR and marked it ready for review.