Files
zed/docs
František GažoandKirill Bulatov f05265c624 outline_panel: Show deleted files inside the file tree (#63570)
# Objective

In a branch diff — or any multi-buffer containing deleted files —
deleted files render as flat "external file" rows above the outline
panel's tree, instead of at the path they used to occupy. They lose all
directory context and appear as a bare list of filenames detached from
the tree, which is confusing precisely when you are trying to review
what a branch changed.

The cause is that `File::project_entry_id` returns `None` for
`DiskState::Deleted`, while the outline panel's tree is keyed end-to-end
by `ProjectEntryId` — depth map, collapse state, children counts. A
deleted buffer therefore falls through to the external-file path in
`update_fs_entries`, even though its `File` still carries a perfectly
good worktree and path.

## Solution

Synthesize the missing entries at the point of classification and let
the existing pipeline run unchanged.

- Entries are synthesized for the deleted file **and** for any ancestor
directories that no longer exist, so a wholly-deleted folder still
appears nested at its old location. An ancestor is only taken from the
worktree if it is a directory; a path that is a file now but was a
directory when the deleted file existed is synthesized too, and sorted
after the file so the nesting pass keeps the directory on its stack.
- Ids come from a per-panel registry that hands them out sequentially
downward from just below `ProjectEntryId::MAX`, keyed by path and kind.
Real ids count up from zero, so the ranges cannot meet; sequential
allocation means two entries can never share an id (the entry maps are
keyed by id alone, so a collision would drop a row); and the registry is
kept across updates, so collapse state on synthesized rows survives.
- Whether a buffer with no worktree entry is a deletion is decided by
its `DiskState`: `Deleted` always, `Present` never, `Historic` by its
own flag, and `New` only when git status reports a deletion or the
excerpt's diff has a base text. The last case is a file deleted in a
commit on the branch: it is absent from disk, the working-tree status
says nothing about it, and `GitStore::display_status` only reflects
branch-diff statuses when `git.diff_base` is `default_branch`. A
deletion has a base version; a path that never existed has none. A
scan-excluded file, which also has no entry, is `Present` and stays an
external row.
- Auto-fold stops where deletion state changes, so a surviving `parent/`
is never struck through together with its deleted child, and
`select_parent` treats a folded row as a valid parent of the folded row
beneath it.
- Auto-reveal resolves a deleted row's ancestors from the panel's own
`fs_entries` rather than re-querying the worktree, and only real
directories are ever passed to `Project::expand_entry` (a synthesized id
would go out as an `ExpandProjectEntry` a remote host rejects). Opening
a deleted row resolves its excerpt from the buffer id, since
`path_for_entry` cannot resolve a synthesized entry.

Deleted rows are struck through by a `line_through` on the row's label
wrapper. `HighlightedLabel` builds its text runs from
`window.text_style()`, so an ancestor's style reaches them even though
`LabelLike`'s own `strikethrough()` does not; nothing outside
`crates/outline_panel` changes. Colour is deliberately left to git
status, matching deleted editor tabs — a committed deletion leaves the
working tree clean, so strikethrough is the only signal in a branch
diff.

## Testing

Thirteen new tests, each asserting the rendered tree through
`display_entries`, which now prints external files and marks deleted
rows:

- deleted file nests under its surviving parent; deleted file inside a
wholly-deleted directory gets synthesized ancestors at the right depth
- a file absent from disk and from git status nests when its excerpt
carries a base text, while a buffer on a path that never existed stays
an external file, unmarked
- a modified, scan-excluded tracked file stays an external file,
unmarked
- same-path file + synthesized directory: nesting and auto-reveal both
pick the directory
- auto-fold stops at the deletion boundary; `select_parent` climbs from
a folded deleted chain to the folded parent above it
- opening a deleted row scrolls the editor to its excerpt
- auto-reveal expands the ancestors of a deleted file and ignores an
external file on a nonexistent path
- buffers with no `File` still become `ExternalFile`
- synthetic ids are distinct per path and kind, and stable

`./script/clippy`, `cargo fmt --all -- --check`, `cargo test -p
outline_panel` (33) are green. Tested manually on macOS against a
fixture branch with a committed file deletion, a wholly-deleted
directory under a surviving empty one, a directory replaced by a
same-path file, an uncommitted deletion, a scan-excluded modified file,
and a modified and an added file.

## Suggested .rules additions

- `GitStore::display_status` only reflects branch-diff statuses when
`git.diff_base` is `default_branch`; the branch diff view can be open
while the setting is `head`. Do not use it to detect committed deletions
— a commit-deleted file's buffer is `DiskState::New`; check the
excerpt's diff for a base text instead.
- Outline panel: a directory with mixed children is marked unfolded
while `fs_entries` is built, so an auto-fold chain only forms through
single-subdirectory links. Tests for folding must use that shape.
- `HighlightedLabel` builds its runs from `window.text_style()` at
render time, so `LabelLike` modifiers such as `strikethrough()` and
`italic()` are no-ops on it; put the style on an ancestor element
instead.

## Self-Review Checklist:

- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable

## Showcase

The same branch diff, which deletes `src/utils/format.rs` (its directory
survives) and the whole of `src/legacy/` (including a nested
`internal/`), alongside a modified and an added file.

| Before | After |
| --- | --- |
| <img
src="https://github.com/user-attachments/assets/bf503759-77a7-4f31-80bb-a85936de0b8a"
width="300"> | <img
src="https://github.com/user-attachments/assets/c558b94b-4ca5-447f-a049-a3ab280c679a"
width="300"> |
| Deleted files sit above the project root as bare filenames, detached
from the tree | Each is nested at its original path, with `legacy/` and
`internal/` synthesized since they no longer exist on disk |

Note that `utils/` renders normally while `legacy/` and `internal/` are
struck through: the marking is per-entry, not applied to every ancestor
on a deleted file's path.

---

Release Notes:

- Fixed deleted files appearing outside the file tree in the outline
panel when viewing a diff

---------

Co-authored-by: Kirill Bulatov <kirill@zed.dev>
2026-09-12 19:03:48 +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.