2c0d6c067d
This PR introduces the `project_panel.scrollbar.horizontal_scroll` setting to allow users to toggle the horizontal scroll bar in the project panel. This was Zed's design before PR #18513, and the default behavior of VSCode (`workbench.list.horizontalScrolling`). https://github.com/user-attachments/assets/f633f4e4-a585-4494-8f48-df77c6aca418 ## Rationale Zed's design used to be the same as the default behavior of VSCode. I.e., no horizontal scrolling, and the view is always snapped to the left, with long file names clipped of. If you want to see the content that is out-of-frame, you'll need to drag the handle and expand the project panel. This could be problematic, especially for large repos with multiple levels of nested directories, as pointed out by issues #5550 and #7001. <img width="1398" height="992" alt="image" src="https://github.com/user-attachments/assets/d86563f2-0f06-4e9e-818c-155ac45f0f56" />\ *VSCode's default setup, for reference.* Then came PR #18513, which added horizontal scroll and addressed this pain point, but users didn't have a choice. They're stuck with horizontal scrolling always turned on. I, for instance, personally prefer the old, VSCode-default behavior, for most projects I open are small and don't need horizontal scrolling in the project panel. With horizontal scrolling always turned on, I find it annoying to have my project panel view accidentally scrolled to the middle, and I'll have to grab my mouse and scroll it back. It's also visually redundant. Thus, why not add an option like VSCode's `workbench.list.horizontalScrolling` and let users choose? I'd love to be able to, say, set a per-project override for the projects that need horizontal scrolling, while having it disabled by default. ## Extra Notes - I was originally thinking about using `ScrollbarAxes` from `src/editor_settings.rs` and make the option `project_panel.scrollbar.axes.horizontal` similar to the global editor scrollbar settings, but this option is specific to the project panel and it doesn't quite make sense to allow disabling vertical scrolling on the project panel, so I added a standalone option for it instead, similar to VSCode's `workbench.list.horizontalScrolling`. - I went the conservative route and set horizontal scrolling to enabled (current behavior) by default. Imo it might make more sense to disable it by default instead, similar to VSCode, but I'll leave this for the Zed team to decide. - I named it `horizontal_scroll` instead of `horizontal_scrolling` to be consistent with the adjacent setting `sticky_scroll`. - As for tests, I don't see tests for the scrollbar, so I didn't add any. I'd be glad to update the PR if anything is not inline with the project's requirements or conventions. --- Release Notes: - Added `project_panel.scrollbar.horizontal_scroll` setting to allow toggling horizontal scrolling in the project panel Signed-off-by: k4yt3x <i@k4yt3x.com> |
||
|---|---|---|
| .. | ||
| .conventions | ||
| .doc-examples | ||
| src | ||
| theme | ||
| .gitignore | ||
| .prettierignore | ||
| .prettierrc | ||
| .rules | ||
| AGENTS.md | ||
| book.toml | ||
| README.md | ||
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. - The CI uploads a new version to the Cloudflare 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 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.
Consent Banner
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
titleanddescriptionwill not be HTML escaped. They should be simple ASCII text with no unicode or emoji characters.