Allow extensions to control how links are opened

[bglgwyng]

What are you proposing?

Add an extension API for controlling how matching URIs are opened.

For example, an extension could register that certain file:// links should open with the system default application rather than inside Zed.

Matching could use:

• URI scheme
• file extension
• path pattern
• language or language server

The extension-provided behavior could remain user-overridable.

Why does this matter?

Haskell Language Server can include local Haddock documentation links in hover Markdown:

file:///nix/store/.../share/doc/.../html/index.html

Zed opens these as HTML source in an editor pane. The intended result is rendered documentation in a browser.

The Haskell extension has enough context to recognize these links, but currently cannot change their handling.

A normal Markdown link also cannot specify LSP’s external: true; that option only exists on a separate window/showDocument request.

Examples or context

Current flow:

1. HLS returns a Haddock link in hover Markdown.
2. Zed renders the link.
3. Clicking it opens the HTML file as source.
4. Opening the same URI externally works as intended.

Related requests:

• add a web view into Zed for website previews #10533 — embedded WebView
• Webview via Extensions #21208 — extension WebView support
• preview button in md/html/latex and svg files #26077 — HTML preview
• Extension API: support custom read-only file previews #59597 — extension-provided previews

This proposal does not add a WebView. It provides a smaller workaround for some of the same use cases by delegating resources to external applications.

Possible approach

Allow extensions to register declarative URI rules:

scheme: file
extension: html
path: */share/doc/*/html/*
action: open_externally

Possible actions:

open_in_zed
open_externally
use_default

A narrower first version supporting matched file:// URIs and open_externally would be enough for this use case.