e76b485de3
Closes: - #12338 - #40202 1. Adds two new settings which allow customizing the set of regexes used to identify path hyperlinks in terminal 1. Fixes path hyperlinks for paths containing unicode emoji and punctuation, for example, `mojo.🔥` 1. Fixes path hyperlinks for Windows verbatim paths, for example, `\\?\C:\Over\here.rs`. 1. Improves path hyperlink performance, especially for terminals with a lot of content 1. Replaces existing custom hard-coded default path hyperlink parsing logic with a set of customizable default regexes ## New settings (from default.json) ### terminal.path_hyperlink_regexes Regexes used to identify paths for hyperlink navigation. Supports optional named capture groups `path`, `line`, `column`, and `link`. If none of these are present, the entire match is the hyperlink target. If `path` is present, it is the hyperlink target, along with `line` and `column` if present. `link` may be used to customize what text in terminal is part of the hyperlink. If `link` is not present, the text of the entire match is used. If `line` and `column` are not present, the default built-in line and column suffix processing is used which parses `line:column` and `(line,column)` variants. The default value handles Python diagnostics and common path, line, column syntaxes. This can be extended or replaced to handle specific scenarios. For example, to enable support for hyperlinking paths which contain spaces in rust output, ``` [ "\\s+(-->|:::|at) (?<link>(?<path>.+?))(:$|$)", "\\s+(Compiling|Checking|Documenting) [^(]+\\((?<link>(?<path>.+))\\)" ], ``` could be used. Processing stops at the first regex with a match, even if no link is produced which is the case when the cursor is not over the hyperlinked text. For best performance it is recommended to order regexes from most common to least common. For readability and documentation, each regex may be an array of strings which are collected into one multi-line regex string for use in terminal path hyperlink detection. ### terminal.path_hyperlink_timeout_ms Timeout for hover and Cmd-click path hyperlink discovery in milliseconds. Specifying a timeout of `0` will disable path hyperlinking in terminal. ## Performance This PR fixes terminal to only search the hovered line for hyperlinks and adds a benchmark. Before this fix, hyperlink detection grows linearly with terminal content, with this fix it is proportional only to the hovered line. The gains come from replacing `visible_regex_match_iter`, which searched all visible lines, with code that only searches the line hovered on (including if the line is wrapped). Local benchmark timings (terminal with 500 lines of content): ||main|this PR|Δ| |-|-|-:|-| | cargo_hyperlink_benchmark | 1.4 ms | 13 µs | -99.0% | | rust_hyperlink_benchmark | 1.2 ms | 11 µs | -99.1% | | ls_hyperlink_benchmark | 1.3 ms | 7 µs | -99.5% | Release Notes: - terminal: New settings to allow customizing the set of regexes used to identify path hyperlinks in terminal - terminal: Fixed terminal path hyperlinks for paths containing unicode punctuation and emoji, e.g. mojo.🔥 - terminal: Fixed path hyperlinks for Windows verbatim paths, for example, `\\?\C:\Over\here.rs` - terminal: Improved terminal hyperlink performance, especially for terminals with a lot of content visible
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) and then run:
mdbook serve docs
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-proxythat intercepts requests tozed.dev/docsand forwards them to the "docs" Cloudflare Pages project. - CI uploads a new version to the Pages project from
.github/workflows/deploy_docs.ymlon every push tomain.
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.
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 just functions that modify the source of the docs pages (usually with a regex match & 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.
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 builtin html renderer and applies post-processing to the html files, to add support for page-specific title and meta 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 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 builtin 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
---
And neither will:
---
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