Extension API: support custom read-only file previews

[jonatasperaza]

Summary

Add an Extension API that allows extensions to register custom read-only file previews for specific file types, rendered inside a normal Zed tab.

Problem

Zed extensions can currently add many editor capabilities, but they do not appear to have a supported way to register a visual file viewer/custom preview for non-text or structured files.

This makes it difficult for the community to build lightweight viewers for files such as:

• .xlsx spreadsheets
• .csv / .tsv grid previews
• .svg previews
• .pdf previews
• .drawio / .excalidraw diagrams
• other structured or binary project assets

For example, an .xlsx extension may only need to open a spreadsheet as a simple read-only grid inside a tab. It does not need full Excel compatibility, formulas, charts, macros, or advanced editing. Today, the realistic workaround is to convert the file to .csv, .tsv, or Markdown and open that generated file, which works but does not feel integrated.

Proposed solution

Introduce a small, safe Custom Preview API for extensions.

The first version could be intentionally limited to read-only previews. Extensions would be able to declare that they handle certain file extensions or glob patterns, and return a structured preview model that Zed renders using native UI components.

Conceptually:

impl zed::Extension for MyExtension {
    fn preview_providers(&self) -> Vec<zed::PreviewProvider> {
        vec![zed::PreviewProvider {
            id: "xlsx-preview",
            name: "XLSX Preview",
            file_patterns: vec!["*.xlsx"],
            mode: zed::PreviewMode::ReadOnly,
        }]
    }

    fn render_preview(
        &mut self,
        request: zed::PreviewRequest,
    ) -> zed::Result<zed::PreviewResponse> {
        // Read the file content and return a structured preview model.
    }
}

The response could initially support a small set of safe preview types, for example:

enum PreviewResponse {
    Markdown(String),
    Table(TableModel),
    Tree(TreeModel),
    PlainText(String),
}

For the spreadsheet case, a TableModel would be enough for a useful MVP:

• sheet tabs
• rows and columns
• vertical and horizontal scrolling
• virtualized rendering for large sheets
• copy selected cells as TSV
• read-only mode

Why not start with full WebView/custom editor support?

This is related to #21208, but the goal here is narrower.

A full WebView/custom editor API would be powerful, but it also introduces larger questions around security, performance, theming, keyboard handling, extension lifecycle, and consistency with Zed's UI.

A native read-only preview API would provide a smaller stepping stone that enables many practical use cases without immediately exposing arbitrary HTML/JS or a fully interactive editor surface.

Example use case: XLSX viewer

An extension could register itself for .xlsx files and render a simple grid preview:

1. User opens data.xlsx in Zed.
2. Zed detects that an extension provides a preview for .xlsx.
3. Zed opens a normal tab with a native preview view instead of a text buffer.
4. The extension parses the workbook and returns a table model.
5. The user can inspect sheets and copy values, but not edit the file yet.

This would already be useful for projects that keep small spreadsheets, exported reports, test fixtures, translation tables, or data files in the repository.

Possible MVP scope

A first implementation could avoid editing entirely:

• register preview providers by file extension/glob
• open extension-rendered read-only previews as workspace items/tabs
• support Markdown, PlainText, and/or Table preview responses
• theme previews using Zed's existing UI/theme system
• provide a fallback to opening the file as text if preview rendering fails

Future versions could consider:

• editable previews
• save-back support
• richer components
• custom actions/commands inside previews
• deeper GPUI integration
• WebView support if needed

Alternatives considered

Current workarounds include:

• converting .xlsx to .csv, .tsv, or Markdown and opening the generated file
• using an external spreadsheet app
• implementing support directly in Zed core for each file type

These workarounds either feel less integrated or do not scale well across many file formats. A small extension-based preview API would allow the community to implement file viewers without requiring Zed core to own every format-specific viewer.

Additional context

This proposal is intentionally scoped as a discussion starter. The main goal is to explore whether Zed would accept a smaller native preview API before considering a larger custom editor or WebView API.

[malikdraz]

This proposal would also help with a concrete .html preview workflow if the response model has a path for rendered local documents.

Use case: agent workflows often generate standalone local HTML artifacts for review: implementation matrices, PR triage boards, design critiques, status reports, and temporary working documents. Today the practical loop is "generate file in Zed, switch to an external browser, open/reload it, switch back." The useful Zed behavior would be "open preview to the side" for the .html file, with the source still editable.

For this proposal, I think there are two possible shapes:

1. Add a constrained Html/Document preview response type for local self-contained HTML, with an explicit sandbox policy.
2. Keep arbitrary HTML out of the generic extension API, but still make the file-preview provider model powerful enough that a first-party or trusted extension can own .html preview later.

The MVP requirements are modest:

• Provider registration by file pattern, including .html.
• Preview opens as a normal Zed tab/item and can open to the side.
• Preview is read-only.
• Refreshes on save or manual refresh.
• Rendering failure falls back cleanly to source view with an actionable error.
• No publishing/upload/share behavior; local preview only.

This is not asking for a full browser. It is a file-preview workflow for local artifacts, similar in spirit to Markdown/SVG/CSV preview but with HTML as the rendered document format.

[jonatasperaza]

Thanks, this is a good example of the same underlying gap.

I agree that local .html preview fits the broader “custom file preview” problem, especially for generated artifacts and agent workflows. The important distinction, in my opinion, is keeping the initial API scoped as a preview surface rather than a full browser or arbitrary app runtime.

Maybe the API could evolve in layers:

1. Safe native preview models first: Markdown, PlainText, Table, Tree.
2. Then a constrained Document / Html preview type for local, self-contained files, with explicit sandboxing and no network/publishing behavior by default.
3. Only later, if needed, a more powerful WebView/custom editor API.

For the MVP, I still think the most important part is the provider model itself:

• extensions can register preview providers by file pattern
• previews open as normal Zed tabs/items
• previews can open beside the source
• read-only by default
• refresh on save/manual refresh
• clean fallback to source view when rendering fails

That would cover .xlsx/table previews and also create a path for local .html previews without immediately requiring a full custom editor API.