Files
zed/docs
Rusty Raven 3a904a7722 docs: Describe how preview tabs actually behave (#63875)
# Objective

- Fixes #33819
- The `preview_tabs` documentation says preview tabs "close
automatically when you switch to another file unless you explicitly pin
them". They do not close. Moving to another file leaves the preview tab
open — either still as the preview tab, or converted into a regular one.
Four people ran into this on the issue over the past year.
- The same section then lists the ways to turn a preview tab into a
regular tab, and two of them are missing, including the pinning that the
sentence above uses as its counter-example.

## Solution

Two corrections to the `Preview tabs` section of
`docs/src/reference/all-settings.md`. No behaviour was touched.

**The description.** A pane holds a single `preview_item_id`, so there
is at most one preview tab at a time. What happens to it when you move
to another file depends on the path:

- Opening a not-yet-open file in preview mode from the project panel or
file finder goes through `Pane::open_item`, which calls
`close_current_preview_item` — that really does close the old tab
(`remove_item`) and hands back its index, and the new file is inserted
there.
- Code navigation with the default
`enable_keep_preview_on_code_navigation: false` instead calls
`unpreview_item_if_preview` on the old item *before*
`replace_preview_item_id`, so the previous file stays open as a regular
tab.

A third path, the file finder with the default
`enable_preview_from_file_finder: false`, opens the new file as a
regular tab and leaves the existing preview tab alone entirely.

Rather than spell out every path in a settings description — the
`enable_preview_*` settings immediately below already cover them — the
new wording sticks to what holds in all of them: a pane keeps at most
one preview tab and opening another file in preview mode takes over that
slot, and switching to a file that is already open does not close the
preview tab. That second half is the case the issue actually reports.

**The list.** Two more ways to convert a preview tab into a regular tab:

- Pinning it — `change_tab_pin_state` calls `unpreview_item_if_preview`
on the `Pin` branch.
- `pane::TogglePreviewTab` — the action dedicated to exactly this,
registered whenever preview tabs are enabled.

## Testing

- Built a debug Zed and walked through the steps from the issue on a
scratch project of `a.txt` / `b.txt` / `c.txt`: with `a.txt` open as a
regular tab and `b.txt` opened as a preview tab, clicking back to
`a.txt` leaves the `b.txt` preview tab open, which is what the current
wording says should not happen. Single-clicking `c.txt` takes over the
same slot rather than adding a second preview tab, and pinning the
preview tab drops the italics.
- Ran the docs steps from `run_tests.yml` locally: `zed
--dump-all-actions > crates/docs_preprocessor/actions.json`, then
`mdbook build ./docs` on mdbook 0.4.37 to match CI. Exit 0 with no
preprocessor errors, and both new `{#action ...}` references resolve —
the rendered page reads "pane: toggle pin tab" and "pane: toggle preview
tab" in the same style as the existing "project panel: open permanent".
- `cargo test -p workspace --lib` — 272 passed, 0 failed, including
`test_close_other_items_unpreviews_active_item`,
`test_reopening_closed_item_after_unpreview`, and the proptest that
opens random paths with random `allow_preview` and asserts a pane never
holds more than one preview item.

## Notes for review

- Several people on the issue would rather the *behaviour* changed, so
that preview tabs close on any tab switch the way the docs currently
describe. I left that alone deliberately: the issue is typed `Docs`, so
this PR only makes the prose match the implementation. Happy to open a
discussion separately if it is worth pursuing.
- Saving a file also unpreviews it (`Pane::save_item`), but I left it
off the list as redundant — you have to edit a file before you can save
it, and editing is already there. Say the word if you would rather it
were explicit.
- The comment on `preview_tabs.enabled` in
`assets/settings/default.json` words this as "close automatically when
you open another preview tab". That is right for the project-panel path
and carries the same code-navigation caveat as above; I left it alone to
keep this diff to one file, and am happy to align it in a follow-up.

## Self-Review Checklist:

- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments — N/A
- [x] The content adheres to Zed's UI standards — N/A, docs only
- [x] Tests cover the new/changed behavior — N/A, no behaviour change;
the docs build is verified locally
- [x] Performance impact has been considered and is acceptable — N/A

---

Release Notes:

- N/A
2026-09-08 12:24:20 +00:00
..
2026-07-23 05:26:09 +00:00
2026-05-07 06:55:11 +00:00

Zed Docs

Welcome to Zed's documentation.

This is built on push to main and published automatically to https://zed.dev/docs.

To preview the docs locally you will need to install mdBook (cargo install mdbook@0.4.40), generate the action metadata, and then serve:

script/generate-action-metadata
mdbook serve docs

The first command dumps an action manifest to crates/docs_preprocessor/actions.json. Without it, the preprocessor cannot validate keybinding and action references in the docs and will report errors. You only need to re-run it when actions change.

If you use Nix, the development shell provides a pinned mdbook (0.4.40) and a prebuilt docs preprocessor, so you can build the docs without installing anything or compiling the preprocessor on every run:

nix develop -c mdbook build docs

(When actions.json has not been generated, action/keybinding validation is skipped with a warning rather than failing the build.)

It's important to note the version number above. For an unknown reason, as of 2025-04-23, running 0.4.48 will cause odd URL behavior that breaks things.

Before committing, verify that the docs are formatted in the way Prettier expects with:

cd docs && pnpm dlx prettier@3.5.0 . --write && cd ..

Preprocessor

We have a custom mdBook preprocessor for interfacing with our crates (crates/docs_preprocessor).

If for some reason you need to bypass the docs preprocessor, you can comment out [preprocessor.zed-docs-preprocessor] from the book.toml.

Images and videos

To add images or videos to the docs, upload them to another location (e.g., zed.dev, GitHub's asset storage) and then link out to them from the docs.

Putting binary assets such as images in the Git repository will bloat the repository size over time.

Internal notes:

  • We have a Cloudflare router called docs-proxy that intercepts requests to zed.dev/docs and forwards them to the "docs" Cloudflare Pages project.
  • The CI uploads a new version to the Cloudflare Pages project from .github/workflows/deploy_docs.yml on every push to main.

Table of Contents

The table of contents files (theme/page-toc.js and theme/page-doc.css) were initially generated by mdbook-pagetoc.

Since all this preprocessor does is generate the static assets, we don't need to keep it around once they have been generated.

Referencing Keybindings and Actions

When referencing keybindings or actions, use the following formats:

Keybindings

{#kb scope::Action} - e.g., {#kb zed::OpenSettings}.

This will output a code element like: <code>Cmd + , | Ctrl + ,</code>. We then use a client-side plugin to show the actual keybinding based on the user's platform.

By using the action name, we can ensure that the keybinding is always up-to-date rather than hardcoding the keybinding.

Keymap Overlays

{#kb:keymap_name scope::Action} - e.g., {#kb:jetbrains editor::GoToDefinition}.

This resolves the keybinding from a keymap overlay (e.g., JetBrains) first, falling back to the default keymap if the overlay doesn't define a binding for that action. This is useful for sections where the documentation expects a special base keymap to be configured.

Supported overlays: jetbrains.

Actions

{#action scope::Action} - e.g., {#action zed::OpenSettings}.

This will render a human-readable version of the action name, e.g., "zed: open settings", and will allow us to implement things like additional context on hover, etc.

Creating New Templates

Templates are functions that modify the source of the docs pages (usually with a regex match and replace). You can see how the actions and keybindings are templated in crates/docs_preprocessor/src/main.rs for reference on how to create new templates.

We pre-bundle the c15t package because the docs pipeline does not include a JS bundler. If you need to update c15t and rebuild the bundle, use:

mkdir c15t-bundle && cd c15t-bundle
npm init -y
npm install c15t@<version> esbuild
echo "import { getOrCreateConsentRuntime } from 'c15t'; window.c15t = { getOrCreateConsentRuntime };" > entry.js
npx esbuild entry.js --bundle --format=iife --minify --outfile=c15t@<version>.js
cp c15t@<version>.js ../theme/c15t@<version>.js
cd .. && rm -rf c15t-bundle

Replace <version> with the new version of c15t you are installing. Then update book.toml to reference the new bundle filename.

References

  • Template Trait: crates/docs_preprocessor/src/templates.rs
  • Example template: crates/docs_preprocessor/src/templates/keybinding.rs
  • Client-side plugins: docs/theme/plugins.js

Postprocessor

A postprocessor is implemented as a sub-command of docs_preprocessor that wraps the built-in HTML renderer and applies post-processing to the HTML files, to add support for page-specific title and meta tag description values.

An example of the syntax can be found in git.md, as well as below:

---
title: Some more detailed title for this page
description: A page-specific description
---

# Editor

The above code will be transformed into (with non-relevant tags removed):

<head>
  <title>Editor | Some more detailed title for this page</title>
  <meta name="description" contents="A page-specific description" />
</head>
<body>
  <h1>Editor</h1>
</body>

If no front matter is provided, or if one or both keys aren't provided, the title and description will be set based on the default-title and default-description keys in book.toml respectively.

Implementation details

Unfortunately, mdBook does not support post-processing like it does pre-processing, and only supports defining one description to put in the meta tag per book rather than per file. So in order to apply post-processing (necessary to modify the HTML head tags) the global book description is set to a marker value #description# and the HTML renderer is replaced with a sub-command of docs_preprocessor that wraps the built-in HTML renderer and applies post-processing to the HTML files, replacing the marker value and the <title>(.*)</title> with the contents of the front matter if there is one.

Known limitations

The front matter parsing is extremely simple, which avoids needing to take on an additional dependency, or implement full YAML parsing.

  • Double quotes and multi-line values are not supported, i.e. Keys and values must be entirely on the same line, with no double quotes around the value.

The following will not work:

---
title: Some
  Multi-line
  Title
---

neither this:

---
title: "Some title"
---
  • The front matter must be at the top of the file, with only white-space preceding it.
  • The contents of the title and description will not be HTML escaped. They should be simple ASCII text with no unicode or emoji characters.