oak-team/oak-gpui
3
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Remove docs & legal

Browse Source
This commit is contained in:
iamnbutler
2025-12-12 14:22:33 -05:00
parent ab50ddd68c
commit 0dc3e6b25b
173 changed files with 0 additions and 24466 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/.gitignore
-1
View File
@@ -1 +0,0 @@
book/
docs/.prettierignore
-2
View File
@@ -1,2 +0,0 @@
# Handlebars partials are not supported by Prettier.
*.hbs
docs/.prettierrc
-3
View File
@@ -1,3 +0,0 @@
{
"printWidth": 80
}
docs/README.md
-132
View File
@@ -1,132 +0,0 @@
# Zed Docs
Welcome to Zed's documentation.
This is built on push to `main` and published automatically to [https://zed.dev/docs](https://zed.dev/docs).
To preview the docs locally you will need to install [mdBook](https://rust-lang.github.io/mdBook/) (`cargo install mdbook@0.4.40`) and then run:
```sh
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-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`](https://crates.io/crates/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.
### 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:
```md
---
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):
```html
<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:
```md
---
title: Some
Multi-line
Title
---
```
neither this:
```md
---
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.
docs/book.toml
-102
View File
@@ -1,102 +0,0 @@
[book]
authors = ["The Zed Team"]
language = "en"
multilingual = false
src = "src"
title = "Zed"
site-url = "/docs/"
[build]
extra-watch-dirs = ["../crates/docs_preprocessor"]
# zed-html is a "custom" renderer that just wraps the
# builtin mdbook html renderer, and applies post-processing
# as post-processing is not possible with mdbook in the same way
# pre-processing is
# The config is passed directly to the html renderer, so all config
# options that apply to html apply to zed-html
[output.zed-html]
command = "cargo run -p docs_preprocessor -- postprocess"
# Set here instead of above as we only use it replace the `#description#` we set in the template
# when no front-matter is provided value
default-description = "Learn how to use and customize Zed, the fast, collaborative code editor. Official docs on features, configuration, AI tools, and workflows."
default-title = "Zed Code Editor Documentation"
no-section-label = true
preferred-dark-theme = "dark"
additional-css = ["theme/page-toc.css", "theme/plugins.css", "theme/highlight.css"]
additional-js = ["theme/page-toc.js", "theme/plugins.js"]
[output.zed-html.print]
enable = false
# Redirects for `/docs` pages.
#
# All of the source URLs are interpreted relative to mdBook, so they must:
# 1. Not start with `/docs`
# 2. End in `.html`
#
# The destination URLs are interpreted relative to `https://zed.dev`.
# - Redirects to other docs pages should end in `.html`
# - You can link to pages on the Zed site by omitting the `/docs` in front of it.
[output.zed-html.redirect]
# AI
"/ai.html" = "/docs/ai/overview.html"
"/assistant-panel.html" = "/docs/ai/agent-panel.html"
"/assistant.html" = "/docs/assistant/assistant.html"
"/assistant/assistant-panel.html" = "/docs/ai/agent-panel.html"
"/assistant/assistant.html" = "/docs/ai/overview.html"
"/assistant/commands.html" = "/docs/ai/text-threads.html"
"/assistant/configuration.html" = "/docs/ai/configuration.html"
"/assistant/context-servers.html" = "/docs/ai/mcp.html"
"/assistant/contexts.html" = "/docs/ai/text-threads.html"
"/assistant/inline-assistant.html" = "/docs/ai/inline-assistant.html"
"/assistant/model-context-protocol.html" = "/docs/ai/mcp.html"
"/assistant/prompting.html" = "/docs/ai/rules.html"
"/language-model-integration.html" = "/docs/assistant/assistant.html"
"/model-improvement.html" = "/docs/ai/ai-improvement.html"
"/ai/temperature.html" = "/docs/ai/agent-settings.html#model-temperature"
# Collaboration
"/channels.html" = "/docs/collaboration/channels.html"
"/collaboration.html" = "/docs/collaboration/overview.html"
# Community
"/community/feedback.html" = "/community-links"
"/conversations.html" = "/community-links"
# Debugger
"/debuggers.html" = "/docs/debugger.html"
# MCP
"/assistant/model-context-protocolCitedby.html" = "/docs/ai/mcp.html"
"/context-servers.html" = "/docs/ai/mcp.html"
"/extensions/context-servers.html" = "/docs/extensions/mcp-extensions.html"
# Languages
"/adding-new-languages.html" = "/docs/extensions/languages.html"
"/elixir.html" = "/docs/languages/elixir.html"
"/javascript.html" = "/docs/languages/javascript.html"
"/languages/languages/html.html" = "/docs/languages/html.html"
"/languages/languages/javascript.html" = "/docs/languages/javascript.html"
"/languages/languages/makefile.html" = "/docs/languages/makefile.html"
"/languages/languages/nim.html" = "/docs/languages/nim.html"
"/languages/languages/ruby.html" = "/docs/languages/ruby.html"
"/languages/languages/scala.html" = "/docs/languages/scala.html"
"/python.html" = "/docs/languages/python.html"
"/ruby.html" = "/docs/languages/ruby.html"
# Zed development
"/contribute-to-zed.html" = "/docs/development.html#contributor-links"
"/contributing.html" = "/docs/development.html#contributor-links"
"/developing-zed.html" = "/docs/development.html"
"/development/development/linux.html" = "/docs/development/linux.html"
"/development/development/macos.html" = "/docs/development/macos.html"
"/development/development/windows.html" = "/docs/development/windows.html"
# Our custom preprocessor for expanding commands like `{#kb action::ActionName}`,
# and other docs-related functions.
#
# Comment the below section out if you need to bypass the preprocessor for some reason.
[preprocessor.zed_docs_preprocessor]
command = "cargo run -p docs_preprocessor --"
renderer = ["html"]
docs/src/SUMMARY.md
-179
View File
@@ -1,179 +0,0 @@
# Summary
# Welcome
- [Getting Started](./getting-started.md)
- [Installation](./installation.md)
- [Update](./update.md)
- [Uninstall](./uninstall.md)
- [Authenticate](./authentication.md)
- [Telemetry](./telemetry.md)
- [Troubleshooting](./troubleshooting.md)
# Configuration
- [Configuring Zed](./configuring-zed.md)
- [Configuring Languages](./configuring-languages.md)
- [Toolchains](./toolchains.md)
- [Key bindings](./key-bindings.md)
- [All Actions](./all-actions.md)
- [Snippets](./snippets.md)
- [Themes](./themes.md)
- [Icon Themes](./icon-themes.md)
- [Visual Customization](./visual-customization.md)
- [Vim Mode](./vim.md)
- [Helix Mode](./helix.md)
<!-- - [Globs](./globs.md) -->
<!-- - [Fonts](./fonts.md) -->
# Using Zed
- [Multibuffers](./multibuffers.md)
- [Command Palette](./command-palette.md)
- [Command-line Interface](./command-line-interface.md)
- [Outline Panel](./outline-panel.md)
- [Code Completions](./completions.md)
- [Collaboration](./collaboration/overview.md)
- [Channels](./collaboration/channels.md)
- [Contacts and Private Calls](./collaboration/contacts-and-private-calls.md)
- [Git](./git.md)
- [Debugger](./debugger.md)
- [Diagnostics](./diagnostics.md)
- [Tasks](./tasks.md)
- [Tab Switcher](./tab-switcher.md)
- [Remote Development](./remote-development.md)
- [Environment Variables](./environment.md)
- [REPL](./repl.md)
# Platform Support
- [Windows](./windows.md)
- [Linux](./linux.md)
# AI
- [Overview](./ai/overview.md)
- [Agent Panel](./ai/agent-panel.md)
- [Tools](./ai/tools.md)
- [External Agents](./ai/external-agents.md)
- [Inline Assistant](./ai/inline-assistant.md)
- [Edit Prediction](./ai/edit-prediction.md)
- [Text Threads](./ai/text-threads.md)
- [Rules](./ai/rules.md)
- [Model Context Protocol](./ai/mcp.md)
- [Configuration](./ai/configuration.md)
- [LLM Providers](./ai/llm-providers.md)
- [Agent Settings](./ai/agent-settings.md)
- [Subscription](./ai/subscription.md)
- [Models](./ai/models.md)
- [Plans and Usage](./ai/plans-and-usage.md)
- [Billing](./ai/billing.md)
- [Privacy and Security](./ai/privacy-and-security.md)
- [AI Improvement](./ai/ai-improvement.md)
# Extensions
- [Overview](./extensions.md)
- [Installing Extensions](./extensions/installing-extensions.md)
- [Developing Extensions](./extensions/developing-extensions.md)
- [Extension Capabilities](./extensions/capabilities.md)
- [Language Extensions](./extensions/languages.md)
- [Debugger Extensions](./extensions/debugger-extensions.md)
- [Theme Extensions](./extensions/themes.md)
- [Icon Theme Extensions](./extensions/icon-themes.md)
- [Slash Command Extensions](./extensions/slash-commands.md)
- [Agent Server Extensions](./extensions/agent-servers.md)
- [MCP Server Extensions](./extensions/mcp-extensions.md)
# Migrate
- [VS Code](./migrate/vs-code.md)
# Language Support
- [All Languages](./languages.md)
- [Ansible](./languages/ansible.md)
- [AsciiDoc](./languages/asciidoc.md)
- [Astro](./languages/astro.md)
- [Bash](./languages/bash.md)
- [Biome](./languages/biome.md)
- [C](./languages/c.md)
- [C++](./languages/cpp.md)
- [C#](./languages/csharp.md)
- [Clojure](./languages/clojure.md)
- [CSS](./languages/css.md)
- [Dart](./languages/dart.md)
- [Deno](./languages/deno.md)
- [Diff](./languages/diff.md)
- [Docker](./languages/docker.md)
- [Elixir](./languages/elixir.md)
- [Elm](./languages/elm.md)
- [Emmet](./languages/emmet.md)
- [Erlang](./languages/erlang.md)
- [Fish](./languages/fish.md)
- [GDScript](./languages/gdscript.md)
- [Gleam](./languages/gleam.md)
- [GLSL](./languages/glsl.md)
- [Go](./languages/go.md)
- [Groovy](./languages/groovy.md)
- [Haskell](./languages/haskell.md)
- [Helm](./languages/helm.md)
- [HTML](./languages/html.md)
- [Java](./languages/java.md)
- [JavaScript](./languages/javascript.md)
- [Julia](./languages/julia.md)
- [JSON](./languages/json.md)
- [Jsonnet](./languages/jsonnet.md)
- [Kotlin](./languages/kotlin.md)
- [Lua](./languages/lua.md)
- [Luau](./languages/luau.md)
- [Makefile](./languages/makefile.md)
- [Markdown](./languages/markdown.md)
- [Nim](./languages/nim.md)
- [OCaml](./languages/ocaml.md)
- [OpenTofu](./languages/opentofu.md)
- [PHP](./languages/php.md)
- [PowerShell](./languages/powershell.md)
- [Prisma](./languages/prisma.md)
- [Proto](./languages/proto.md)
- [PureScript](./languages/purescript.md)
- [Python](./languages/python.md)
- [R](./languages/r.md)
- [Rego](./languages/rego.md)
- [ReStructuredText](./languages/rst.md)
- [Racket](./languages/racket.md)
- [Roc](./languages/roc.md)
- [Ruby](./languages/ruby.md)
- [Rust](./languages/rust.md)
- [Scala](./languages/scala.md)
- [Scheme](./languages/scheme.md)
- [Shell Script](./languages/sh.md)
- [SQL](./languages/sql.md)
- [Svelte](./languages/svelte.md)
- [Swift](./languages/swift.md)
- [Tailwind CSS](./languages/tailwindcss.md)
- [Terraform](./languages/terraform.md)
- [TOML](./languages/toml.md)
- [TypeScript](./languages/typescript.md)
- [Uiua](./languages/uiua.md)
- [Vue](./languages/vue.md)
- [XML](./languages/xml.md)
- [YAML](./languages/yaml.md)
- [Yara](./languages/yara.md)
- [Yarn](./languages/yarn.md)
- [Zig](./languages/zig.md)
# Developing Zed
- [Developing Zed](./development.md)
- [macOS](./development/macos.md)
- [Linux](./development/linux.md)
- [Windows](./development/windows.md)
- [FreeBSD](./development/freebsd.md)
- [Local Collaboration](./development/local-collaboration.md)
- [Using Debuggers](./development/debuggers.md)
- [Performance](./performance.md)
- [Glossary](./development/glossary.md)
- [Release Notes](./development/release-notes.md)
- [Debugging Crashes](./development/debugging-crashes.md)
docs/src/ai/agent-panel.md
-184
View File
@@ -1,184 +0,0 @@
# Agent Panel
The Agent Panel allows you to interact with many LLMs and coding agents that can help with various types of tasks, such as generating code, codebase understanding, and other general inquiries like writing emails, documentation, and more.
To open it, use the `agent: new thread` action in [the Command Palette](../getting-started.md#command-palette) or click the ✨ (sparkles) icon in the status bar.
## Getting Started {#getting-started}
If you're using the Agent Panel for the first time, you need to have at least one LLM provider or external agent configured.
You can do that by:
1. [subscribing to our Pro plan](https://zed.dev/pricing), so you have access to our hosted models
2. [using your own API keys](./llm-providers.md#use-your-own-keys), either from model providers like Anthropic or model gateways like OpenRouter.
3. using an [external agent](./external-agents.md) like [Gemini CLI](./external-agents.md#gemini-cli) or [Claude Code](./external-agents.md#claude-code)
## Overview {#overview}
With an LLM provider or an external agent configured, type at the message editor and hit `enter` to submit your prompt.
If you need extra room to type, you can expand the message editor with {#kb agent::ExpandMessageEditor}.
You should start to see the responses stream in with indications of [which tools](./tools.md) the model is using to fulfill your prompt.
From this point on, you can interact with the many supported features outlined below.
> Note that for external agents, like [Gemini CLI](./external-agents.md#gemini-cli) or [Claude Code](./external-agents.md#claude-code), some of the features outlined below may _not_ be supported—for example, _restoring threads from history_, _checkpoints_, _token usage display_, and others. Their availability varies depending on the agent.
### Creating New Threads {#new-thread}
By default, the Agent Panel uses Zed's first-party agent.
To change that, go to the plus button in the top-right of the Agent Panel and choose another option.
You can choose to create a new [Text Thread](./text-threads.md) or, if you have [external agents](./external-agents.md) connected, you can create new threads with them.
### Editing Messages {#editing-messages}
Any message that you send to the AI is editable.
You can click on the card that contains your message and re-submit it with an adjusted prompt and/or new pieces of context.
### Checkpoints {#checkpoints}
Every time the AI performs an edit, you should see a "Restore Checkpoint" button at the top of your message, allowing you to return your code base to the state it was in prior to that message.
The checkpoint button appears even if you interrupt the thread midway through an edit attempt, as this is likely a moment when you've identified that the agent is not heading in the right direction and you want to revert back.
### Navigating History {#navigating-history}
To quickly navigate through recently opened threads, use the {#kb agent::ToggleNavigationMenu} binding, when focused on the panel's editor, or click the menu icon button at the top right of the panel to open the dropdown that shows you the six most recent threads.
The items in this menu function similarly to tabs, and closing them doesn’t delete the thread; instead, it simply removes them from the recent list.
To view all historical conversations, reach for the `View All` option from within the same menu or via the {#kb agent::OpenHistory} binding.
### Following the Agent {#following-the-agent}
Zed is built with collaboration natively integrated, and this design pattern extends to collaboration with AI. To follow the agent as it reads and edits in your codebase, click on the "crosshair" icon button at the bottom left of the panel.
You can also do that with the keyboard by pressing the `cmd`/`ctrl` modifier with `enter` when submitting a message.
### Get Notified {#get-notified}
If you send a prompt to the Agent and then move elsewhere, putting Zed in the background, you can be notified when its response is finished via:
- a visual notification that appears in the top right of your screen
- a sound notification
These notifications can be used together or individually, according to your preference.
You can customize their behavior, including turning them off entirely, by using the `agent.notify_when_agent_waiting` and `agent.play_sound_when_agent_done` settings keys.
### Reviewing Changes {#reviewing-changes}
Once the agent has made changes to your project, the panel will surface which files, and how many of them, have been edited.
To see which files specifically have been edited, expand the accordion bar that shows up right above the message editor or click the `Review Changes` button ({#kb agent::OpenAgentDiff}), which opens a multi-buffer tab with all changes.
You're able to reject or accept each individual change hunk, or the whole set of changes made by the agent.
Edit diffs also appear in individual buffers. If your active tab had edits made by the AI, you'll see diffs with the same accept/reject controls as in the multi-buffer.
## Adding Context {#adding-context}
Although Zed's agent is very efficient at reading through your code base to autonomously pick up relevant context, manually adding whatever would be useful to fulfill your prompt is still very encouraged as a way to not only improve the AI's response quality but also to speed up its response time.
In Zed's Agent Panel, all pieces of context are added as mentions in the panel's message editor.
You can type `@` to mention files, directories, symbols, previous threads, and rules files.
Copying images and pasting them in the panel's message editor is also supported.
### Selection as Context
Additionally, you can also select text in a buffer and add it as context by using the {#kb agent::AddSelectionToThread} keybinding, running the {#action agent::AddSelectionToThread} action, or choosing the "Selection" item in the `@` menu.
## Token Usage {#token-usage}
Zed surfaces how many tokens you are consuming for your currently active thread near the profile selector in the panel's message editor. Depending on how many pieces of context you add, your token consumption can grow rapidly.
Once you approach the model's context window, a banner appears below the message editor suggesting to start a new thread with the current one summarized and added as context.
You can also do this at any time with an ongoing thread via the "Agent Options" menu on the top right.
## Changing Models {#changing-models}
After you've configured your LLM providers—either via [a custom API key](./llm-providers.md) or through [Zed's hosted models](./models.md)—you can switch between them by clicking on the model selector on the message editor or by using the {#kb agent::ToggleModelSelector} keybinding.
> The same model can be offered via multiple providers - for example, Claude Sonnet 4 is available via Zed Pro, OpenRouter, Anthropic directly, and more.
> Make sure you've selected the correct model **_provider_** for the model you'd like to use, delineated by the logo to the left of the model in the model selector.
## Using Tools {#using-tools}
The new Agent Panel supports tool calling, which enables agentic editing.
Zed comes with [several built-in tools](./tools.md) that allow models to perform tasks such as searching through your codebase, editing files, running commands, and others.
You can also extend the set of available tools via [MCP Servers](./mcp.md).
### Profiles {#profiles}
Profiles act as a way to group tools.
Zed offers three built-in profiles and you can create as many custom ones as you want.
#### Built-in Profiles {#built-in-profiles}
- `Write`: A profile with tools to allow the LLM to write to your files and run terminal commands. This one essentially has all built-in tools turned on.
- `Ask`: A profile with read-only tools. Best for asking questions about your code base without the concern of the agent making changes.
- `Minimal`: A profile with no tools. Best for general conversations with the LLM where no knowledge of your code base is necessary.
You can explore the exact tools enabled in each profile by clicking on the profile selector button > `Configure` button > the one you want to check out.
Alternatively, you can also use either the command palette, by running {#action agent::ManageProfiles}, or the keybinding directly, {#kb agent::ManageProfiles}, to have access to the profile management modal.
#### Custom Profiles {#custom-profiles}
You can also create a custom profile through the Agent Profile modal.
From there, you can choose to `Add New Profile` or fork an existing one with a custom name and your preferred set of tools.
It's also possible to override built-in profiles.
In the Agent Profile modal, select a built-in profile, navigate to `Configure Tools`, and rearrange the tools you'd like to keep or remove.
Zed will store this profile in your settings using the same profile name as the default you overrode.
All custom profiles can be edited via the UI or by hand under the `agent.profiles` key in your `settings.json` file.
### Tool Approval
Zed's Agent Panel surfaces the `agent.always_allow_tool_actions` setting that, if turned to `false`, will require you to give permission to any editing attempt as well as tool calls coming from MCP servers.
You can change that by setting this key to `true` in either your `settings.json` or via the Agent Panel's settings view.
### Model Support {#model-support}
Tool calling needs to be individually supported by each model and model provider.
Therefore, despite the presence of tools, some models may not have the ability to pick them up yet in Zed.
You should see a "No tools" label if you select a model that falls into this case.
All [Zed's hosted models](./models.md) support tool calling out-of-the-box.
### MCP Servers {#mcp-servers}
Similarly to the built-in tools, some models may not support all tools included in a given MCP Server.
Zed's UI will inform you about this via a warning icon that appears close to the model selector.
## Text Threads {#text-threads}
["Text Threads"](./text-threads.md) present your conversation with the LLM in a different format—as raw text.
With text threads, you have full control over the conversation data.
You can remove and edit responses from the LLM, swap roles, and include more context earlier in the conversation.
For users who have been with us for some time, you'll notice that text threads are our original assistant panel—users love it for the control it offers.
We do not plan to deprecate text threads, but it should be noted that if you want the AI to write to your code base autonomously, that's only available in the newer, and now default, "Threads".
## Errors and Debugging {#errors-and-debugging}
In case of any error or strange LLM response behavior, the best way to help the Zed team debug is by reaching for the `agent: open thread as markdown` action and attaching that data as part of your issue on GitHub.
You can also open threads as Markdown by clicking on the file icon button, to the right of the thumbs down button, when focused on the panel's editor.
## Feedback {#feedback}
Zed supports rating responses from the agent for feedback and improvement.
> Note that rating responses will send your data related to that response to Zed's servers.
> See [AI Improvement](./ai-improvement.md) and [Privacy and Security](./privacy-and-security.md) for more information about Zed's approach to AI improvement, privacy, and security.
> **_If you don't want data persisted on Zed's servers, don't rate_**. We will not collect data for improving our Agentic offering without you explicitly rating responses.
The best way you can help influence the next change to Zed's system prompt and tools is by rating the LLM's response via the thumbs up/down buttons at the end of every response. In case of a thumbs down, a new text area will show up where you can add more specifics about what happened.
You can provide feedback on the thread at any point after the agent responds, and multiple times within the same thread.
docs/src/ai/agent-settings.md
-266
View File
@@ -1,266 +0,0 @@
# Agent Settings
Learn about all the settings you can customize in Zed's Agent Panel.
## Model Settings {#model-settings}
### Default Model {#default-model}
If you're using [Zed's hosted LLM service](./subscription.md), it sets `claude-sonnet-4` as the default model for agentic work (agent panel, inline assistant) and `gpt-5-nano` as the default "fast" model (thread summarization, git commit messages). If you're not subscribed or want to change these defaults, you can manually edit the `default_model` object in your settings:
```json [settings]
{
"agent": {
"default_model": {
"provider": "openai",
"model": "gpt-4o"
}
}
}
```
### Feature-specific Models {#feature-specific-models}
You can assign distinct and specific models for the following AI-powered features:
- Thread summary model: Used for generating thread summaries
- Inline assistant model: Used for the inline assistant feature
- Commit message model: Used for generating Git commit messages
```json [settings]
{
"agent": {
"default_model": {
"provider": "zed.dev",
"model": "claude-sonnet-4"
},
"inline_assistant_model": {
"provider": "anthropic",
"model": "claude-3-5-sonnet"
},
"commit_message_model": {
"provider": "openai",
"model": "gpt-4o-mini"
},
"thread_summary_model": {
"provider": "google",
"model": "gemini-2.0-flash"
}
}
}
```
> If a custom model isn't set for one of these features, they automatically fall back to using the default model.
### Alternative Models for Inline Assists {#alternative-assists}
With the Inline Assistant in particular, you can send the same prompt to multiple models at once.
Here's how you can customize your `settings.json` to add this functionality:
```json [settings]
{
"agent": {
"default_model": {
"provider": "zed.dev",
"model": "claude-sonnet-4"
},
"inline_alternatives": [
{
"provider": "zed.dev",
"model": "gpt-4-mini"
}
]
}
}
```
When multiple models are configured, you'll see in the Inline Assistant UI buttons that allow you to cycle between outputs generated by each model.
The models you specify here are always used in _addition_ to your [default model](#default-model).
For example, the following configuration will generate three outputs for every assist.
One with Claude Sonnet 4 (the default model), another with GPT-5-mini, and another one with Gemini 2.5 Flash.
```json [settings]
{
"agent": {
"default_model": {
"provider": "zed.dev",
"model": "claude-sonnet-4"
},
"inline_alternatives": [
{
"provider": "zed.dev",
"model": "gpt-4-mini"
},
{
"provider": "zed.dev",
"model": "gemini-2.5-flash"
}
]
}
}
```
### Model Temperature
Specify a custom temperature for a provider and/or model:
```json [settings]
"model_parameters": [
// To set parameters for all requests to OpenAI models:
{
"provider": "openai",
"temperature": 0.5
},
// To set parameters for all requests in general:
{
"temperature": 0
},
// To set parameters for a specific provider and model:
{
"provider": "zed.dev",
"model": "claude-sonnet-4",
"temperature": 1.0
}
],
```
## Agent Panel Settings {#agent-panel-settings}
Note that some of these settings are also surfaced in the Agent Panel's settings UI, which you can access either via the `agent: open settings` action or by the dropdown menu on the top-right corner of the panel.
### Default View
Use the `default_view` setting to change the default view of the Agent Panel.
You can choose between `thread` (the default) and `text_thread`:
```json [settings]
{
"agent": {
"default_view": "text_thread"
}
}
```
### Font Size
Use the `agent_font_size` setting to change the font size of rendered agent responses in the panel.
```json [settings]
{
"agent": {
"agent_font_size": 18
}
}
```
> Editors in the Agent Panel—whether that is the main message textarea or previous messages—use monospace fonts and therefore, are controlled by the `buffer_font_size` setting, which is defined globally in your `settings.json`.
### Auto-run Commands
Control whether to allow the agent to run commands without asking you for permission.
The default value is `false`.
```json [settings]
{
"agent": {
"always_allow_tool_actions": true
}
}
```
### Single-file Review
Control whether to display review actions (accept & reject) in single buffers after the agent is done performing edits.
The default value is `false`.
```json [settings]
{
"agent": {
"single_file_review": true
}
}
```
When set to false, these controls are only available in the multibuffer review tab.
### Sound Notification
Control whether to hear a notification sound when the agent is done generating changes or needs your input.
The default value is `false`.
```json [settings]
{
"agent": {
"play_sound_when_agent_done": true
}
}
```
### Message Editor Size
Use the `message_editor_min_lines` setting to control the minimum number of lines of height the agent message editor should have.
It is set to `4` by default, and the max number of lines is always double of the minimum.
```json [settings]
{
"agent": {
"message_editor_min_lines": 4
}
}
```
### Modifier to Send
Make a modifier (`cmd` on macOS, `ctrl` on Linux) required to send messages.
This is encouraged for more thoughtful prompt crafting.
The default value is `false`.
```json [settings]
{
"agent": {
"use_modifier_to_send": true
}
}
```
### Edit Card
Use the `expand_edit_card` setting to control whether edit cards show the full diff in the Agent Panel.
It is set to `true` by default, but if set to false, the card's height is capped to a certain number of lines, requiring a click to be expanded.
```json [settings]
{
"agent": {
"expand_edit_card": false
}
}
```
### Terminal Card
Use the `expand_terminal_card` setting to control whether terminal cards show the command output in the Agent Panel.
It is set to `true` by default, but if set to false, the card will be fully collapsed even while the command is running, requiring a click to be expanded.
```json [settings]
{
"agent": {
"expand_terminal_card": false
}
}
```
### Feedback Controls
Control whether to display the thumbs up/down buttons at the bottom of each agent response, allowing you to give Zed feedback about the agent's performance.
The default value is `true`.
```json [settings]
{
"agent": {
"enable_feedback": false
}
}
```
docs/src/ai/ai-improvement.md
-112
View File
@@ -1,112 +0,0 @@
# Zed AI Improvement
## Agent Panel
### Opt-In
When you use the Agent Panel through any of these means:
- [Zed's hosted models](./subscription.md)
- [connecting a non-Zed AI service via API key](./llm-providers.md)
- using an [external agent](./external-agents.md)
Zed does not persistently store user content or use user content to evaluate and/or improve our AI features, unless it is explicitly shared with Zed. Each share is opt-in, and sharing once will not cause future content or data to be shared again.
> Note that rating responses will send your data related to that response to Zed's servers.
> **_If you don't want data persisted on Zed's servers, don't rate_**. We will not collect data for improving our Agentic offering without you explicitly rating responses.
When using upstream services through Zed's hosted models, we require assurances from our service providers that your user content won't be used for training models.
| Provider | No Training Guarantee | Zero-Data Retention (ZDR) |
| --------- | ------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
| Anthropic | [Yes](https://www.anthropic.com/legal/commercial-terms) | [Yes](https://privacy.anthropic.com/en/articles/8956058-i-have-a-zero-data-retention-agreement-with-anthropic-what-products-does-it-apply-to) |
| Google | [Yes](https://cloud.google.com/terms/service-terms) | [Yes](https://cloud.google.com/terms/service-terms), see Service Terms sections 17 and 19h |
| OpenAI | [Yes](https://openai.com/enterprise-privacy/) | [Yes](https://platform.openai.com/docs/guides/your-data) |
When you use your own API keys or external agents, **Zed does not have control over how your data is used by that service provider.**
You should reference your agreement with each service provider to understand what terms and conditions apply.
### Data we collect
For prompts you have explicitly shared with us, Zed may store copies of those prompts and other data about the specific use of the Agent Panel.
This data includes:
- The prompt given to the Agent
- Any commentary you include
- Product telemetry about the agentic thread
- Metadata about your Zed installation
### Data Handling
Collected data is stored in Snowflake, a private database where we track other metrics. We periodically review this data to improve our overall agentic approach and refine the product via our system prompt, tool use, etc. We ensure any included data is anonymized and contains no sensitive information (access tokens, user IDs, email addresses, etc).
## Edit Predictions
By default, when using Zed Edit Predictions, Zed does not persistently store user content or use user content for training of its models.
### Opt-in
Users who are working on open source licensed projects may optionally opt-in to providing model improvement feedback. This opt-in occurs on a per-project basis. If you work on multiple open source projects and wish to provide model improvement feedback you will have to opt-in for each individual project.
When working on other projects where you haven't opted-in, Zed will not persistently store user content or use user content for training of its models.
You can see exactly how Zed detects open source licenses in: [license_detection.rs](https://github.com/zed-industries/zed/blob/main/crates/zeta/src/license_detection.rs).
### Exclusions
Zed will intentionally exclude certain files from Predictive Edits entirely, even when you have opted-in to model improvement feedback.
You can inspect this exclusion list by opening `zed: open default settings` from the command palette:
```json [settings]
{
"edit_predictions": {
// A list of globs representing files that edit predictions should be disabled for.
// There's a sensible default list of globs already included.
// Any addition to this list will be merged with the default list.
"disabled_globs": [
"**/.env*",
"**/*.pem",
"**/*.key",
"**/*.cert",
"**/*.crt",
"**/secrets.yml"
]
}
}
```
Users may explicitly exclude additional paths and/or file extensions by adding them to [`edit_predictions.disabled_globs`](https://zed.dev/docs/configuring-zed#edit-predictions) in their Zed settings.json:
```json [settings]
{
"edit_predictions": {
"disabled_globs": ["secret_dir/*", "**/*.log"]
}
}
```
### Data we collect
For open source projects where you have opted-in, Zed may store copies of requests and responses to the Zed AI Prediction service.
This data includes:
- the edit prediction
- a portion of the buffer content around the cursor
- a few recent edits
- the current buffer outline
- diagnostics (errors, warnings, etc) from language servers
### Data Handling
Collected data is stored in Snowflake, a private database where we track other metrics. We periodically review this data to select training samples for inclusion in our model training dataset. We ensure any included data is anonymized and contains no sensitive information (access tokens, user IDs, email addresses, etc). This training dataset is publicly available at [huggingface.co/datasets/zed-industries/zeta](https://huggingface.co/datasets/zed-industries/zeta).
### Model Output
We then use this training dataset to fine-tune [Qwen2.5-Coder-7B](https://huggingface.co/Qwen/Qwen2.5-Coder-7B) and make the resulting model available at [huggingface.co/zed-industries/zeta](https://huggingface.co/zed-industries/zeta).
## Applicable terms
Please see the [Zed Terms of Service](https://zed.dev/terms-of-service) for more.
docs/src/ai/billing.md
-50
View File
@@ -1,50 +0,0 @@
# Billing
We use Stripe as our payments provider, and Orb for invoicing and metering. All Pro plans require payment via credit card or other supported payment method.
For invoice-based billing, a Business plan is required. Contact [sales@zed.dev](mailto:sales@zed.dev) for more information.
## Billing Information {#settings}
You can access billing information and settings at [zed.dev/account](https://zed.dev/account).
Most of the page embeds information from our invoicing/metering partner, Orb (we're planning on a more native experience soon!).
## Billing Cycles {#billing-cycles}
Zed is billed on a monthly basis based on the date you initially subscribe. You'll receive _at least_ one invoice from Zed each month you're subscribed to Zed Pro, and more than one if you use more than $10 in incremental token spend within the month.
## Threshold Billing {#threshold-billing}
Zed utilizes threshold billing to ensure timely collection of owed monies and prevent abuse. Every time your usage of Zed's hosted models crosses a $10 spend threshold, a new invoice is generated, and the threshold resets to $0.
For example,
- You subscribe on February 1. Your first invoice is $10.
- You use $12 of incremental tokens in the month of February, with the first $10 spent on February 15. You'll receive an invoice for $10 on February 15
- On March 1, you receive an invoice for $12: $10 (March Pro subscription) and $2 in leftover token spend, since your usage didn't cross the $10 threshold.
## Payment Failures {#payment-failures}
If payment of an invoice fails, Zed will block usage of our hosted models until the payment is complete. Email [billing-support@zed.dev](mailto:billing-support@zed.dev) for assistance.
## Invoice History {#invoice-history}
You can access your invoice history by navigating to [zed.dev/account](https://zed.dev/account) and clicking `Invoice history` within the embedded Orb portal.
If you require historical Stripe invoices, email [billing-support@zed.dev](mailto:billing-support@zed.dev)
## Updating Billing Information {#updating-billing-info}
Email [billing-support@zed.dev](mailto:billing-support@zed.dev) for help updating payment methods, names, addresses, and tax information.
> We'll be updating our account page shortly to allow for self-service updates. Stay tuned!
Please note that changes to billing information will **only** affect future invoices — **we cannot modify historical invoices**.
## Sales Tax {#sales-tax}
Zed partners with [Sphere](https://www.getsphere.com/) to calculate indirect tax rate for invoices, based on customer location and the product being sold. Tax is listed as a separate line item on invoices, based preferentially on your billing address, followed by the card issue country known to Stripe.
If you have a VAT/GST ID, you can add it at during checkout. Check the box that denotes you as a business.
Please note that changes to VAT/GST IDs and address will **only** affect future invoices — **we cannot modify historical invoices**.
Questions or issues can be directed to [billing-support@zed.dev](mailto:billing-support@zed.dev).
docs/src/ai/configuration.md
-23
View File
@@ -1,23 +0,0 @@
# Configuration
When using AI in Zed, you can configure multiple dimensions:
1. Which LLM providers you can use
- Zed's hosted models, which require [authentication](../authentication.md) and [subscription](./subscription.md)
- [Using your own API keys](./llm-providers.md), which do not
- Using [external agents like Claude Code](./external-agents.md), which do not
2. [Model parameters and usage](./agent-settings.md#model-settings)
3. [Interactions with the Agent Panel](./agent-settings.md#agent-panel-settings)
## Turning AI Off Entirely
We want to respect users who want to use Zed without interacting with AI whatsoever.
To do that, add the following key to your `settings.json`:
```json [settings]
{
"disable_ai": true
}
```
Read [the following blog post](https://zed.dev/blog/disable-ai-features) to learn more about our motivation to promote this, as much as we also encourage users to explore AI-assisted programming.
docs/src/ai/edit-prediction.md
-365
View File
@@ -1,365 +0,0 @@
# Edit Prediction
Edit Prediction is Zed's LLM mechanism for predicting the code you want to write.
Each keystroke sends a new request to the edit prediction provider, which returns individual or multi-line suggestions that can be quickly accepted by pressing `tab`.
The default provider is [Zeta, a proprietary open source and open dataset model](https://huggingface.co/zed-industries/zeta), but you can also use [other providers](#other-providers) like GitHub Copilot, Supermaven, and Codestral.
## Configuring Zeta
To use Zeta, the only thing you need to do is [to sign in](../authentication.md#what-features-require-signing-in).
After doing that, you should already see predictions as you type on your files.
You can confirm that Zeta is properly configured either by verifying whether you have the following code in your `settings.json`:
```json [settings]
"features": {
"edit_prediction_provider": "zed"
},
```
Or you can also look for a little Z icon in the right of your status bar at the bottom.
### Pricing and Plans
From just signing in, while in Zed's free plan, you get 2,000 Zeta-powered edit predictions per month.
But you can get _**unlimited edit predictions**_ by upgrading to [the Pro plan](../ai/plans-and-usage.md).
More information can be found in [Zed's pricing page](https://zed.dev/pricing).
### Switching Modes {#switching-modes}
Zed's Edit Prediction comes with two different display modes:
1. `eager` (default): predictions are displayed inline as long as it doesn't conflict with language server completions
2. `subtle`: predictions only appear inline when holding a modifier key (`alt` by default)
Toggle between them via the `mode` key:
```json [settings]
"edit_predictions": {
"mode": "eager" // or "subtle"
},
```
Or directly via the UI through the status bar menu:
![Edit Prediction status bar menu, with the modes toggle.](https://zed.dev/img/edit-prediction/status-bar-menu.webp)
> Note that edit prediction modes work with any prediction provider.
### Conflict With Other `tab` Actions {#edit-predictions-conflict}
By default, when `tab` would normally perform a different action, Zed requires a modifier key to accept predictions:
1. When the language server completions menu is visible.
2. When your cursor isn't at the right indentation level.
In these cases, `alt-tab` is used instead to accept the prediction. When the language server completions menu is open, holding `alt` first will cause it to temporarily disappear in order to preview the prediction within the buffer.
On Linux, `alt-tab` is often used by the window manager for switching windows, so `alt-l` is provided as the default binding for accepting predictions. `tab` and `alt-tab` also work, but aren't displayed by default.
{#action editor::AcceptPartialEditPrediction} ({#kb editor::AcceptPartialEditPrediction}) can be used to accept the current edit prediction up to the next word boundary.
## Configuring Edit Prediction Keybindings {#edit-predictions-keybinding}
By default, `tab` is used to accept edit predictions. You can use another keybinding by inserting this in your keymap:
```json [settings]
{
"context": "Editor && edit_prediction",
"bindings": {
// Here we also allow `alt-enter` to accept the prediction
"alt-enter": "editor::AcceptEditPrediction"
}
}
```
When there's a [conflict with the `tab` key](#edit-predictions-conflict), Zed uses a different key context to accept keybindings (`edit_prediction_conflict`).
If you want to use a different one, you can insert this in your keymap:
```json [settings]
{
"context": "Editor && edit_prediction_conflict",
"bindings": {
"ctrl-enter": "editor::AcceptEditPrediction" // Example of a modified keybinding
}
}
```
If your keybinding contains a modifier (`ctrl` in the example above), it will also be used to preview the edit prediction and temporarily hide the language server completion menu.
You can also bind this action to keybind without a modifier.
In that case, Zed will use the default modifier (`alt`) to preview the edit prediction.
```json [settings]
{
"context": "Editor && edit_prediction_conflict",
"bindings": {
// Here we bind tab to accept even when there's a language server completion
// or the cursor isn't at the correct indentation level
"tab": "editor::AcceptEditPrediction"
}
}
```
To maintain the use of the modifier key for accepting predictions when there is a language server completions menu, but allow `tab` to accept predictions regardless of cursor position, you can specify the context further with `showing_completions`:
```json [settings]
{
"context": "Editor && edit_prediction_conflict && !showing_completions",
"bindings": {
// Here we don't require a modifier unless there's a language server completion
"tab": "editor::AcceptEditPrediction"
}
}
```
### Keybinding Example: Always Use Tab
If you want to use `tab` to always accept edit predictions, you can use the following keybinding:
```json [keymap]
{
"context": "Editor && edit_prediction_conflict && showing_completions",
"bindings": {
"tab": "editor::AcceptEditPrediction"
}
}
```
This will make `tab` work to accept edit predictions _even when_ you're also seeing language server completions.
That means that you need to rely on `enter` for accepting the latter.
### Keybinding Example: Always Use Alt-Tab
The keybinding example below causes `alt-tab` to always be used instead of sometimes using `tab`.
You might want this in order to have just one (alternative) keybinding to use for accepting edit predictions, since the behavior of `tab` varies based on context.
```json [keymap]
{
"context": "Editor && edit_prediction",
"bindings": {
"alt-tab": "editor::AcceptEditPrediction"
}
},
// Bind `tab` back to its original behavior.
{
"context": "Editor",
"bindings": {
"tab": "editor::Tab"
}
},
{
"context": "Editor && showing_completions",
"bindings": {
"tab": "editor::ComposeCompletion"
}
},
```
If you are using [Vim mode](../vim.md), then additional bindings are needed after the above to return `tab` to its original behavior:
```json [keymap]
{
"context": "(VimControl && !menu) || vim_mode == replace || vim_mode == waiting",
"bindings": {
"tab": "vim::Tab"
}
},
{
"context": "vim_mode == literal",
"bindings": {
"tab": ["vim::Literal", ["tab", "\u0009"]]
}
},
```
### Keybinding Example: Displaying Tab and Alt-Tab on Linux
While `tab` and `alt-tab` are supported on Linux, `alt-l` is displayed instead.
If your window manager does not reserve `alt-tab`, and you would prefer to use `tab` and `alt-tab`, include these bindings in `keymap.json`:
```json [keymap]
{
"context": "Editor && edit_prediction",
"bindings": {
"tab": "editor::AcceptEditPrediction",
// Optional: This makes the default `alt-l` binding do nothing.
"alt-l": null
}
},
{
"context": "Editor && edit_prediction_conflict",
"bindings": {
"alt-tab": "editor::AcceptEditPrediction",
// Optional: This makes the default `alt-l` binding do nothing.
"alt-l": null
}
},
```
### Missing keybind {#edit-predictions-missing-keybinding}
Zed requires at least one keybinding for the {#action editor::AcceptEditPrediction} action in both the `Editor && edit_prediction` and `Editor && edit_prediction_conflict` contexts ([learn more above](#edit-predictions-keybinding)).
If you have previously bound the default keybindings to different actions in the global context, you will not be able to preview or accept edit predictions. For example:
```json [keymap]
[
// Your keymap
{
"bindings": {
// Binds `alt-tab` to a different action globally
"alt-tab": "menu::SelectNext"
}
}
]
```
To fix this, you can specify your own keybinding for accepting edit predictions:
```json [keymap]
[
// ...
{
"context": "Editor && edit_prediction_conflict",
"bindings": {
"alt-l": "editor::AcceptEditPrediction"
}
}
]
```
If you would like to use the default keybinding, you can free it up by either moving yours to a more specific context or changing it to something else.
## Disabling Automatic Edit Prediction
There are different levels in which you can disable edit predictions to be displayed, including not having it turned on at all.
Alternatively, if you have Zed set as your provider, consider [using Subtle Mode](#switching-modes).
### On Buffers
To not have predictions appear automatically as you type, set this within `settings.json`:
```json [settings]
{
"show_edit_predictions": false
}
```
This hides every indication that there is a prediction available, regardless of [the display mode](#switching-modes) you're in (valid only if you have Zed as your provider).
Still, you can trigger edit predictions manually by executing {#action editor::ShowEditPrediction} or hitting {#kb editor::ShowEditPrediction}.
### For Specific Languages
To not have predictions appear automatically as you type when working with a specific language, set this within `settings.json`:
```json [settings]
{
"language": {
"python": {
"show_edit_predictions": false
}
}
}
```
### In Specific Directories
To disable edit predictions for specific directories or files, set this within `settings.json`:
```json [settings]
{
"edit_predictions": {
"disabled_globs": ["~/.config/zed/settings.json"]
}
}
```
### Turning Off Completely
To completely turn off edit prediction across all providers, explicitly set the settings to `none`, like so:
```json [settings]
"features": {
"edit_prediction_provider": "none"
},
```
## Configuring Other Providers {#other-providers}
Zed's Edit Prediction also work with other completion model providers aside from Zeta.
Learn about the available ones below.
### GitHub Copilot {#github-copilot}
To use GitHub Copilot as your provider, set this within `settings.json`:
```json [settings]
{
"features": {
"edit_prediction_provider": "copilot"
}
}
```
You should be able to sign-in to GitHub Copilot by clicking on the Copilot icon in the status bar and following the setup instructions.
#### Using GitHub Copilot Enterprise
If your organization uses GitHub Copilot Enterprise, you can configure Zed to use your enterprise instance by specifying the enterprise URI in your `settings.json`:
```json [settings]
{
"edit_predictions": {
"copilot": {
"enterprise_uri": "https://your.enterprise.domain"
}
}
}
```
Replace `"https://your.enterprise.domain"` with the URL provided by your GitHub Enterprise administrator (e.g., `https://foo.ghe.com`).
Once set, Zed will route Copilot requests through your enterprise endpoint.
When you sign in by clicking the Copilot icon in the status bar, you will be redirected to your configured enterprise URL to complete authentication.
All other Copilot features and usage remain the same.
Copilot can provide multiple completion alternatives, and these can be navigated with the following actions:
- {#action editor::NextEditPrediction} ({#kb editor::NextEditPrediction}): To cycle to the next edit prediction
- {#action editor::PreviousEditPrediction} ({#kb editor::PreviousEditPrediction}): To cycle to the previous edit prediction
### Supermaven {#supermaven}
To use Supermaven as your provider, set this within `settings.json`:
```json [settings]
{
"features": {
"edit_prediction_provider": "supermaven"
}
}
```
You should be able to sign-in to Supermaven by clicking on the Supermaven icon in the status bar and following the setup instructions.
### Codestral {#codestral}
To use Mistral's Codestral as your provider, start by going to the Agent Panel settings view by running the {#action agent::OpenSettings} action.
Look for the Mistral item and add a Codestral API key in the corresponding text input.
After that, you should be able to switch your provider to it in your `settings.json` file:
```json [settings]
{
"features": {
"edit_prediction_provider": "codestral"
}
}
```
## See also
To learn about other ways to interact with AI in Zed, you may also want to see more about the [Agent Panel](./agent-panel.md) or the [Inline Assistant](./inline-assistant.md) feature.
docs/src/ai/external-agents.md
-248
View File
@@ -1,248 +0,0 @@
# External Agents
Zed supports terminal-based agents through the [Agent Client Protocol (ACP)](https://agentclientprotocol.com).
Currently, [Gemini CLI](https://github.com/google-gemini/gemini-cli) serves as the reference implementation.
[Claude Code](https://www.anthropic.com/claude-code) and [Codex](https://developers.openai.com/codex) are also included by default, and you can [add custom ACP-compatible agents](#add-more-agents) as well.
> Note that Zed's affordance for external agents is strictly UI-based; the billing and legal/terms arrangement is directly between you and the agent provider.
> Zed does not charge for use of external agents, and our [zero-data retention agreements/privacy guarantees](./ai-improvement.md) are **_only_** applicable for Zed's hosted models.
## Gemini CLI {#gemini-cli}
Zed provides the ability to run [Gemini CLI](https://github.com/google-gemini/gemini-cli) directly in the [agent panel](./agent-panel.md).
Under the hood we run Gemini CLI in the background, and talk to it over ACP.
This means that you're running the real Gemini CLI, with all of the advantages of that, but you can see and interact with files in your editor.
### Getting Started
As of [Zed Stable v0.201.5](https://zed.dev/releases/stable/0.201.5) you should be able to use Gemini CLI directly from Zed. First open the agent panel with {#kb agent::ToggleFocus}, and then use the `+` button in the top right to start a new Gemini CLI thread.
If you'd like to bind this to a keyboard shortcut, you can do so by editing your `keymap.json` file via the `zed: open keymap` command to include:
```json [keymap]
[
{
"bindings": {
"cmd-alt-g": ["agent::NewExternalAgentThread", { "agent": "gemini" }]
}
}
]
```
#### Installation
The first time you create a Gemini CLI thread, Zed will install [@google/gemini-cli](https://github.com/google-gemini/gemini-cli). This installation is only available to Zed and is kept up to date as you use the agent.
By default, Zed will use this managed version of Gemini CLI even if you have it installed globally. However, you can configure it to use a version in your `PATH` by adding this to your settings:
```json [settings]
{
"agent_servers": {
"gemini": {
"ignore_system_version": false
}
}
}
```
#### Authentication
After you have Gemini CLI running, you'll be prompted to choose your authentication method.
Most users should click the "Log in with Google". This will cause a browser window to pop-up and auth directly with Gemini CLI. Zed does not see your OAuth or access tokens in this case.
You can also use the "Gemini API Key". If you select this, and have the `GEMINI_API_KEY` set, then we will use that. Otherwise Zed will prompt you for an API key which will be stored securely in your keychain, and used to start Gemini CLI from within Zed.
The "Vertex AI" option is for those who are using [Vertex AI](https://cloud.google.com/vertex-ai), and have already configured their environment correctly.
For more information, see the [Gemini CLI docs](https://github.com/google-gemini/gemini-cli/blob/main/docs/index.md).
### Usage
Similar to Zed's first-party agent, you can use Gemini CLI to do anything that you need.
And to give it context, you can @-mention files, recent threads, symbols, or fetch the web.
> Note that some first-party agent features don't yet work with Gemini CLI: editing past messages, resuming threads from history, and checkpointing.
> We hope to add these features in the near future.
## Claude Code
Similar to Gemini CLI, you can also run [Claude Code](https://www.anthropic.com/claude-code) directly via Zed's [agent panel](./agent-panel.md).
Under the hood, Zed runs Claude Code and communicate to it over ACP, through [a dedicated adapter](https://github.com/zed-industries/claude-code-acp).
### Getting Started
Open the agent panel with {#kb agent::ToggleFocus}, and then use the `+` button in the top right to start a new Claude Code thread.
If you'd like to bind this to a keyboard shortcut, you can do so by editing your `keymap.json` file via the `zed: open keymap` command to include:
```json [keymap]
[
{
"bindings": {
"cmd-alt-c": ["agent::NewExternalAgentThread", { "agent": "claude_code" }]
}
}
]
```
### Authentication
As of version `0.202.7` (stable) and `0.203.2` (preview), authentication to Zed's Claude Code installation is decoupled entirely from Zed's agent. That is to say, an Anthropic API key added via the [Zed Agent's settings](./llm-providers.md#anthropic) will _not_ be utilized by Claude Code for authentication and billing.
To ensure you're using your billing method of choice, [open a new Claude Code thread](./agent-panel.md#new-thread). Then, run `/login`, and authenticate either via API key, or via `Log in with Claude Code` to use a Claude Pro/Max subscription.
#### Installation
The first time you create a Claude Code thread, Zed will install [@zed-industries/claude-code-acp](https://github.com/zed-industries/claude-code-acp). This installation is only available to Zed and is kept up to date as you use the agent.
Zed will always use this managed version of the Claude Code adapter, which includes a vendored version of the Claude Code CLI, even if you have it installed globally.
If you want to override the executable used by the adapter, you can set the `CLAUDE_CODE_EXECUTABLE` environment variable in your settings to the path of your preferred executable.
```json
{
"agent_servers": {
"claude": {
"env": {
"CLAUDE_CODE_EXECUTABLE": "/path/to/alternate-claude-code-executable"
}
}
}
}
```
### Usage
Similar to Zed's first-party agent, you can use Claude Code to do anything that you need.
And to give it context, you can @-mention files, recent threads, symbols, or fetch the web.
In complement to talking to it [over ACP](https://agentclientprotocol.com), Zed relies on the [Claude Code SDK](https://docs.anthropic.com/en/docs/claude-code/sdk/sdk-overview) to support some of its specific features.
However, the SDK doesn't yet expose everything needed to fully support all of them:
- Slash Commands: A subset of [built-in commands](https://docs.anthropic.com/en/docs/claude-code/slash-commands#built-in-slash-commands) are supported, while [custom slash commands](https://docs.anthropic.com/en/docs/claude-code/slash-commands#custom-slash-commands) are fully supported.
- [Subagents](https://docs.anthropic.com/en/docs/claude-code/sub-agents) are supported.
- [Hooks](https://docs.anthropic.com/en/docs/claude-code/hooks-guide) are currently _not_ supported.
> Also note that some [first-party agent](./agent-panel.md) features don't yet work with Claude Code: editing past messages, resuming threads from history, and checkpointing.
> We hope to add these features in the near future.
#### CLAUDE.md
Claude Code in Zed will automatically use any `CLAUDE.md` file found in your project root, project subdirectories, or root `.claude` directory.
If you don't have a `CLAUDE.md` file, you can ask Claude Code to create one for you through the `init` slash command.
## Codex CLI
You can also run [Codex CLI](https://github.com/openai/codex) directly via Zed's [agent panel](./agent-panel.md).
Under the hood, Zed runs Codex CLI and communicates to it over ACP, through [a dedicated adapter](https://github.com/zed-industries/codex-acp).
### Getting Started
As of Zed Stable v0.208 you should be able to use Codex directly from Zed. Open the agent panel with {#kb agent::ToggleFocus}, and then use the `+` button in the top right to start a new Codex thread.
If you'd like to bind this to a keyboard shortcut, you can do so by editing your `keymap.json` file via the `zed: open keymap` command to include:
```json
[
{
"bindings": {
"cmd-alt-c": ["agent::NewExternalAgentThread", { "agent": "codex" }]
}
}
]
```
### Authentication
Authentication to Zed's Codex installation is decoupled entirely from Zed's agent. That is to say, an OpenAI API key added via the [Zed Agent's settings](./llm-providers.md#openai) will _not_ be utilized by Codex for authentication and billing.
To ensure you're using your billing method of choice, [open a new Codex thread](./agent-panel.md#new-thread). The first time you will be prompted to authenticate with one of three methods:
1. Login with ChatGPT - allows you to use your existing, paid ChatGPT subscription. _Note: This method isn't currently supported in remote projects_
2. `CODEX_API_KEY` - uses an API key you have set in your environment under the variable `CODEX_API_KEY`.
3. `OPENAI_API_KEY` - uses an API key you have set in your environment under the variable `OPENAI_API_KEY`.
If you are already logged in and want to change your authentication method, type `/logout` in the thread and authenticate again.
If you want to use a third-party provider with Codex, you can configure that with your [Codex config.toml](https://github.com/openai/codex/blob/main/docs/config.md#model-selection) or pass extra [args/env variables](https://github.com/openai/codex/blob/main/docs/config.md#model-selection) to your Codex agent servers settings.
#### Installation
The first time you create a Codex thread, Zed will install [codex-acp](https://github.com/zed-industries/codex-acp). This installation is only available to Zed and is kept up to date as you use the agent.
Zed will always use this managed version of Codex even if you have it installed globally.
### Usage
Similar to Zed's first-party agent, you can use Codex to do anything that you need.
And to give it context, you can @-mention files, symbols, or fetch the web.
> Note that some first-party agent features don't yet work with Codex: editing past messages, resuming threads from history, and checkpointing.
> We hope to add these features in the near future.
## Add More Agents {#add-more-agents}
Add more external agents to Zed by installing [Agent Server extensions](../extensions/agent-servers.md).
See what agents are available by filtering for "Agent Servers" in the extensions page, which you can access via the command palette with `zed: extensions`, or the [Zed website](https://zed.dev/extensions?filter=agent-servers).
You can also add agents through your `settings.json`, by specifying certain fields under `agent_servers`, like so:
```json [settings]
{
"agent_servers": {
"My Custom Agent": {
"type": "custom",
"command": "node",
"args": ["~/projects/agent/index.js", "--acp"],
"env": {}
}
}
}
```
This can be useful if you're in the middle of developing a new agent that speaks the protocol and you want to debug it.
It's also possible to specify a custom path, arguments, or environment for the builtin integrations by using the `claude` and `gemini` names.
### Custom Keybinding For Extension-Based Agents
To assign a custom keybinding to start a new thread for agents that were added by installing agent server extensions, add the following snippet to your `keymap.json` file:
```json [keymap]
{
"bindings": {
"cmd-alt-n": [ // Your custom keybinding
"agent::NewExternalAgentThread",
{
"agent": {
"custom": {
"name": "My Agent", // The agent name as it appears in the UI (e.g., "OpenCode", "Auggie CLI", etc.)
"command": {
"command": "my-agent", // The agent name in lowercase with no spaces
"args": ["acp"]
}
}
}
}
]
}
},
```
## Debugging Agents
When using external agents in Zed, you can access the debug view via with `dev: open acp logs` from the Command Palette. This lets you see the messages being sent and received between Zed and the agent.
![The debug view for ACP logs.](https://zed.dev/img/acp/acp-logs.webp)
## MCP Servers
Note that for external agents, access to MCP servers [installed from Zed](./mcp.md) may vary depending on the ACP agent implementation.
Regarding the built-in ones, Claude Code and Codex both support it, and Gemini CLI does not yet.
In the meantime, learn how to add MCP server support to Gemini CLI through [their documentation](https://github.com/google-gemini/gemini-cli?tab=readme-ov-file#using-mcp-servers).
docs/src/ai/inline-assistant.md
-120
View File
@@ -1,120 +0,0 @@
# Inline Assistant
## Usage Overview
Use {#kb assistant::InlineAssist} to open the Inline Assistant nearly anywhere you can enter text: editors, text threads, the rules library, channel notes, and even within the terminal panel.
The Inline Assistant allows you to send the current selection (or the current line) to a language model and modify the selection with the language model's response.
## Getting Started
If you're using the Inline Assistant for the first time, you need to have at least one LLM provider or external agent configured.
You can do that by:
1. [subscribing to our Pro plan](https://zed.dev/pricing), so you have access to our hosted models
2. [using your own API keys](./llm-providers.md#use-your-own-keys), either from model providers like Anthropic or model gateways like OpenRouter.
If you have already set up an LLM provider to interact with [the Agent Panel](./agent-panel.md#getting-started), then that will also work for the Inline Assistant.
> Unlike the Agent Panel, though, the only exception at the moment is [external agents](./external-agents.md).
> They currently can't be used for generating changes with the Inline Assistant.
## Adding Context
You can add context in the Inline Assistant the same way you can in [the Agent Panel](./agent-panel.md#adding-context):
- @-mention files, directories, past threads, rules, and symbols
- paste images that are copied on your clipboard
Additionally, a useful pattern is to create a thread in the Agent Panel, and then mention it with `@thread` in the Inline Assistant to include it as context.
That often serves as a way to more quickly iterate over a specific part of a change that happened in the context of a larger thread.
## Parallel Generations
There are two ways in which you can generate multiple changes at once with the Inline Assistant:
### Multiple Cursors
If you have a multiple cursor selection and hit {#kb assistant::InlineAssist}, you can shoot the same prompt for all cursor positions and get a change in all of them.
This is particularly useful when working on excerpts in [a multibuffer context](../multibuffers.md).
### Multiple Models
You can use the Inline Assistant to send the same prompt to multiple models at once.
Here's how you can customize your `settings.json` to add this functionality:
```json [settings]
{
"agent": {
"default_model": {
"provider": "zed.dev",
"model": "claude-sonnet-4"
},
"inline_alternatives": [
{
"provider": "zed.dev",
"model": "gpt-4-mini"
}
]
}
}
```
When multiple models are configured, you'll see in the Inline Assistant UI buttons that allow you to cycle between outputs generated by each model.
The models you specify here are always used in _addition_ to your [default model](#default-model).
For example, the following configuration will generate three outputs for every assist.
One with Claude Sonnet 4 (the default model), another with GPT-5-mini, and another one with Gemini 2.5 Flash.
```json [settings]
{
"agent": {
"default_model": {
"provider": "zed.dev",
"model": "claude-sonnet-4"
},
"inline_alternatives": [
{
"provider": "zed.dev",
"model": "gpt-4-mini"
},
{
"provider": "zed.dev",
"model": "gemini-2.5-flash"
}
]
}
}
```
## Inline Assistant vs. Edit Prediction
Users often ask what's the difference between these two AI-powered features in Zed, particularly because both of them involve getting inline LLM code completions.
Here's how they are different:
- The Inline Assistant is more similar to the Agent Panel as in you're still writing a prompt yourself and crafting context. It works from within the buffer and is mostly centered around your selections.
- [Edit Predictions](./edit-prediction.md) is an AI-powered completion mechanism that intelligently suggests what you likely want to add next, based on context automatically gathered from your previous edits, recently visited files, and more.
In summary, the key difference is that in the Inline Assistant, you're still manually prompting, whereas Edit Prediction will _automatically suggest_ edits to you.
## Prefilling Prompts
To create a custom keybinding that prefills a prompt, you can add the following format in your keymap:
```json [keymap]
[
{
"context": "Editor && mode == full",
"bindings": {
"ctrl-shift-enter": [
"assistant::InlineAssist",
{ "prompt": "Build a snake game" }
]
}
}
]
```
docs/src/ai/llm-providers.md
-678
View File
@@ -1,678 +0,0 @@
# LLM Providers
To use AI in Zed, you need to have at least one large language model provider set up.
You can do that by either subscribing to [one of Zed's plans](./plans-and-usage.md), or by using API keys you already have for the supported providers.
## Use Your Own Keys {#use-your-own-keys}
If you already have an API key for an existing LLM provider, like Anthropic or OpenAI, you can add them to Zed and use the full power of the Agent Panel **_for free_**.
To add an existing API key to a given provider, go to the Agent Panel settings (`agent: open settings`), look for the desired provider, paste the key into the input, and hit enter.
> Note: API keys are _not_ stored as plain text in your `settings.json`, but rather in your OS's secure credential storage.
## Supported Providers
Zed offers an extensive list of "use your own key" LLM providers
- [Amazon Bedrock](#amazon-bedrock)
- [Anthropic](#anthropic)
- [DeepSeek](#deepseek)
- [GitHub Copilot Chat](#github-copilot-chat)
- [Google AI](#google-ai)
- [LM Studio](#lmstudio)
- [Mistral](#mistral)
- [Ollama](#ollama)
- [OpenAI](#openai)
- [OpenAI API Compatible](#openai-api-compatible)
- [OpenRouter](#openrouter)
- [Vercel](#vercel-v0)
- [xAI](#xai)
### Amazon Bedrock {#amazon-bedrock}
> Supports tool use with models that support streaming tool use.
> More details can be found in the [Amazon Bedrock's Tool Use documentation](https://docs.aws.amazon.com/bedrock/latest/userguide/conversation-inference-supported-models-features.html).
To use Amazon Bedrock's models, an AWS authentication is required.
Ensure your credentials have the following permissions set up:
- `bedrock:InvokeModelWithResponseStream`
- `bedrock:InvokeModel`
Your IAM policy should look similar to:
```json [settings]
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"bedrock:InvokeModel",
"bedrock:InvokeModelWithResponseStream"
],
"Resource": "*"
}
]
}
```
With that done, choose one of the two authentication methods:
#### Authentication via Named Profile (Recommended)
1. Ensure you have the AWS CLI installed and configured with a named profile
2. Open your `settings.json` (`zed: open settings file`) and include the `bedrock` key under `language_models` with the following settings:
```json [settings]
{
"language_models": {
"bedrock": {
"authentication_method": "named_profile",
"region": "your-aws-region",
"profile": "your-profile-name"
}
}
}
```
#### Authentication via Static Credentials
While it's possible to configure through the Agent Panel settings UI by entering your AWS access key and secret directly, we recommend using named profiles instead for better security practices.
To do this:
1. Create an IAM User that you can assume in the [IAM Console](https://us-east-1.console.aws.amazon.com/iam/home?region=us-east-1#/users).
2. Create security credentials for that User, save them and keep them secure.
3. Open the Agent Configuration with (`agent: open settings`) and go to the Amazon Bedrock section
4. Copy the credentials from Step 2 into the respective **Access Key ID**, **Secret Access Key**, and **Region** fields.
#### Cross-Region Inference
The Zed implementation of Amazon Bedrock uses [Cross-Region inference](https://docs.aws.amazon.com/bedrock/latest/userguide/cross-region-inference.html) to improve availability and throughput.
With Cross-Region inference, you can distribute traffic across multiple AWS Regions, enabling higher throughput.
##### Regional vs Global Inference Profiles
Bedrock supports two types of cross-region inference profiles:
- **Regional profiles** (default): Route requests within a specific geography (US, EU, APAC). For example, `us-east-1` uses the `us.*` profile which routes across `us-east-1`, `us-east-2`, and `us-west-2`.
- **Global profiles**: Route requests across all commercial AWS Regions for maximum availability and performance.
By default, Zed uses **regional profiles** which keep your data within the same geography. You can opt into global profiles by adding `"allow_global": true` to your Bedrock configuration:
```json [settings]
{
"language_models": {
"bedrock": {
"authentication_method": "named_profile",
"region": "your-aws-region",
"profile": "your-profile-name",
"allow_global": true
}
}
}
```
**Note:** Only select newer models support global inference profiles. See the [AWS Bedrock supported models documentation](https://docs.aws.amazon.com/bedrock/latest/userguide/inference-profiles-support.html#inference-profiles-support-system) for the current list of models that support global inference. If you encounter availability issues with a model in your region, enabling `allow_global` may resolve them.
Although the data remains stored only in the source Region, your input prompts and output results might move outside of your source Region during cross-Region inference.
All data will be transmitted encrypted across Amazon's secure network.
We will support Cross-Region inference for each of the models on a best-effort basis, please refer to the [Cross-Region Inference method Code](https://github.com/zed-industries/zed/blob/main/crates/bedrock/src/models.rs#L297).
For the most up-to-date supported regions and models, refer to the [Supported Models and Regions for Cross Region inference](https://docs.aws.amazon.com/bedrock/latest/userguide/inference-profiles-support.html).
### Anthropic {#anthropic}
You can use Anthropic models by choosing them via the model dropdown in the Agent Panel.
1. Sign up for Anthropic and [create an API key](https://console.anthropic.com/settings/keys)
2. Make sure that your Anthropic account has credits
3. Open the settings view (`agent: open settings`) and go to the Anthropic section
4. Enter your Anthropic API key
Even if you pay for Claude Pro, you will still have to [pay for additional credits](https://console.anthropic.com/settings/plans) to use it via the API.
Zed will also use the `ANTHROPIC_API_KEY` environment variable if it's defined.
#### Custom Models {#anthropic-custom-models}
You can add custom models to the Anthropic provider by adding the following to your Zed `settings.json`:
```json [settings]
{
"language_models": {
"anthropic": {
"available_models": [
{
"name": "claude-3-5-sonnet-20240620",
"display_name": "Sonnet 2024-June",
"max_tokens": 128000,
"max_output_tokens": 2560,
"cache_configuration": {
"max_cache_anchors": 10,
"min_total_token": 10000,
"should_speculate": false
},
"tool_override": "some-model-that-supports-toolcalling"
}
]
}
}
}
```
Custom models will be listed in the model dropdown in the Agent Panel.
You can configure a model to use [extended thinking](https://docs.anthropic.com/en/docs/about-claude/models/extended-thinking-models) (if it supports it) by changing the mode in your model's configuration to `thinking`, for example:
```json [settings]
{
"name": "claude-sonnet-4-latest",
"display_name": "claude-sonnet-4-thinking",
"max_tokens": 200000,
"mode": {
"type": "thinking",
"budget_tokens": 4096
}
}
```
### DeepSeek {#deepseek}
1. Visit the DeepSeek platform and [create an API key](https://platform.deepseek.com/api_keys)
2. Open the settings view (`agent: open settings`) and go to the DeepSeek section
3. Enter your DeepSeek API key
The DeepSeek API key will be saved in your keychain.
Zed will also use the `DEEPSEEK_API_KEY` environment variable if it's defined.
#### Custom Models {#deepseek-custom-models}
The Zed agent comes pre-configured to use the latest version for common models (DeepSeek Chat, DeepSeek Reasoner).
If you wish to use alternate models or customize the API endpoint, you can do so by adding the following to your Zed `settings.json`:
```json [settings]
{
"language_models": {
"deepseek": {
"api_url": "https://api.deepseek.com",
"available_models": [
{
"name": "deepseek-chat",
"display_name": "DeepSeek Chat",
"max_tokens": 64000
},
{
"name": "deepseek-reasoner",
"display_name": "DeepSeek Reasoner",
"max_tokens": 64000,
"max_output_tokens": 4096
}
]
}
}
}
```
Custom models will be listed in the model dropdown in the Agent Panel.
You can also modify the `api_url` to use a custom endpoint if needed.
### GitHub Copilot Chat {#github-copilot-chat}
You can use GitHub Copilot Chat with the Zed agent by choosing it via the model dropdown in the Agent Panel.
1. Open the settings view (`agent: open settings`) and go to the GitHub Copilot Chat section
2. Click on `Sign in to use GitHub Copilot`, follow the steps shown in the modal.
Alternatively, you can provide an OAuth token via the `GH_COPILOT_TOKEN` environment variable.
> **Note**: If you don't see specific models in the dropdown, you may need to enable them in your [GitHub Copilot settings](https://github.com/settings/copilot/features).
To use Copilot Enterprise with Zed (for both agent and completions), you must configure your enterprise endpoint as described in [Configuring GitHub Copilot Enterprise](./edit-prediction.md#github-copilot-enterprise).
### Google AI {#google-ai}
You can use Gemini models with the Zed agent by choosing it via the model dropdown in the Agent Panel.
1. Go to the Google AI Studio site and [create an API key](https://aistudio.google.com/app/apikey).
2. Open the settings view (`agent: open settings`) and go to the Google AI section
3. Enter your Google AI API key and press enter.
The Google AI API key will be saved in your keychain.
Zed will also use the `GEMINI_API_KEY` environment variable if it's defined. See [Using Gemini API keys](https://ai.google.dev/gemini-api/docs/api-key) in the Gemini docs for more.
#### Custom Models {#google-ai-custom-models}
By default, Zed will use `stable` versions of models, but you can use specific versions of models, including [experimental models](https://ai.google.dev/gemini-api/docs/models/experimental-models). You can configure a model to use [thinking mode](https://ai.google.dev/gemini-api/docs/thinking) (if it supports it) by adding a `mode` configuration to your model. This is useful for controlling reasoning token usage and response speed. If not specified, Gemini will automatically choose the thinking budget.
Here is an example of a custom Google AI model you could add to your Zed `settings.json`:
```json [settings]
{
"language_models": {
"google": {
"available_models": [
{
"name": "gemini-2.5-flash-preview-05-20",
"display_name": "Gemini 2.5 Flash (Thinking)",
"max_tokens": 1000000,
"mode": {
"type": "thinking",
"budget_tokens": 24000
}
}
]
}
}
}
```
Custom models will be listed in the model dropdown in the Agent Panel.
### LM Studio {#lmstudio}
1. Download and install [the latest version of LM Studio](https://lmstudio.ai/download)
2. In the app press `cmd/ctrl-shift-m` and download at least one model (e.g., qwen2.5-coder-7b). Alternatively, you can get models via the LM Studio CLI:
```sh
lms get qwen2.5-coder-7b
```
3. Make sure the LM Studio API server is running by executing:
```sh
lms server start
```
Tip: Set [LM Studio as a login item](https://lmstudio.ai/docs/advanced/headless#run-the-llm-service-on-machine-login) to automate running the LM Studio server.
### Mistral {#mistral}
1. Visit the Mistral platform and [create an API key](https://console.mistral.ai/api-keys/)
2. Open the configuration view (`agent: open settings`) and navigate to the Mistral section
3. Enter your Mistral API key
The Mistral API key will be saved in your keychain.
Zed will also use the `MISTRAL_API_KEY` environment variable if it's defined.
#### Custom Models {#mistral-custom-models}
The Zed agent comes pre-configured with several Mistral models (codestral-latest, mistral-large-latest, mistral-medium-latest, mistral-small-latest, open-mistral-nemo, and open-codestral-mamba).
All the default models support tool use.
If you wish to use alternate models or customize their parameters, you can do so by adding the following to your Zed `settings.json`:
```json [settings]
{
"language_models": {
"mistral": {
"api_url": "https://api.mistral.ai/v1",
"available_models": [
{
"name": "mistral-tiny-latest",
"display_name": "Mistral Tiny",
"max_tokens": 32000,
"max_output_tokens": 4096,
"max_completion_tokens": 1024,
"supports_tools": true,
"supports_images": false
}
]
}
}
}
```
Custom models will be listed in the model dropdown in the Agent Panel.
### Ollama {#ollama}
Download and install Ollama from [ollama.com/download](https://ollama.com/download) (Linux or macOS) and ensure it's running with `ollama --version`.
1. Download one of the [available models](https://ollama.com/models), for example, for `mistral`:
```sh
ollama pull mistral
```
2. Make sure that the Ollama server is running. You can start it either via running Ollama.app (macOS) or launching:
```sh
ollama serve
```
3. In the Agent Panel, select one of the Ollama models using the model dropdown.
#### Ollama Context Length {#ollama-context}
Zed has pre-configured maximum context lengths (`max_tokens`) to match the capabilities of common models.
Zed API requests to Ollama include this as the `num_ctx` parameter, but the default values do not exceed `16384` so users with ~16GB of RAM are able to use most models out of the box.
See [get_max_tokens in ollama.rs](https://github.com/zed-industries/zed/blob/main/crates/ollama/src/ollama.rs) for a complete set of defaults.
> **Note**: Token counts displayed in the Agent Panel are only estimates and will differ from the model's native tokenizer.
Depending on your hardware or use-case you may wish to limit or increase the context length for a specific model via settings.json:
```json [settings]
{
"language_models": {
"ollama": {
"api_url": "http://localhost:11434",
"available_models": [
{
"name": "qwen2.5-coder",
"display_name": "qwen 2.5 coder 32K",
"max_tokens": 32768,
"supports_tools": true,
"supports_thinking": true,
"supports_images": true
}
]
}
}
}
```
If you specify a context length that is too large for your hardware, Ollama will log an error.
You can watch these logs by running: `tail -f ~/.ollama/logs/ollama.log` (macOS) or `journalctl -u ollama -f` (Linux).
Depending on the memory available on your machine, you may need to adjust the context length to a smaller value.
You may also optionally specify a value for `keep_alive` for each available model.
This can be an integer (seconds) or alternatively a string duration like "5m", "10m", "1h", "1d", etc.
For example, `"keep_alive": "120s"` will allow the remote server to unload the model (freeing up GPU VRAM) after 120 seconds.
The `supports_tools` option controls whether the model will use additional tools.
If the model is tagged with `tools` in the Ollama catalog, this option should be supplied, and the built-in profiles `Ask` and `Write` can be used.
If the model is not tagged with `tools` in the Ollama catalog, this option can still be supplied with the value `true`; however, be aware that only the `Minimal` built-in profile will work.
The `supports_thinking` option controls whether the model will perform an explicit "thinking" (reasoning) pass before producing its final answer.
If the model is tagged with `thinking` in the Ollama catalog, set this option and you can use it in Zed.
The `supports_images` option enables the model's vision capabilities, allowing it to process images included in the conversation context.
If the model is tagged with `vision` in the Ollama catalog, set this option and you can use it in Zed.
#### Ollama Authentication
In addition to running Ollama on your own hardware, which generally does not require authentication, Zed also supports connecting to remote Ollama instances. API keys are required for authentication.
One such service is [Ollama Turbo])(https://ollama.com/turbo). To configure Zed to use Ollama turbo:
1. Sign in to your Ollama account and subscribe to Ollama Turbo
2. Visit [ollama.com/settings/keys](https://ollama.com/settings/keys) and create an API key
3. Open the settings view (`agent: open settings`) and go to the Ollama section
4. Paste your API key and press enter.
5. For the API URL enter `https://ollama.com`
Zed will also use the `OLLAMA_API_KEY` environment variables if defined.
### OpenAI {#openai}
1. Visit the OpenAI platform and [create an API key](https://platform.openai.com/account/api-keys)
2. Make sure that your OpenAI account has credits
3. Open the settings view (`agent: open settings`) and go to the OpenAI section
4. Enter your OpenAI API key
The OpenAI API key will be saved in your keychain.
Zed will also use the `OPENAI_API_KEY` environment variable if it's defined.
#### Custom Models {#openai-custom-models}
The Zed agent comes pre-configured to use the latest version for common models (GPT-5, GPT-5 mini, o4-mini, GPT-4.1, and others).
To use alternate models, perhaps a preview release, or if you wish to control the request parameters, you can do so by adding the following to your Zed `settings.json`:
```json [settings]
{
"language_models": {
"openai": {
"available_models": [
{
"name": "gpt-5",
"display_name": "gpt-5 high",
"reasoning_effort": "high",
"max_tokens": 272000,
"max_completion_tokens": 20000
},
{
"name": "gpt-4o-2024-08-06",
"display_name": "GPT 4o Summer 2024",
"max_tokens": 128000
}
]
}
}
}
```
You must provide the model's context window in the `max_tokens` parameter; this can be found in the [OpenAI model documentation](https://platform.openai.com/docs/models).
OpenAI `o1` models should set `max_completion_tokens` as well to avoid incurring high reasoning token costs.
Custom models will be listed in the model dropdown in the Agent Panel.
### OpenAI API Compatible {#openai-api-compatible}
Zed supports using [OpenAI compatible APIs](https://platform.openai.com/docs/api-reference/chat) by specifying a custom `api_url` and `available_models` for the OpenAI provider.
This is useful for connecting to other hosted services (like Together AI, Anyscale, etc.) or local models.
You can add a custom, OpenAI-compatible model either via the UI or by editing your `settings.json`.
To do it via the UI, go to the Agent Panel settings (`agent: open settings`) and look for the "Add Provider" button to the right of the "LLM Providers" section title.
Then, fill up the input fields available in the modal.
To do it via your `settings.json`, add the following snippet under `language_models`:
```json [settings]
{
"language_models": {
"openai_compatible": {
// Using Together AI as an example
"Together AI": {
"api_url": "https://api.together.xyz/v1",
"available_models": [
{
"name": "mistralai/Mixtral-8x7B-Instruct-v0.1",
"display_name": "Together Mixtral 8x7B",
"max_tokens": 32768,
"capabilities": {
"tools": true,
"images": false,
"parallel_tool_calls": false,
"prompt_cache_key": false
}
}
]
}
}
}
}
```
By default, OpenAI-compatible models inherit the following capabilities:
- `tools`: true (supports tool/function calling)
- `images`: false (does not support image inputs)
- `parallel_tool_calls`: false (does not support `parallel_tool_calls` parameter)
- `prompt_cache_key`: false (does not support `prompt_cache_key` parameter)
Note that LLM API keys aren't stored in your settings file.
So, ensure you have it set in your environment variables (`<PROVIDER_NAME>_API_KEY=<your api key>`) so your settings can pick it up. In the example above, it would be `TOGETHER_AI_API_KEY=<your api key>`.
### OpenRouter {#openrouter}
OpenRouter provides access to multiple AI models through a single API. It supports tool use for compatible models.
1. Visit [OpenRouter](https://openrouter.ai) and create an account
2. Generate an API key from your [OpenRouter keys page](https://openrouter.ai/keys)
3. Open the settings view (`agent: open settings`) and go to the OpenRouter section
4. Enter your OpenRouter API key
The OpenRouter API key will be saved in your keychain.
Zed will also use the `OPENROUTER_API_KEY` environment variable if it's defined.
#### Custom Models {#openrouter-custom-models}
You can add custom models to the OpenRouter provider by adding the following to your Zed `settings.json`:
```json [settings]
{
"language_models": {
"open_router": {
"api_url": "https://openrouter.ai/api/v1",
"available_models": [
{
"name": "google/gemini-2.0-flash-thinking-exp",
"display_name": "Gemini 2.0 Flash (Thinking)",
"max_tokens": 200000,
"max_output_tokens": 8192,
"supports_tools": true,
"supports_images": true,
"mode": {
"type": "thinking",
"budget_tokens": 8000
}
}
]
}
}
}
```
The available configuration options for each model are:
- `name` (required): The model identifier used by OpenRouter
- `display_name` (optional): A human-readable name shown in the UI
- `max_tokens` (required): The model's context window size
- `max_output_tokens` (optional): Maximum tokens the model can generate
- `max_completion_tokens` (optional): Maximum completion tokens
- `supports_tools` (optional): Whether the model supports tool/function calling
- `supports_images` (optional): Whether the model supports image inputs
- `mode` (optional): Special mode configuration for thinking models
You can find available models and their specifications on the [OpenRouter models page](https://openrouter.ai/models).
Custom models will be listed in the model dropdown in the Agent Panel.
#### Provider Routing
You can optionally control how OpenRouter routes a given custom model request among underlying upstream providers via the `provider` object on each model entry.
Supported fields (all optional):
- `order`: Array of provider slugs to try first, in order (e.g. `["anthropic", "openai"]`)
- `allow_fallbacks` (default: `true`): Whether fallback providers may be used if preferred ones are unavailable
- `require_parameters` (default: `false`): Only use providers that support every parameter you supplied
- `data_collection` (default: `allow`): `"allow"` or `"disallow"` (controls use of providers that may store data)
- `only`: Whitelist of provider slugs allowed for this request
- `ignore`: Provider slugs to skip
- `quantizations`: Restrict to specific quantization variants (e.g. `["int4","int8"]`)
- `sort`: Sort strategy for candidate providers (e.g. `"price"` or `"throughput"`)
Example adding routing preferences to a model:
```json [settings]
{
"language_models": {
"open_router": {
"api_url": "https://openrouter.ai/api/v1",
"available_models": [
{
"name": "openrouter/auto",
"display_name": "Auto Router (Tools Preferred)",
"max_tokens": 2000000,
"supports_tools": true,
"provider": {
"order": ["anthropic", "openai"],
"allow_fallbacks": true,
"require_parameters": true,
"only": ["anthropic", "openai", "google"],
"ignore": ["cohere"],
"quantizations": ["int8"],
"sort": "price",
"data_collection": "allow"
}
}
]
}
}
}
```
These routing controls let you fine‑tune cost, capability, and reliability trade‑offs without changing the model name you select in the UI.
### Vercel v0 {#vercel-v0}
[Vercel v0](https://v0.app/docs/api/model) is an expert model for generating full-stack apps, with framework-aware completions optimized for modern stacks like Next.js and Vercel.
It supports text and image inputs and provides fast streaming responses.
The v0 models are [OpenAI-compatible models](/#openai-api-compatible), but Vercel is listed as first-class provider in the panel's settings view.
To start using it with Zed, ensure you have first created a [v0 API key](https://v0.dev/chat/settings/keys).
Once you have it, paste it directly into the Vercel provider section in the panel's settings view.
You should then find it as `v0-1.5-md` in the model dropdown in the Agent Panel.
### xAI {#xai}
Zed has first-class support for [xAI](https://x.ai/) models. You can use your own API key to access Grok models.
1. [Create an API key in the xAI Console](https://console.x.ai/team/default/api-keys)
2. Open the settings view (`agent: open settings`) and go to the **xAI** section
3. Enter your xAI API key
The xAI API key will be saved in your keychain. Zed will also use the `XAI_API_KEY` environment variable if it's defined.
> **Note:** While the xAI API is OpenAI-compatible, Zed has first-class support for it as a dedicated provider. For the best experience, we recommend using the dedicated `x_ai` provider configuration instead of the [OpenAI API Compatible](#openai-api-compatible) method.
#### Custom Models {#xai-custom-models}
The Zed agent comes pre-configured with common Grok models. If you wish to use alternate models or customize their parameters, you can do so by adding the following to your Zed `settings.json`:
```json [settings]
{
"language_models": {
"x_ai": {
"api_url": "https://api.x.ai/v1",
"available_models": [
{
"name": "grok-1.5",
"display_name": "Grok 1.5",
"max_tokens": 131072,
"max_output_tokens": 8192
},
{
"name": "grok-1.5v",
"display_name": "Grok 1.5V (Vision)",
"max_tokens": 131072,
"max_output_tokens": 8192,
"supports_images": true
}
]
}
}
}
```
## Custom Provider Endpoints {#custom-provider-endpoint}
You can use a custom API endpoint for different providers, as long as it's compatible with the provider's API structure.
To do so, add the following to your `settings.json`:
```json [settings]
{
"language_models": {
"some-provider": {
"api_url": "http://localhost:11434"
}
}
}
```
Currently, `some-provider` can be any of the following values: `anthropic`, `google`, `ollama`, `openai`.
This is the same infrastructure that powers models that are, for example, [OpenAI-compatible](#openai-api-compatible).
docs/src/ai/mcp.md
-139
View File
@@ -1,139 +0,0 @@
# Model Context Protocol
Zed uses the [Model Context Protocol](https://modelcontextprotocol.io/) to interact with context servers.
> The Model Context Protocol (MCP) is an open protocol that enables seamless integration between LLM applications and external data sources and tools. Whether you're building an AI-powered IDE, enhancing a chat interface, or creating custom AI workflows, MCP provides a standardized way to connect LLMs with the context they need.
Check out the [Anthropic news post](https://www.anthropic.com/news/model-context-protocol) and the [Zed blog post](https://zed.dev/blog/mcp) for a general intro to MCP.
## Installing MCP Servers
### As Extensions
One of the ways you can use MCP servers in Zed is by exposing them as an extension.
Check out the [MCP Server Extensions](../extensions/mcp-extensions.md) page to learn how to create your own.
Thanks to our awesome community, many MCP servers have already been added as extensions.
You can check which ones are available via any of these routes:
1. [the Zed website](https://zed.dev/extensions?filter=context-servers)
2. in the app, open the Command Palette and run the `zed: extensions` action
3. in the app, go to the Agent Panel's top-right menu and look for the "View Server Extensions" menu item
In any case, here are some popular available servers:
- [Context7](https://zed.dev/extensions/context7-mcp-server)
- [GitHub](https://zed.dev/extensions/github-mcp-server)
- [Puppeteer](https://zed.dev/extensions/puppeteer-mcp-server)
- [Gem](https://zed.dev/extensions/gem)
- [Brave Search](https://zed.dev/extensions/brave-search-mcp-server)
- [Prisma](https://github.com/aqrln/prisma-mcp-zed)
- [Framelink Figma](https://zed.dev/extensions/framelink-figma-mcp-server)
- [Linear](https://zed.dev/extensions/linear-mcp-server)
- [Resend](https://zed.dev/extensions/resend-mcp-server)
### As Custom Servers
Creating an extension is not the only way to use MCP servers in Zed.
You can connect them by adding their commands directly to your `settings.json`, like so:
```json [settings]
{
"context_servers": {
"local-mcp-server": {
"command": "some-command",
"args": ["arg-1", "arg-2"],
"env": {}
},
"remote-mcp-server": {
"url": "custom",
"headers": { "Authorization": "Bearer <token>" }
}
}
}
```
Alternatively, you can also add a custom server by accessing the Agent Panel's Settings view (also accessible via the `agent: open settings` action).
From there, you can add it through the modal that appears when you click the "Add Custom Server" button.
## Using MCP Servers
### Configuration Check
Regardless of how you've installed MCP servers, whether as an extension or adding them directly, most servers out there still require some sort of configuration as part of the setup process.
In the case of extensions, after installing it, Zed will pop up a modal displaying what is required for you to properly set it up.
For example, the GitHub MCP extension requires you to add a [Personal Access Token](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens).
In the case of custom servers, make sure you check the provider documentation to determine what type of command, arguments, and environment variables need to be added to the JSON.
To check if your MCP server is properly configured, go to the Agent Panel's settings view and watch the indicator dot next to its name.
If they're running correctly, the indicator will be green and its tooltip will say "Server is active".
If not, other colors and tooltip messages will indicate what is happening.
### Agent Panel Usage
Once installation is complete, you can return to the Agent Panel and start prompting.
Some models are better than others when it comes to picking up tools from MCP servers.
Mentioning your server by name always helps the model to pick it up.
However, if you want to _ensure_ a given MCP server will be used, you can create [a custom profile](./agent-panel.md#custom-profiles) where all built-in tools (or the ones that could cause conflicts with the server's tools) are turned off and only the tools coming from the MCP server are turned on.
As an example, [the Dagger team suggests](https://container-use.com/agent-integrations#zed) doing that with their [Container Use MCP server](https://zed.dev/extensions/mcp-server-container-use):
```json [settings]
"agent": {
"profiles": {
"container-use": {
"name": "Container Use",
"tools": {
"fetch": true,
"thinking": true,
"copy_path": false,
"find_path": false,
"delete_path": false,
"create_directory": false,
"list_directory": false,
"diagnostics": false,
"read_file": false,
"open": false,
"move_path": false,
"grep": false,
"edit_file": false,
"terminal": false
},
"enable_all_context_servers": false,
"context_servers": {
"container-use": {
"tools": {
"environment_create": true,
"environment_add_service": true,
"environment_update": true,
"environment_run_cmd": true,
"environment_open": true,
"environment_file_write": true,
"environment_file_read": true,
"environment_file_list": true,
"environment_file_delete": true,
"environment_checkpoint": true
}
}
}
}
}
}
```
### Tool Approval
Zed's Agent Panel includes the `agent.always_allow_tool_actions` setting that, if set to `false`, will require you to give permission for any editing attempt as well as tool calls coming from MCP servers.
You can change this by setting this key to `true` in either your `settings.json` or through the Agent Panel's settings view.
### External Agents
Note that for [external agents](./external-agents.md) connected through the [Agent Client Protocol](https://agentclientprotocol.com/), access to MCP servers installed from Zed may vary depending on the ACP agent implementation.
Regarding the built-in ones, Claude Code and Codex both support it, and Gemini CLI does not yet.
In the meantime, learn how to add MCP server support to Gemini CLI through [their documentation](https://github.com/google-gemini/gemini-cli?tab=readme-ov-file#using-mcp-servers).
docs/src/ai/models.md
-93
View File
@@ -1,93 +0,0 @@
# Models
Zed’s plans offer hosted versions of major LLMs, generally with higher rate limits than using your API keys.
We’re working hard to expand the models supported by Zed’s subscription offerings, so please check back often.
| Model | Provider | Token Type | Provider Price per 1M tokens | Zed Price per 1M tokens |
| ---------------------- | --------- | ------------------- | ---------------------------- | ----------------------- |
| Claude Opus 4.5 | Anthropic | Input | $5.00 | $5.50 |
| | Anthropic | Output | $25.00 | $27.50 |
| | Anthropic | Input - Cache Write | $6.25 | $6.875 |
| | Anthropic | Input - Cache Read | $0.50 | $0.55 |
| Claude Opus 4.1 | Anthropic | Input | $15.00 | $16.50 |
| | Anthropic | Output | $75.00 | $82.50 |
| | Anthropic | Input - Cache Write | $18.75 | $20.625 |
| | Anthropic | Input - Cache Read | $1.50 | $1.65 |
| Claude Sonnet 4.5 | Anthropic | Input | $3.00 | $3.30 |
| | Anthropic | Output | $15.00 | $16.50 |
| | Anthropic | Input - Cache Write | $3.75 | $4.125 |
| | Anthropic | Input - Cache Read | $0.30 | $0.33 |
| Claude Sonnet 4 | Anthropic | Input | $3.00 | $3.30 |
| | Anthropic | Output | $15.00 | $16.50 |
| | Anthropic | Input - Cache Write | $3.75 | $4.125 |
| | Anthropic | Input - Cache Read | $0.30 | $0.33 |
| Claude Sonnet 3.7 | Anthropic | Input | $3.00 | $3.30 |
| | Anthropic | Output | $15.00 | $16.50 |
| | Anthropic | Input - Cache Write | $3.75 | $4.125 |
| | Anthropic | Input - Cache Read | $0.30 | $0.33 |
| Claude Haiku 4.5 | Anthropic | Input | $1.00 | $1.10 |
| | Anthropic | Output | $5.00 | $5.50 |
| | Anthropic | Input - Cache Write | $1.25 | $1.375 |
| | Anthropic | Input - Cache Read | $0.10 | $0.11 |
| GPT-5 | OpenAI | Input | $1.25 | $1.375 |
| | OpenAI | Output | $10.00 | $11.00 |
| | OpenAI | Cached Input | $0.125 | $0.1375 |
| GPT-5 mini | OpenAI | Input | $0.25 | $0.275 |
| | OpenAI | Output | $2.00 | $2.20 |
| | OpenAI | Cached Input | $0.025 | $0.0275 |
| GPT-5 nano | OpenAI | Input | $0.05 | $0.055 |
| | OpenAI | Output | $0.40 | $0.44 |
| | OpenAI | Cached Input | $0.005 | $0.0055 |
| Gemini 3.0 Pro | Google | Input | $2.00 | $2.20 |
| | Google | Output | $12.00 | $13.20 |
| Gemini 2.5 Pro | Google | Input | $1.25 | $1.375 |
| | Google | Output | $10.00 | $11.00 |
| Gemini 2.5 Flash | Google | Input | $0.30 | $0.33 |
| | Google | Output | $2.50 | $2.75 |
| Grok 4 | X.ai | Input | $3.00 | $3.30 |
| | X.ai | Output | $15.00 | $16.5 |
| | X.ai | Cached Input | $0.75 | $0.825 |
| Grok 4 Fast | X.ai | Input | $0.20 | $0.22 |
| | X.ai | Output | $0.50 | $0.55 |
| | X.ai | Cached Input | $0.05 | $0.055 |
| Grok 4 (Non-Reasoning) | X.ai | Input | $0.20 | $0.22 |
| | X.ai | Output | $0.50 | $0.55 |
| | X.ai | Cached Input | $0.05 | $0.055 |
| Grok Code Fast 1 | X.ai | Input | $0.20 | $0.22 |
| | X.ai | Output | $1.50 | $1.65 |
| | X.ai | Cached Input | $0.02 | $0.022 |
## Usage {#usage}
Any usage of a Zed-hosted model will be billed at the Zed Price (rightmost column above). See [Plans and Usage](./plans-and-usage.md) for details on Zed's plans and limits for use of hosted models.
> We encourage you to think through what model is best for your needs before leaving the Agent Panel to work. All LLMs can "spiral" and occasionally enter unending loops that require user intervention.
## Context Windows {#context-windows}
A context window is the maximum span of text and code an LLM can consider at once, including both the input prompt and output generated by the model.
| Model | Provider | Zed-Hosted Context Window |
| ----------------- | --------- | ------------------------- |
| Claude Opus 4.5 | Anthropic | 200k |
| Claude Opus 4.1 | Anthropic | 200k |
| Claude Sonnet 4 | Anthropic | 200k |
| Claude Sonnet 3.7 | Anthropic | 200k |
| Claude Haiku 4.5 | Anthropic | 200k |
| GPT-5 | OpenAI | 400k |
| GPT-5 mini | OpenAI | 400k |
| GPT-5 nano | OpenAI | 400k |
| Gemini 2.5 Pro | Google | 200k |
| Gemini 2.5 Flash | Google | 200k |
| Gemini 3.0 Pro | Google | 200k |
> We're planning on expanding supported context windows for hosted Sonnet 4 and Gemini 2.5 Pro/Flash in the near future. Stay tuned!
Each Agent thread and text thread in Zed maintains its own context window.
The more prompts, attached files, and responses included in a session, the larger the context window grows.
For best results, it’s recommended you take a purpose-based approach to Agent thread management, starting a new thread for each unique task.
## Tool Calls {#tool-calls}
Models can use [tools](./tools.md) to interface with your code, search the web, and perform other useful functions.
docs/src/ai/overview.md
-33
View File
@@ -1,33 +0,0 @@
# AI
Learn how to get started using AI with Zed and all its capabilities.
## Setting up AI in Zed
- [Configuration](./configuration.md): Learn how to set up different language model providers like Anthropic, OpenAI, Ollama, Google AI, and more.
- [External Agents](./external-agents.md): Learn how to plug in your favorite agent into Zed.
- [Subscription](./subscription.md): Learn about Zed's hosted models and other billing-related information.
- [Privacy and Security](./privacy-and-security.md): Understand how Zed handles privacy and security with AI features.
## Agentic Editing
- [Agent Panel](./agent-panel.md): Create and manage interactions with LLM agents.
- [Rules](./rules.md): How to define rules for AI interactions.
- [Tools](./tools.md): Explore the tools that power Zed's built-in agent.
- [Model Context Protocol](./mcp.md): Learn about how to configure and use MCP servers.
- [Inline Assistant](./inline-assistant.md): Discover how to use AI to generate inline transformations directly within a file or terminal.
## Edit Prediction
- [Edit Prediction](./edit-prediction.md): Learn about Zed's AI prediction feature that helps autocomplete your code.
## Text Threads
- [Text Threads](./text-threads.md): Learn about an editor-based interface for interacting with language models.
docs/src/ai/plans-and-usage.md
-31
View File
@@ -1,31 +0,0 @@
# Plans and Usage
## Available Plans {#plans}
For costs and more information on pricing, visit [Zed’s pricing page](https://zed.dev/pricing).
Please note that if you’re interested in just using Zed as the world’s fastest editor, with no AI or subscription features, you can always do so for free, without [authentication](../authentication.md).
## Usage {#usage}
Usage of Zed's hosted models is measured on a token basis, converted to dollars at the rates lists on [the Models page](./models.md) (list price from the provider, +10%).
Zed Pro comes with $5 of monthly dollar credit. A trial of Zed Pro includes $20 of credit, usable for 14 days. Monthly included credit resets on your monthly billing date.
To view your current usage, you can visit your account at [zed.dev/account](https://zed.dev/account). Information from our metering and billing provider, Orb, is embedded on that page.
## Spend Limits {#usage-spend-limits}
At the top of [the Account page](https://zed.dev/account), you'll find an input for `Maximum Token Spend`. The dollar amount here specifies your _monthly_ limit for spend on tokens, _not counting_ the $5/month included with your Pro subscription.
The default value for all Pro users is $10, for a total monthly spend with Zed of $20 ($10 for your Pro subscription, $10 in incremental token spend). This can be set to $0 to limit your spend with Zed to exactly $10/month. If you adjust this limit _higher_ than $10 and consume more than $10 of incremental token spend, you'll be billed via [threshold billing](./billing.md#threshold-billing).
Once the spend limit is hit, we’ll stop any further usage until your token spend limit resets.
## Business Usage {#business-usage}
Email [sales@zed.dev](mailto:sales@zed.dev) with any questions on business plans.
## Trials {#trials}
Note that trials will automatically convert to Zed Free plans on termination, and no cancellation is needed to prevent conversion to Zed Pro.
docs/src/ai/privacy-and-security.md
-29
View File
@@ -1,29 +0,0 @@
# Privacy and Security
## Philosophy
Zed aims to collect on the minimum data necessary to serve and improve our product.
We believe in opt-in data sharing as the default in building AI products, rather than opt-out, like most of our competitors. Privacy Mode is not a setting to be toggled, it's a default stance.
As an open-source product, we believe in maximal transparency, and invite you to examine our codebase. If you find issues, we encourage you to share them with us.
It is entirely possible to use Zed, including Zed's AI capabilities, without sharing any data with us and without authenticating into the product. We're happy to always support this desired use pattern.
## Documentation
- [Telemetry](../telemetry.md): How Zed collects general telemetry data.
- [AI Improvement](./ai-improvement.md): Zed's opt-in-only approach to data collection for AI improvement, whether our Agentic offering or Edit Predictions.
- [Accounts](../authentication.md): When and why you'd need to authenticate into Zed, how to do so, and what scope we need from you.
- [Collab](https://zed.dev/faq#data-and-privacy): How Zed's live collaboration works, and how data flows to provide the experience (we don't store your code!).
## Legal Links
- [Terms of Service](https://zed.dev/terms-of-service)
- [Terms of Use](https://zed.dev/terms)
- [Privacy Policy](https://zed.dev/privacy-policy)
- [Zed's Contributor License and Feedback Agreement](https://zed.dev/cla)
- [Subprocessors](https://zed.dev/subprocessors)
docs/src/ai/rules.md
-75
View File
@@ -1,75 +0,0 @@
# Using Rules {#using-rules}
A rule is essentially a prompt that is inserted at the beginning of each interaction with the Agent.
Currently, Zed supports adding rules through files inserted directly in the worktree or through the Rules Library, which allows you to store multiple rules for constant or on-demand usage.
## `.rules` files
Zed supports including `.rules` files at the top level of worktrees, and they act as project-level instructions that are included in all of your interactions with the Agent Panel.
Other names for this file are also supported for compatibility with other agents, but note that the first file which matches in this list will be used:
- `.rules`
- `.cursorrules`
- `.windsurfrules`
- `.clinerules`
- `.github/copilot-instructions.md`
- `AGENT.md`
- `AGENTS.md`
- `CLAUDE.md`
- `GEMINI.md`
## Rules Library {#rules-library}
The Rules Library is an interface for writing and managing rules. Like other text-driven UIs in Zed, it is a full editor with syntax highlighting, keyboard shortcuts, etc.
You can use the inline assistant right in the rules editor, allowing you to automate and rewrite rules.
### Opening the Rules Library
1. Open the Agent Panel.
2. Click on the Agent menu (`...`) in the top right corner.
3. Select `Rules...` from the dropdown.
You can also reach it by running {#action agent::OpenRulesLibrary} in the command palette or through the {#kb agent::OpenRulesLibrary} keybinding.
### Managing Rules
Once a rules file is selected, you can edit it directly in the built-in editor. Its title can be changed from the editor title bar as well.
Rules can be duplicated, deleted, or added to the default rules using the buttons in the rules editor.
### Creating Rules {#creating-rules}
To create a rule file, simply open the `Rules Library` and click the `+` button. Rules files are stored locally and can be accessed from the library at any time.
Having a series of rules files specifically tailored to prompt engineering can also help you write consistent and effective rules.
Here are a couple of helpful resources for writing better rules:
- [Anthropic: Prompt Engineering](https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview)
- [OpenAI: Prompt Engineering](https://platform.openai.com/docs/guides/prompt-engineering)
### Editing the Default Rules {#default-rules}
Zed allows you to customize the default rules used when interacting with LLMs.
Or to be more precise, it uses a series of rules that are combined to form the default rules.
Default rules are included in the context of every new thread automatically.
You can also manually add other rules (that are not flagged as default) as context using the `@rule` command.
## Migrating from Prompt Library
Previously, the Rules Library was called the "Prompt Library".
The new rules system replaces the Prompt Library except in a few specific cases, which are outlined below.
### Slash Commands in Rules
Previously, it was possible to use slash commands (now @-mentions) in custom prompts (now rules).
There is currently no support for using @-mentions in rules files, however, slash commands are supported in rules files when used with text threads.
See the documentation for using [slash commands in rules](./text-threads.md#slash-commands-in-rules) for more information.
### Prompt templates
Zed maintains backwards compatibility with its original template system, which allows you to customize prompts used throughout the application, including the inline assistant.
While the Rules Library is now the primary way to manage prompts, you can still use these legacy templates to override default prompts.
For more details, see the [Rules Templates](./text-threads.md#rule-templates) section under [Text Threads](./text-threads.md).
docs/src/ai/subscription.md
-13
View File
@@ -1,13 +0,0 @@
# Subscription
Zed's hosted models are offered via subscription to Zed Pro or Zed Business.
> Using [your own API keys](./llm-providers.md), and [external agents](./external-agents.md), is _free_ — you do not need to subscribe to a Zed plan to use AI features.
See the following pages for specific aspects of our subscription offering:
- [Models](./models.md): Overview of the models offered by Zed's subscriptions.
- [Plans and Usage](./plans-and-usage.md): Outlines Zed's plans and how usage is measured.
- [Billing](./billing.md): Billing policies and procedures, and how to update or view various billing settings.
docs/src/ai/text-threads.md
-291
View File
@@ -1,291 +0,0 @@
# Text Threads
## Overview {#overview}
Text threads in the [Agent Panel](./agent-panel.md) function similarly to any other editor.
You can use custom key bindings and work with multiple cursors, allowing for seamless transitions between coding and engaging in discussions with the language models.
However, the text threads differ in the inclusion of message blocks.
These blocks serve as containers for text that correspond to different roles within the context.
These roles include:
- `You`
- `Assistant`
- `System`
To begin, type a message in a `You` block.
![Asking a question](https://zed.dev/img/assistant/ask-a-question.png)
As you type, the remaining tokens count for the selected model is updated.
Inserting text from an editor is as simple as highlighting the text and running `agent: add selection to thread` ({#kb agent::AddSelectionToThread}); Zed will wrap it in a fenced code block if it is code.
![Quoting a selection](https://zed.dev/img/assistant/quoting-a-selection.png)
To submit a message, use {#kb assistant::Assist}(`assistant: assist`).
Unlike normal threads, where pressing <kbd>enter</kbd> would submit the message, in text threads, our goal is to make it feel as close to a regular editor as possible.
So, pressing {#kb editor::Newline} simply inserts a new line.
After submitting a message, the response will be streamed below, in an `Assistant` message block.
![Receiving an answer](https://zed.dev/img/assistant/receiving-an-answer.png)
The stream can be canceled at any point with <kbd>escape</kbd>.
This is useful if you realize early on that the response is not what you were looking for.
If you want to start a new conversation at any time, you can hit <kbd>cmd-n|ctrl-n</kbd> or use the `New Chat` menu option in the hamburger menu at the top left of the panel.
Simple back-and-forth conversations work well with the text threads.
However, there may come a time when you want to modify the previous text in the conversation and steer it in a different direction.
## Editing a Text Thread {#edit-text-thread}
Text threads give you the flexibility to have control over the context.
You can freely edit any previous text, including the responses from the LLM.
If you want to remove a message block entirely, simply place your cursor at the beginning of the block and use the `delete` key.
A typical workflow might involve making edits and adjustments throughout the context to refine your inquiry or provide additional information.
Here's an example:
1. Write text in a `You` block.
2. Submit the message with {#kb assistant::Assist}.
3. Receive an `Assistant` response that doesn't meet your expectations.
4. Cancel the response with <kbd>escape</kbd>.
5. Erase the content of the `Assistant` message block and remove the block entirely.
6. Add additional context to your original message.
7. Submit the message with {#kb assistant::Assist}.
Being able to edit previous messages gives you control over how tokens are used.
You don't need to start up a new chat to correct a mistake or to add additional information, and you don't have to waste tokens by submitting follow-up corrections.
> **Note**: The act of editing past messages is often referred to as "Rewriting History" in the context of the language models.
Some additional points to keep in mind:
- You can cycle the role of a message block by clicking on the role, which is useful when you receive a response in an `Assistant` block that you want to edit and send back up as a `You` block.
## Commands Overview {#commands}
Slash commands enhance the assistant's capabilities.
Begin by typing a `/` at the beginning of the line to see a list of available commands:
- `/default`: Inserts the default rule
- `/diagnostics`: Injects errors reported by the project's language server
- `/fetch`: Fetches the content of a webpage and inserts it
- `/file`: Inserts a single file or a directory of files
- `/now`: Inserts the current date and time
- `/prompt`: Adds a custom-configured prompt to the context ([see Rules Library](./rules.md#rules-library))
- `/symbols`: Inserts the current tab's active symbols
- `/tab`: Inserts the content of the active tab or all open tabs
- `/terminal`: Inserts a select number of lines of output from the terminal
- `/selection`: Inserts the selected text
> **Note:** Remember, commands are only evaluated when the text thread is created or when the command is inserted, so a command like `/now` won't continuously update, or `/file` commands won't keep their contents up to date.
### `/default`
Read more about `/default` in the [Rules: Editing the Default Rules](./rules.md#default-rules) section.
Usage: `/default`
### `/diagnostics`
The `/diagnostics` command injects errors reported by the project's language server into the context.
This is useful for getting an overview of current issues in your project.
Usage: `/diagnostics [--include-warnings] [path]`
- `--include-warnings`: Optional flag to include warnings in addition to errors.
- `path`: Optional path to limit diagnostics to a specific file or directory.
### `/file`
The `/file` command inserts the content of a single file or a directory of files into the context.
This allows you to reference specific parts of your project in your conversation with the assistant.
Usage: `/file <path>`
You can use glob patterns to match multiple files or directories.
Examples:
- `/file src/index.js` - Inserts the content of `src/index.js` into the context.
- `/file src/*.js` - Inserts the content of all `.js` files in the `src` directory.
- `/file src` - Inserts the content of all files in the `src` directory.
### `/now`
The `/now` command inserts the current date and time into the context.
This can be useful for letting the language model know the current time (and by extension, how old their current knowledge base is).
Usage: `/now`
### `/prompt`
The `/prompt` command inserts a prompt from the prompt library into the context.
It can also be used to nest prompts within prompts.
Usage: `/prompt <prompt_name>`
Related: `/default`
### `/symbols`
The `/symbols` command inserts the active symbols (functions, classes, etc.) from the current tab into the context.
This is useful for getting an overview of the structure of the current file.
Usage: `/symbols`
### `/tab`
The `/tab` command inserts the content of the active tab or all open tabs into the context.
This allows you to reference the content you're currently working on.
Usage: `/tab [tab_name|all]`
- `tab_name`: Optional name of a specific tab to insert.
- `all`: Insert content from all open tabs.
Examples:
- `/tab` - Inserts the content of the active tab.
- `/tab "index.js"` - Inserts the content of the tab named "index.js".
- `/tab all` - Inserts the content of all open tabs.
### `/terminal`
The `/terminal` command inserts a select number of lines of output from the terminal into the context.
This is useful for referencing recent command outputs or logs.
Usage: `/terminal [<number>]`
- `<number>`: Optional parameter to specify the number of lines to insert (default is 50).
### `/selection`
The `/selection` command inserts the selected text in the editor into the context.
This is useful for referencing specific parts of your code.
This is equivalent to the `agent: add selection to thread` command ({#kb agent::AddSelectionToThread}).
Usage: `/selection`
## Commands in the Rules Library {#slash-commands-in-rules}
[Commands](#commands) can be used in rules, in the Rules Library (previously known as Prompt Library), to insert dynamic content or perform actions.
For example, if you want to create a rule where it is important for the model to know the date, you can use the `/now` command to insert the current date.
> **Warn:** Slash commands in rules **only** work when they are used in text threads. Using them in non-text threads is not supported.
> **Note:** Slash commands in rules **must** be on their own line.
See the [list of commands](#commands) above for more information on commands, and what slash commands are available.
### Example
```plaintext
You are an expert Rust engineer. The user has asked you to review their project and answer some questions.
Here is some information about their project:
/file Cargo.toml
```
In the above example, the `/file` command is used to insert the contents of the `Cargo.toml` file (or all `Cargo.toml` files present in the project) into the rule.
## Nesting Rules
Similar to adding rules to the default rules, you can nest rules within other rules with the `/prompt` command (only supported in Text Threads currently).
You might want to nest rules to:
- Create templates on the fly
- Break collections like docs or references into smaller, mix-and-matchable parts
- Create variants of a similar rule (e.g., `Async Rust - Tokio` vs. `Async Rust - Async-std`)
### Example
```plaintext
Title: Zed-Flavored Rust
## About Zed
/prompt Zed: Zed (a rule about what Zed is)
## Rust - Zed Style
/prompt Rust: Async - Async-std (zed doesn't use tokio)
/prompt Rust: Zed-style Crates (we have some unique conventions)
/prompt Rust - Workspace deps (bias towards reusing deps from the workspace)
```
_The text in parentheses above are comments and are not part of the rule._
> **Note:** While you technically _can_ nest a rule within itself, we wouldn't recommend it (in the strongest of terms.) Use at your own risk!
By using nested rules, you can create modular and reusable rule components that can be combined in various ways to suit different scenarios.
> **Note:** When using slash commands to bring in additional context, the injected content can be edited directly inline in the text thread—edits here will not propagate to the saved rules.
## Extensibility
Additional slash commands can be provided by extensions.
See [Extension: Slash Commands](../extensions/slash-commands.md) to learn how to create your own.
## Text Threads vs. Threads
For some time, text threads were the only way to interact with AI in Zed.
In May 2025, we introduced a new version of the agent panel, which, as opposed to being editor-based, is optimized for readability.
Visit [the Agent Panel page](./agent-panel.md) to learn more about it.
More importantly, aside from the many UI differences, the major aspect that sets one apart from the other is that tool calls don't work in Text Threads.
Due to that, it's accurate to say that Text Threads aren't conceptually agentic, as they can't perform any action on your behalf (or any action at all).
Think of it more like a regular/"traditional" AI chat, where the only thing you can get from the model is simply just text.
Consequently, [MCP servers](./mcp.md) and [external agents](./external-agents.md) are also not available in Text Threads.
## Advanced Concepts
### Rule Templates {#rule-templates}
Zed uses rule templates to power internal assistant features, like the terminal assistant, or the content rules used in the inline assistant.
Zed has the following internal rule templates:
- `content_prompt.hbs`: Used for generating content in the editor.
- `terminal_assistant_prompt.hbs`: Used for the terminal assistant feature.
At this point it is unknown if we will expand templates further to be user-creatable.
### Overriding Templates
> **Note:** It is not recommended to override templates unless you know what you are doing. Editing templates will break your assistant if done incorrectly.
Zed allows you to override the default rules used for various assistant features by placing custom Handlebars (.hbs) templates in your `~/.config/zed/prompt_overrides` directory.
The following templates can be overridden:
1. [`content_prompt.hbs`](https://github.com/zed-industries/zed/tree/main/assets/prompts/content_prompt.hbs): Used for generating content in the editor.
2. [`terminal_assistant_prompt.hbs`](https://github.com/zed-industries/zed/tree/main/assets/prompts/terminal_assistant_prompt.hbs): Used for the terminal assistant feature.
> **Note:** Be sure you want to override these, as you'll miss out on iteration on our built-in features.
> This should be primarily used when developing Zed.
You can customize these templates to better suit your needs while maintaining the core structure and variables used by Zed.
Zed will automatically reload your prompt overrides when they change on disk.
Consult Zed's [assets/prompts](https://github.com/zed-industries/zed/tree/main/assets/prompts) directory for current versions you can play with.
### History {#history}
After you submit your first message in a text thread, a name for your context is generated by the language model, and the context is automatically saved to your file system in
- `~/.config/zed/conversations` (macOS)
- `~/.local/share/zed/conversations` (Linux)
- `%LocalAppData%\Zed\conversations` (Windows)
You can access and load previous contexts by clicking on the history button in the top-left corner of the agent panel.
![Viewing assistant history](https://zed.dev/img/assistant/assistant-history.png)
docs/src/ai/tools.md
-73
View File
@@ -1,73 +0,0 @@
# Tools
Zed's built-in agent has access to a variety of tools that allow it to interact with your codebase and perform tasks.
## Read & Search Tools
### `diagnostics`
Gets errors and warnings for either a specific file or the entire project, useful after making edits to determine if further changes are needed.
When a path is provided, shows all diagnostics for that specific file.
When no path is provided, shows a summary of error and warning counts for all files in the project.
### `fetch`
Fetches a URL and returns the content as Markdown. Useful for providing docs as context.
### `find_path`
Quickly finds files by matching glob patterns (like "\*_/_.js"), returning matching file paths alphabetically.
### `grep`
Searches file contents across the project using regular expressions, preferred for finding symbols in code without knowing exact file paths.
### `list_directory`
Lists files and directories in a given path, providing an overview of filesystem contents.
### `now`
Returns the current date and time.
### `open`
Opens a file or URL with the default application associated with it on the user's operating system.
### `read_file`
Reads the content of a specified file in the project, allowing access to file contents.
### `thinking`
Allows the Agent to work through problems, brainstorm ideas, or plan without executing actions, useful for complex problem-solving.
### `web_search`
Searches the web for information, providing results with snippets and links from relevant web pages, useful for accessing real-time information.
## Edit Tools
### `copy_path`
Copies a file or directory recursively in the project, more efficient than manually reading and writing files when duplicating content.
### `create_directory`
Creates a new directory at the specified path within the project, creating all necessary parent directories (similar to `mkdir -p`).
### `delete_path`
Deletes a file or directory (including contents recursively) at the specified path and confirms the deletion.
### `edit_file`
Edits files by replacing specific text with new content.
### `move_path`
Moves or renames a file or directory in the project, performing a rename if only the filename differs.
### `terminal`
Executes shell commands and returns the combined output, creating a new shell process for each invocation.
docs/src/all-actions.md
-3
View File
@@ -1,3 +0,0 @@
# All Actions
{#ACTIONS_TABLE#}
docs/src/authentication.md
-37
View File
@@ -1,37 +0,0 @@
# Authenticate with Zed
Signing in to Zed is not required. You can use most features you'd expect in a code editor without ever doing so. We'll outline the few features that do require signing in, and how to do so, here.
## What Features Require Signing In?
1. All real-time [collaboration features](./collaboration/overview.md).
2. [LLM-powered features](./ai/overview.md), if you are using Zed as the provider of your LLM models. To use AI without signing in, you can [bring and configure your own API keys](./ai/llm-providers.md#use-your-own-keys).
## Signing In
Zed uses GitHub's OAuth flow to authenticate users, requiring only the `read:user` GitHub scope, which grants read-only access to your GitHub profile information.
1. Open Zed and click the `Sign In` button in the top-right corner of the window, or run the `client: sign in` command from the command palette (`cmd-shift-p` on macOS or `ctrl-shift-p` on Windows/Linux).
2. Your default web browser will open to the Zed sign-in page.
3. Authenticate with your GitHub account when prompted.
4. After successful authentication, your browser will display a confirmation, and you'll be automatically signed in to Zed.
**Note**: If you're behind a corporate firewall, ensure that connections to `zed.dev` and `collab.zed.dev` are allowed.
## Signing Out
To sign out of Zed, you can use either of these methods:
- Click on the profile icon in the upper right corner and select `Sign Out` from the dropdown menu.
- Open the command palette and run the `client: sign out` command.
## Email Addresses {#email}
Your Zed account's email address is the address provided by GitHub OAuth. If you have a public email address then it will be used, otherwise your primary GitHub email address will be used. Changes to your email address on GitHub can be synced to your Zed account by [signing in to zed.dev](https://zed.dev/sign_in).
Stripe is used for billing, and will use your Zed account's email address when starting a subscription. Changes to your Zed account email address do not currently update the email address used in Stripe. See [Updating Billing Information](./ai/billing.md#updating-billing-info) for how to change this email address.
## Hiding Sign In button from the interface
In case the Sign In feature is not used, it's possible to hide that from the interface by using `show_sign_in` settings property.
Refer to [Visual Customization page](./visual-customization.md) for more details.
docs/src/collaboration/channels.md
-122
View File
@@ -1,122 +0,0 @@
# Channels
Channels provide a way to streamline collaborating for software engineers in many ways, but particularly:
- Pairing – when working on something together, you both have your own screen, mouse, and keyboard.
- Mentoring – it's easy to jump in to someone else's context, and help them get unstuck, without the friction of pushing code up.
- Refactoring – you can have multiple people join in on large refactoring without fear of conflict.
- Ambient awareness – you can see what everyone else is working on with no need for status emails or meetings.
Each channel corresponds to an ongoing project or work-stream.
You can see who's in a channel as their avatars will show up in the sidebar.
This makes it easy to see what everyone is doing and where to find them if needed.
Create a channel by clicking the `+` icon next to the `Channels` text in the collab panel.
Create a subchannel by right clicking an existing channel and selecting `New Subchannel`.
You can mix channels for your day job, as well as side-projects in your collab panel.
Joining a channel adds you to a shared room where you can work on projects together.
_Join [our channel tree](https://zed.dev/channel/zed-283) to get an idea of how you can organize yours._
## Inviting People
By default, channels you create can only be accessed by you.
You can invite collaborators by right clicking and selecting `Manage members`.
When you have subchannels nested under others, permissions are inherited.
For instance, adding people to the top-level channel in your channel tree will automatically give them access to its subchannels.
Once you have added someone, they can either join your channel by clicking on it in their Zed sidebar, or you can share the link to the channel so that they can join directly.
## Voice Chat
You can mute/unmute your microphone via the microphone icon in the upper right-hand side of the window.
> Note: When joining a channel, Zed will automatically share your microphone with other users in the call, if your OS allows it.
> If you'd prefer your microphone to be off when joining a channel, you can do so via the [`mute_on_join`](../configuring-zed.md#calls) setting.
## Sharing Projects
After joining a channel, you can share a project over the channel via the `Share` button in the upper right-hand side of the window.
This will allow channel members to edit the code hosted on your machine as though they had it checked out locally.
When you are editing someone else's project, you still have the full power of the editor at your fingertips; you can jump to definitions, use the AI assistant, and see any diagnostic errors.
This is extremely powerful for pairing, as one of you can be implementing the current method while the other is reading and researching the correct solution to the next problem.
And, because you have your own config running, it feels like you're using your own machine.
We aim to eliminate the distinction between local and remote projects as much as possible.
Collaborators can open, edit, and save files, perform searches, interact with the language server, etc.
Guests have a read-only view of the project, including access to language server info.
### Unsharing a Project
You can remove a project from a channel by clicking on the `Unshare` button in the title bar.
Collaborators that are currently in that project will be disconnected from the project and will not be able to rejoin it unless you share it again.
## Channel Notes
Each channel has a Markdown notes file associated with it to keep track of current status, new ideas, or to collaborate on building out the design for the feature that you're working on before diving into code.
This is similar to a Google Doc, except powered by Zed's collaborative software and persisted to our servers.
Open the channel notes by clicking on the document icon to the right of the channel name in the collaboration panel.
> Note: You can view a channel's notes without joining the channel, if you'd just like to read up on what has been written.
## Following Collaborators
To follow a collaborator, click on their avatar in the top left of the title bar.
You can also cycle through collaborators using {#kb workspace::FollowNextCollaborator} or `workspace: follow next collaborator` in the command palette.
When you join a project, you'll immediately start following the collaborator that invited you.
When you are in a pane that is following a collaborator, you will:
- follow their cursor and scroll position
- follow them to other files in the same project
- instantly swap to viewing their screenshare in that pane, if they are sharing their screen and leave the project
To stop following, simply move your mouse or make an edit via your keyboard.
### How Following Works
Following is confined to a particular pane.
When a pane is following a collaborator, it is outlined in their cursor color.
Avatars of collaborators in the same project as you are in color, and have a cursor color.
Collaborators in other projects are shown in gray.
This pane-specific behavior allows you to follow someone in one pane while navigating independently in another and can be an effective layout for some collaboration styles.
### Following a Terminal
Following is not currently supported in the terminal in the way it is supported in the editor.
As a workaround, collaborators can share their screen and you can follow that instead.
## Screen Sharing
Share your screen with collaborators in the current channel by clicking on the `Share screen` (monitor icon) button in the top right of the title bar.
If you have multiple displays, you can choose which one to share via the chevron to the right of the monitor icon.
After you've shared your screen, others can click on the `Screen` entry under your name in the collaboration panel to open a tab that always keeps it visible.
If they are following you, Zed will automatically switch between following your cursor in their Zed instance and your screen share, depending on whether you are focused on Zed or another application, like a web browser.
> Note: Collaborators can see your entire screen when you are screen sharing, so be careful not to share anything you don't want to share.
> Remember to stop screen sharing when you are finished.
## Livestreaming & Guests
A Channel can also be made Public.
This allows anyone to join the channel by clicking on the link.
Guest users in channels can hear and see everything that is happening, and have read only access to projects and channel notes.
If you'd like to invite a guest to participate in a channel for the duration of a call you can do so by right clicking on them in the Collaboration Panel.
"Allowing Write Access" will allow them to edit any projects shared into the call, and to use their microphone and share their screen if they wish.
## Leaving a Call
You can leave a channel by clicking on the `Leave call` button in the upper right-hand side of the window.
docs/src/collaboration/contacts-and-private-calls.md
-25
View File
@@ -1,25 +0,0 @@
# Contacts and Private Calls
Zed allows you to have private calls / collaboration sessions with those in your contacts.
These calls can be one-on-ones or contain any number of users from your contacts.
## Adding a Contact
1. In the collaboration panel, click the `+` button next to the `Contacts` section
1. Search for the contact using their GitHub handle.\
_Note: Your contact must be an existing Zed user who has completed the GitHub authentication sign-in flow._
1. Your contact will receive a notification.
Once they accept, you'll both appear in each other's contact list.
## Private Calls
To start up a private call...
1. Click the `...` menu next to an online contact's name in the collaboration panel.
1. Click `Call <username>`
Once you've begun a private call, you can add other online contacts by clicking on their name in the collaboration panel.
---
_Aside from a few additional features (channel notes, etc.), collaboration in private calls is largely the same as it is in [channels](./channels.md)._
docs/src/collaboration/overview.md
-24
View File
@@ -1,24 +0,0 @@
# Collaboration
At Zed, we believe that great things are built by great people working together.
We have designed Zed to help individuals work faster and help teams of people work together more effectively.
In Zed, all collaboration happens in the collaboration panel, which can be opened via {#kb collab_panel::ToggleFocus} or `collab panel: toggle focus` from the command palette.
You will need to [sign in](../authentication.md#signing-in) in order to access features within the collaboration panel.
## Collaboration panel
The collaboration panel is broken down into two sections:
1. [Channels](./channels.md): Ongoing project rooms where team members can share projects, collaborate on code, and maintain ambient awareness of what everyone is working on.
1. [Contacts and Private Calls](./contacts-and-private-calls.md): Your contacts list for ad-hoc private collaboration.
---
> Note: Only collaborate with people that you trust.
> Since sharing a project gives them access to your local file system, you should not share projects with people you do not trust; they could potentially do some nasty things.
>
> In the future, we will do more to prevent this type of access beyond the shared project and add more control over what collaborators can do, but for now, only collaborate with people you trust.
See our [Data and Privacy FAQs](https://zed.dev/faq#data-and-privacy) for collaboration.
docs/src/command-line-interface.md
-18
View File
@@ -1,18 +0,0 @@
# Command-line Interface
Zed has a CLI, on Linux this should come with the distribution's Zed package (binary name can vary from distribution to distribution, `zed` will be used later for brevity).
For macOS, the CLI comes in the same package with the editor binary, and could be installed into the system with the `cli: install` Zed command which will create a symlink to the `/usr/local/bin/zed`.
It can also be built from source out of the `cli` crate in this repository.
Use `zed --help` to see the full list of capabilities.
General highlights:
- Opening another empty Zed window: `zed`
- Opening a file or directory in Zed: `zed /path/to/entry` (use `-n` to open in the new window)
- Reading from stdin: `ps axf | zed -`
- Starting Zed with logs in the terminal: `zed --foreground`
- Uninstalling Zed and all its related files: `zed --uninstall`
docs/src/command-palette.md
-9
View File
@@ -1,9 +0,0 @@
# Command Palette
The Command Palette is the main way to access pretty much any functionality that's available in Zed. Its keybinding is the first one you should make yourself familiar with. To open it, hit: {#kb command_palette::Toggle}.
![The opened Command Palette](https://zed.dev/img/features/command-palette.jpg)
Try it! Open the Command Palette and type in `new file`. You should see the list of commands being filtered down to `workspace: new file`. Hit return and you end up with a new buffer.
Any time you see instructions that include commands of the form `zed: ...` or `editor: ...` and so on that means you need to execute them in the Command Palette.
docs/src/completions.md
-28
View File
@@ -1,28 +0,0 @@
# Completions
Zed supports two sources for completions:
1. "Code Completions" provided by Language Servers (LSPs) automatically installed by Zed or via [Zed Language Extensions](languages.md).
2. "Edit Predictions" provided by Zed's own Zeta model or by external providers like [GitHub Copilot](#github-copilot) or [Supermaven](#supermaven).
## Language Server Code Completions {#code-completions}
When there is an appropriate language server available, Zed will provide completions of variable names, functions, and other symbols in the current file. You can disable these by adding the following to your Zed `settings.json` file:
```json [settings]
"show_completions_on_input": false
```
You can manually trigger completions with `ctrl-space` or by triggering the `editor::ShowCompletions` action from the command palette.
For more information, see:
- [Configuring Supported Languages](./configuring-languages.md)
- [List of Zed Supported Languages](./languages.md)
## Edit Predictions {#edit-predictions}
Zed has built-in support for predicting multiple edits at a time [via Zeta](https://huggingface.co/zed-industries/zeta), Zed's open-source and open-data model.
Edit predictions appear as you type, and most of the time, you can accept them by pressing `tab`.
See the [edit predictions documentation](./ai/edit-prediction.md) for more information on how to setup and configure Zed's edit predictions.
docs/src/configuring-languages.md
-465
View File
@@ -1,465 +0,0 @@
# Configuring Supported Languages
Zed offers powerful customization options for each programming language it supports. This guide will walk you through the various ways you can tailor your coding experience to your preferences and project requirements.
Zed's language support is built on two main technologies:
1. Tree-sitter: This handles syntax highlighting and structure-based features like the outline panel.
2. Language Server Protocol (LSP): This provides semantic features such as code completion and diagnostics.
These components work together to provide Zed's language capabilities.
In this guide, we'll cover:
- Language-specific settings
- File associations
- Working with language servers
- Formatting and linting configuration
- Customizing syntax highlighting and themes
- Advanced language features
By the end of this guide, you should know how to configure and customize supported languages in Zed.
For a comprehensive list of languages supported by Zed and their specific configurations, see our [Supported Languages](./languages.md) page. To go further, you could explore developing your own extensions to add support for additional languages or enhance existing functionality. For more information on creating language extensions, see our [Language Extensions](./extensions/languages.md) guide.
## Language-specific Settings
Zed allows you to override global settings for individual languages. These custom configurations are defined in your `settings.json` file under the `languages` key.
Here's an example of language-specific settings:
```json [settings]
"languages": {
"Python": {
"tab_size": 4,
"formatter": "language_server",
"format_on_save": "on"
},
"JavaScript": {
"tab_size": 2,
"formatter": {
"external": {
"command": "prettier",
"arguments": ["--stdin-filepath", "{buffer_path}"]
}
}
}
}
```
You can customize a wide range of settings for each language, including:
- [`tab_size`](./configuring-zed.md#tab-size): The number of spaces for each indentation level
- [`formatter`](./configuring-zed.md#formatter): The tool used for code formatting
- [`format_on_save`](./configuring-zed.md#format-on-save): Whether to automatically format code when saving
- [`enable_language_server`](./configuring-zed.md#enable-language-server): Toggle language server support
- [`hard_tabs`](./configuring-zed.md#hard-tabs): Use tabs instead of spaces for indentation
- [`preferred_line_length`](./configuring-zed.md#preferred-line-length): The recommended maximum line length
- [`soft_wrap`](./configuring-zed.md#soft-wrap): How to wrap long lines of code
- [`show_completions_on_input`](./configuring-zed.md#show-completions-on-input): Whether or not to show completions as you type
- [`show_completion_documentation`](./configuring-zed.md#show-completion-documentation): Whether to display inline and alongside documentation for items in the completions menu
- [`colorize_brackets`](./configuring-zed.md#colorize-brackets): Whether to use tree-sitter bracket queries to detect and colorize the brackets in the editor (also known as "rainbow brackets")
These settings allow you to maintain specific coding styles across different languages and projects.
## File Associations
Zed automatically detects file types based on their extensions, but you can customize these associations to fit your workflow.
To set up custom file associations, use the [`file_types`](./configuring-zed.md#file-types) setting in your `settings.json`:
```json [settings]
"file_types": {
"C++": ["c"],
"TOML": ["MyLockFile"],
"Dockerfile": ["Dockerfile*"]
}
```
This configuration tells Zed to:
- Treat `.c` files as C++ instead of C
- Recognize files named "MyLockFile" as TOML
- Apply Dockerfile syntax to any file starting with "Dockerfile"
You can use glob patterns for more flexible matching, allowing you to handle complex naming conventions in your projects.
## Working with Language Servers
Language servers are a crucial part of Zed's intelligent coding features, providing capabilities like auto-completion, go-to-definition, and real-time error checking.
### What are Language Servers?
Language servers implement the Language Server Protocol (LSP), which standardizes communication between the editor and language-specific tools. This allows Zed to support advanced features for multiple programming languages without implementing each feature separately.
Some key features provided by language servers include:
- Code completion
- Error checking and diagnostics
- Code navigation (go to definition, find references)
- Code actions (Rename, extract method)
- Hover information
- Workspace symbol search
### Managing Language Servers
Zed simplifies language server management for users:
1. Automatic Download: When you open a file with a matching file type, Zed automatically downloads the appropriate language server. Zed may prompt you to install an extension for known file types.
2. Storage Location:
- macOS: `~/Library/Application Support/Zed/languages`
- Linux: `$XDG_DATA_HOME/zed/languages`, `$FLATPAK_XDG_DATA_HOME/zed/languages`, or `$HOME/.local/share/zed/languages`
3. Automatic Updates: Zed keeps your language servers up-to-date, ensuring you always have the latest features and improvements.
### Choosing Language Servers
Some languages in Zed offer multiple language server options. You might have multiple extensions installed that bundle language servers targeting the same language, potentially leading to overlapping capabilities. To ensure you get the functionality you prefer, Zed allows you to prioritize which language servers are used and in what order.
You can specify your preference using the `language_servers` setting:
```json [settings]
"languages": {
"PHP": {
"language_servers": ["intelephense", "!phpactor", "!phptools", "..."]
}
}
```
In this example:
- `intelephense` is set as the primary language server
- `phpactor` is disabled (note the `!` prefix)
- `...` expands to the rest of the language servers that are registered for PHP
This configuration allows you to tailor the language server setup to your specific needs, ensuring that you get the most suitable functionality for your development workflow.
### Toolchains
Some language servers need to be configured with a current "toolchain", which is an installation of a specific version of a programming language compiler or/and interpreter, which can possibly include a full set of dependencies of a project.
An example of what Zed considers a toolchain is a virtual environment in Python.
Not all languages in Zed support toolchain discovery and selection, but for those that do, you can specify the toolchain from a toolchain picker (via {#action toolchain::Select}). To learn more about toolchains in Zed, see [`toolchains`](./toolchains.md).
### Configuring Language Servers
Many language servers accept custom configuration options. You can set these in the `lsp` section of your `settings.json`:
```json [settings]
"lsp": {
"rust-analyzer": {
"initialization_options": {
"check": {
"command": "clippy"
}
}
}
}
```
This example configures the Rust Analyzer to use Clippy for additional linting when saving files.
#### Nested objects
When configuring language server options in Zed, it's important to use nested objects rather than dot-delimited strings. This is particularly relevant when working with more complex configurations. Let's look at a real-world example using the TypeScript language server:
Suppose you want to configure the following settings for TypeScript:
- Enable strict null checks
- Set the target ECMAScript version to ES2020
Here's how you would structure these settings in Zed's `settings.json`:
```json [settings]
"lsp": {
"typescript-language-server": {
"initialization_options": {
// These are not supported (VSCode dotted style):
// "preferences.strictNullChecks": true,
// "preferences.target": "ES2020"
//
// These is correct (nested notation):
"preferences": {
"strictNullChecks": true,
"target": "ES2020"
},
}
}
}
```
#### Possible configuration options
Depending on how a particular language server is implemented, they may depend on different configuration options, both specified in the LSP.
- [initializationOptions](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#version_3_17_0)
Sent once during language server startup, requires server's restart to reapply changes.
For example, rust-analyzer and clangd rely on this way of configuring only.
```json [settings]
"lsp": {
"rust-analyzer": {
"initialization_options": {
"checkOnSave": false
}
}
}
```
- [Configuration Request](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#workspace_configuration)
May be queried by the server multiple times.
Most of the servers would rely on this way of configuring only.
```json [settings]
"lsp": {
"tailwindcss-language-server": {
"settings": {
"tailwindCSS": {
"emmetCompletions": true,
},
}
}
}
```
Apart of the LSP-related server configuration options, certain servers in Zed allow configuring the way binary is launched by Zed.
Language servers are automatically downloaded or launched if found in your path, if you wish to specify an explicit alternate binary you can specify that in settings:
```json [settings]
"lsp": {
"rust-analyzer": {
"binary": {
// Whether to fetch the binary from the internet, or attempt to find locally.
"ignore_system_version": false,
"path": "/path/to/langserver/bin",
"arguments": ["--option", "value"],
"env": {
"FOO": "BAR"
}
}
}
}
```
### Enabling or Disabling Language Servers
You can toggle language server support globally or per-language:
```json [settings]
"languages": {
"Markdown": {
"enable_language_server": false
}
}
```
This disables the language server for Markdown files, which can be useful for performance in large documentation projects. You can configure this globally in your `~/.config/zed/settings.json` or inside a `.zed/settings.json` in your project directory.
## Formatting and Linting
Zed provides support for code formatting and linting to maintain consistent code style and catch potential issues early.
### Configuring Formatters
Zed supports both built-in and external formatters. See [`formatter`](./configuring-zed.md#formatter) docs for more. You can configure formatters globally or per-language in your `settings.json`:
```json [settings]
"languages": {
"JavaScript": {
"formatter": {
"external": {
"command": "prettier",
"arguments": ["--stdin-filepath", "{buffer_path}"]
}
},
"format_on_save": "on"
},
"Rust": {
"formatter": "language_server",
"format_on_save": "on"
}
}
```
This example uses Prettier for JavaScript and the language server's formatter for Rust, both set to format on save.
To disable formatting for a specific language:
```json [settings]
"languages": {
"Markdown": {
"format_on_save": "off"
}
}
```
### Setting Up Linters
Linting in Zed is typically handled by language servers. Many language servers allow you to configure linting rules:
```json [settings]
"lsp": {
"eslint": {
"settings": {
"codeActionOnSave": {
"rules": ["import/order"]
}
}
}
}
```
This configuration sets up ESLint to organize imports on save for JavaScript files.
To run linter fixes automatically on save:
```json [settings]
"languages": {
"JavaScript": {
"formatter": {
"code_action": "source.fixAll.eslint"
}
}
}
```
### Integrating Formatting and Linting
Zed allows you to run both formatting and linting on save. Here's an example that uses Prettier for formatting and ESLint for linting JavaScript files:
```json [settings]
"languages": {
"JavaScript": {
"formatter": [
{
"code_action": "source.fixAll.eslint"
},
{
"external": {
"command": "prettier",
"arguments": ["--stdin-filepath", "{buffer_path}"]
}
}
],
"format_on_save": "on"
}
}
```
### Troubleshooting
If you encounter issues with formatting or linting:
1. Check Zed's log file for error messages (Use the command palette: `zed: open log`)
2. Ensure external tools (formatters, linters) are correctly installed and in your PATH
3. Verify configurations in both Zed settings and language-specific config files (e.g., `.eslintrc`, `.prettierrc`)
## Syntax Highlighting and Themes
Zed offers customization options for syntax highlighting and themes, allowing you to tailor the visual appearance of your code.
### Customizing Syntax Highlighting
Zed uses Tree-sitter grammars for syntax highlighting. Override the default highlighting using the `theme_overrides` setting.
This example makes comments italic and changes the color of strings:
```json [settings]
"theme_overrides": {
"One Dark": {
"syntax": {
"comment": {
"font_style": "italic"
},
"string": {
"color": "#00AA00"
}
}
}
}
```
### Selecting and Customizing Themes
Change your theme:
1. Use the theme selector ({#kb theme_selector::Toggle})
2. Or set it in your `settings.json`:
```json [settings]
"theme": {
"mode": "dark",
"dark": "One Dark",
"light": "GitHub Light"
}
```
Create custom themes by creating a JSON file in `~/.config/zed/themes/`. Zed will automatically detect and make available any themes in this directory.
### Using Theme Extensions
Zed supports theme extensions. Browse and install theme extensions from the Extensions panel ({#kb zed::Extensions}).
To create your own theme extension, refer to the [Developing Theme Extensions](./extensions/themes.md) guide.
## Using Language Server Features
### Inlay Hints
Inlay hints provide additional information inline in your code, such as parameter names or inferred types. Configure inlay hints in your `settings.json`:
```json [settings]
"inlay_hints": {
"enabled": true,
"show_type_hints": true,
"show_parameter_hints": true,
"show_other_hints": true
}
```
For language-specific inlay hint settings, refer to the documentation for each language.
### Code Actions
Code actions provide quick fixes and refactoring options. Access code actions using the `editor: Toggle Code Actions` command or by clicking the lightbulb icon that appears next to your cursor when actions are available.
### Go To Definition and References
Use these commands to navigate your codebase:
- `editor: Go to Definition` (<kbd>f12|f12</kbd>)
- `editor: Go to Type Definition` (<kbd>cmd-f12|ctrl-f12</kbd>)
- `editor: Find All References` (<kbd>shift-f12|shift-f12</kbd>)
### Rename Symbol
To rename a symbol across your project:
1. Place your cursor on the symbol
2. Use the `editor: Rename Symbol` command (<kbd>f2|f2</kbd>)
3. Enter the new name and press Enter
These features depend on the capabilities of the language server for each language.
When renaming a symbol that spans multiple files, Zed will open a preview in a multibuffer. This allows you to review all the changes across your project before applying them. To confirm the rename, simply save the multibuffer. If you decide not to proceed with the rename, you can undo the changes or close the multibuffer without saving.
### Hover Information
Use the `editor: Hover` command to display information about the symbol under the cursor. This often includes type information, documentation, and links to relevant resources.
### Workspace Symbol Search
The `workspace: Open Symbol` command allows you to search for symbols (functions, classes, variables) across your entire project. This is useful for quickly navigating large codebases.
### Code Completion
Zed provides intelligent code completion suggestions as you type. You can manually trigger completion with the `editor: Show Completions` command. Use <kbd>tab|tab</kbd> or <kbd>enter|enter</kbd> to accept suggestions.
### Diagnostics
Language servers provide real-time diagnostics (errors, warnings, hints) as you code. View all diagnostics for your project using the `diagnostics: Toggle` command.
docs/src/configuring-zed.md
-4996
View File
File diff suppressed because it is too large Load Diff
docs/src/debugger.md
-370
View File
@@ -1,370 +0,0 @@
# Debugger
Zed uses the [Debug Adapter Protocol (DAP)](https://microsoft.github.io/debug-adapter-protocol/) to provide debugging functionality across multiple programming languages.
DAP is a standardized protocol that defines how debuggers, editors, and IDEs communicate with each other.
It allows Zed to support various debuggers without needing to implement language-specific debugging logic.
Zed implements the client side of the protocol, and various _debug adapters_ implement the server side.
This protocol enables features like setting breakpoints, stepping through code, inspecting variables,
and more, in a consistent manner across different programming languages and runtime environments.
## Supported Languages
To debug code written in a specific language, Zed needs to find a debug adapter for that language. Some debug adapters are provided by Zed without additional setup, and some are provided by [language extensions](./extensions/debugger-extensions.md). The following languages currently have debug adapters available:
<!-- keep this sorted -->
- [C](./languages/c.md#debugging) (built-in)
- [C++](./languages/cpp.md#debugging) (built-in)
- [Go](./languages/go.md#debugging) (built-in)
- [Java](./languages/java.md#debugging) (provided by extension)
- [JavaScript](./languages/javascript.md#debugging) (built-in)
- [PHP](./languages/php.md#debugging) (built-in)
- [Python](./languages/python.md#debugging) (built-in)
- [Ruby](./languages/ruby.md#debugging) (provided by extension)
- [Rust](./languages/rust.md#debugging) (built-in)
- [Swift](./languages/swift.md#debugging) (provided by extension)
- [TypeScript](./languages/typescript.md#debugging) (built-in)
> If your language isn't listed, you can contribute by adding a debug adapter for it. Check out our [debugger extensions](./extensions/debugger-extensions.md) documentation for more information.
Follow those links for language- and adapter-specific information and examples, or read on for more about Zed's general debugging features that apply to all adapters.
## Getting Started
For most languages, the fastest way to get started is to run {#action debugger::Start} ({#kb debugger::Start}). This opens the _new process modal_, which shows you a contextual list of preconfigured debug tasks for the current project. Debug tasks are created from tests, entry points (like a `main` function), and from other sources — consult the documentation for your language for full information about what's supported.
You can open the same modal by clicking the "plus" button at the top right of the debug panel.
For languages that don't provide preconfigured debug tasks (this includes C, C++, and some extension-supported languages), you can define debug configurations in the `.zed/debug.json` file in your project root. This file should be an array of configuration objects:
```json [debug]
[
{
"adapter": "CodeLLDB",
"label": "First configuration"
// ...
},
{
"adapter": "Debugpy",
"label": "Second configuration"
// ...
}
]
```
Check the documentation for your language for example configurations covering typical use-cases. Once you've added configurations to `.zed/debug.json`, they'll appear in the list in the new process modal.
Zed will also load debug configurations from `.vscode/launch.json`, and show them in the new process modal if no configurations are found in `.zed/debug.json`.
#### Global debug configurations
If you run the same launch profiles across multiple projects, you can store them once in your user configuration. Invoke {#action zed::OpenDebugTasks} from the command palette to open the global `debug.json` file; Zed creates it next to your user `settings.json` and keeps it in sync with the debugger UI. The file lives at:
- **macOS:** `~/Library/Application Support/Zed/debug.json`
- **Linux/BSD:** `$XDG_CONFIG_HOME/zed/debug.json` (falls back to `~/.config/zed/debug.json`)
- **Windows:** `%APPDATA%\Zed\debug.json`
Populate this file with the same array of objects you would place in `.zed/debug.json`. Any scenarios defined there are merged into every workspace, so your favorite launch presets appear automatically in the "New Debug Session" dialog.
### Launching & Attaching
Zed debugger offers two ways to debug your program; you can either _launch_ a new instance of your program or _attach_ to an existing process.
Which one you choose depends on what you are trying to achieve.
When launching a new instance, Zed (and the underlying debug adapter) can often do a better job at picking up the debug information compared to attaching to an existing process, since it controls the lifetime of a whole program.
Running unit tests or a debug build of your application is a good use case for launching.
Compared to launching, attaching to an existing process might seem inferior, but that's far from truth; there are cases where you cannot afford to restart your program, because for example, the bug is not reproducible outside of a production environment or some other circumstances.
## Configuration
Zed requires the `adapter` and `label` fields for all debug tasks. In addition, Zed will use the `build` field to run any necessary setup steps before the debugger starts [(see below)](#build-tasks), and can accept a `tcp_connection` field to connect to an existing process.
All other fields are provided by the debug adapter and can contain [task variables](./tasks.md#variables). Most adapters support `request`, `program`, and `cwd`:
```json [debug]
[
{
// The label for the debug configuration and used to identify the debug session inside the debug panel & new process modal
"label": "Example Start debugger config",
// The debug adapter that Zed should use to debug the program
"adapter": "Example adapter name",
// Request:
// - launch: Zed will launch the program if specified, or show a debug terminal with the right configuration
// - attach: Zed will attach to a running program to debug it, or when the process_id is not specified, will show a process picker (only supported for node currently)
"request": "launch",
// The program to debug. This field supports path resolution with ~ or . symbols.
"program": "path_to_program",
// cwd: defaults to the current working directory of your project ($ZED_WORKTREE_ROOT)
"cwd": "$ZED_WORKTREE_ROOT"
}
]
```
Check your debug adapter's documentation for more information on the fields it supports.
### Build tasks
Zed allows embedding a Zed task in the `build` field that is run before the debugger starts. This is useful for setting up the environment or running any necessary setup steps before the debugger starts.
```json [debug]
[
{
"label": "Build Binary",
"adapter": "CodeLLDB",
"program": "path_to_program",
"request": "launch",
"build": {
"command": "make",
"args": ["build", "-j8"]
}
}
]
```
Build tasks can also refer to the existing tasks by unsubstituted label:
```json [debug]
[
{
"label": "Build Binary",
"adapter": "CodeLLDB",
"program": "path_to_program",
"request": "launch",
"build": "my build task" // Or "my build task for $ZED_FILE"
}
]
```
### Automatic scenario creation
Given a Zed task, Zed can automatically create a scenario for you. Automatic scenario creation also powers our scenario creation from gutter.
Automatic scenario creation is currently supported for Rust, Go, Python, JavaScript, and TypeScript.
## Breakpoints
To set a breakpoint, simply click next to the line number in the editor gutter.
Breakpoints can be tweaked depending on your needs; to access additional options of a given breakpoint, right-click on the breakpoint icon in the gutter and select the desired option.
At present, you can:
- Add a log to a breakpoint, which will output a log message whenever that breakpoint is hit.
- Make the breakpoint conditional, which will only stop at the breakpoint when the condition is met. The syntax for conditions is adapter-specific.
- Add a hit count to a breakpoint, which will only stop at the breakpoint after it's hit a certain number of times.
- Disable a breakpoint, which will prevent it from being hit while leaving it visible in the gutter.
Some debug adapters (e.g. CodeLLDB and JavaScript) will also _verify_ whether your breakpoints can be hit; breakpoints that cannot be hit are surfaced more prominently in the UI.
All breakpoints enabled for a given project are also listed in "Breakpoints" item in your debugging session UI. From "Breakpoints" item in your UI you can also manage exception breakpoints.
The debug adapter will then stop whenever an exception of a given kind occurs. Which exception types are supported depends on the debug adapter.
## Settings
The settings for the debugger are grouped under the `debugger` key in `settings.json`:
- `dock`: Determines the position of the debug panel in the UI.
- `stepping_granularity`: Determines the stepping granularity.
- `save_breakpoints`: Whether the breakpoints should be reused across Zed sessions.
- `button`: Whether to show the debug button in the status bar.
- `timeout`: Time in milliseconds until timeout error when connecting to a TCP debug adapter.
- `log_dap_communications`: Whether to log messages between active debug adapters and Zed.
- `format_dap_log_messages`: Whether to format DAP messages when adding them to the debug adapter logger.
### Dock
- Description: The position of the debug panel in the UI.
- Default: `bottom`
- Setting: debugger.dock
**Options**
1. `left` - The debug panel will be docked to the left side of the UI.
2. `right` - The debug panel will be docked to the right side of the UI.
3. `bottom` - The debug panel will be docked to the bottom of the UI.
```json [settings]
"debugger": {
"dock": "bottom"
},
```
### Stepping granularity
- Description: The Step granularity that the debugger will use
- Default: `line`
- Setting: `debugger.stepping_granularity`
**Options**
1. Statement - The step should allow the program to run until the current statement has finished executing.
The meaning of a statement is determined by the adapter and it may be considered equivalent to a line.
For example 'for(int i = 0; i < 10; i++)' could be considered to have 3 statements 'int i = 0', 'i < 10', and 'i++'.
```json [settings]
{
"debugger": {
"stepping_granularity": "statement"
}
}
```
2. Line - The step should allow the program to run until the current source line has executed.
```json [settings]
{
"debugger": {
"stepping_granularity": "line"
}
}
```
3. Instruction - The step should allow one instruction to execute (e.g. one x86 instruction).
```json [settings]
{
"debugger": {
"stepping_granularity": "instruction"
}
}
```
### Save Breakpoints
- Description: Whether the breakpoints should be saved across Zed sessions.
- Default: `true`
- Setting: `debugger.save_breakpoints`
**Options**
`boolean` values
```json [settings]
{
"debugger": {
"save_breakpoints": true
}
}
```
### Button
- Description: Whether the button should be displayed in the debugger toolbar.
- Default: `true`
- Setting: `debugger.show_button`
**Options**
`boolean` values
```json [settings]
{
"debugger": {
"show_button": true
}
}
```
### Timeout
- Description: Time in milliseconds until timeout error when connecting to a TCP debug adapter.
- Default: `2000`
- Setting: `debugger.timeout`
**Options**
`integer` values
```json [settings]
{
"debugger": {
"timeout": 3000
}
}
```
### Inline Values
- Description: Whether to enable editor inlay hints showing the values of variables in your code during debugging sessions.
- Default: `true`
- Setting: `inlay_hints.show_value_hints`
**Options**
```json [settings]
{
"inlay_hints": {
"show_value_hints": false
}
}
```
Inline value hints can also be toggled from the Editor Controls menu in the editor toolbar.
### Log Dap Communications
- Description: Whether to log messages between active debug adapters and Zed. (Used for DAP development)
- Default: false
- Setting: debugger.log_dap_communications
**Options**
`boolean` values
```json [settings]
{
"debugger": {
"log_dap_communications": true
}
}
```
### Format Dap Log Messages
- Description: Whether to format DAP messages when adding them to the debug adapter logger. (Used for DAP development)
- Default: false
- Setting: debugger.format_dap_log_messages
**Options**
`boolean` values
```json [settings]
{
"debugger": {
"format_dap_log_messages": true
}
}
```
### Customizing Debug Adapters
- Description: Custom program path and arguments to override how Zed launches a specific debug adapter.
- Default: Adapter-specific
- Setting: `dap.$ADAPTER.binary` and `dap.$ADAPTER.args`
You can pass `binary`, `args`, or both. `binary` should be a path to a _debug adapter_ (like `lldb-dap`) not a _debugger_ (like `lldb` itself). The `args` setting overrides any arguments that Zed would otherwise pass to the adapter.
```json [settings]
{
"dap": {
"CodeLLDB": {
"binary": "/Users/name/bin/lldb-dap",
"args": ["--wait-for-debugger"]
}
}
}
```
## Theme
The Debugger supports the following theme options:
- `debugger.accent`: Color used to accent breakpoint & breakpoint-related symbols
- `editor.debugger_active_line.background`: Background color of active debug line
## Troubleshooting
If you're running into problems with the debugger, please [open a GitHub issue](https://github.com/zed-industries/zed/issues/new?template=04_bug_debugger.yml), providing as much context as possible. There are also some features you can use to gather more information about the problem:
- When you have a session running in the debug panel, you can run the {#action dev::CopyDebugAdapterArguments} action to copy a JSON blob to the clipboard that describes how Zed initialized the session. This is especially useful when the session failed to start, and is great context to add if you open a GitHub issue.
- You can also use the {#action dev::OpenDebugAdapterLogs} action to see a trace of all of Zed's communications with debug adapters during the most recent debug sessions.
docs/src/development.md
-93
View File
@@ -1,93 +0,0 @@
# Developing Zed
See the platform-specific instructions for building Zed from source:
- [macOS](./development/macos.md)
- [Linux](./development/linux.md)
- [Windows](./development/windows.md)
If you'd like to develop collaboration features, additionally see:
- [Local Collaboration](./development/local-collaboration.md)
## Keychain access
Zed stores secrets in the system keychain.
However, when running a development build of Zed on macOS (and perhaps other
platforms) trying to access the keychain results in a lot of keychain prompts
that require entering your password over and over.
On macOS this is caused by the development build not having a stable identity.
Even if you choose the "Always Allow" option, the OS will still prompt you for
your password again the next time something changes in the binary.
This quickly becomes annoying and impedes development speed.
That is why, by default, when running a development build of Zed an alternative
credential provider is used in order to bypass the system keychain.
> Note: This is **only** the case for development builds. For all non-development
> release channels the system keychain is always used.
If you need to test something out using the real system keychain in a
development build, run Zed with the following environment variable set:
```
ZED_DEVELOPMENT_USE_KEYCHAIN=1
```
## Performance Measurements
Zed includes a frame time measurement system that can be used to profile how long it takes to render each frame. This is particularly useful when comparing rendering performance between different versions or when optimizing frame rendering code.
### Using ZED_MEASUREMENTS
To enable performance measurements, set the `ZED_MEASUREMENTS` environment variable:
```sh
export ZED_MEASUREMENTS=1
```
When enabled, Zed will print frame rendering timing information to stderr, showing how long each frame takes to render.
### Performance Comparison Workflow
Here's a typical workflow for comparing frame rendering performance between different versions:
1. **Enable measurements:**
```sh
export ZED_MEASUREMENTS=1
```
2. **Test the first version:**
- Checkout the commit you want to measure
- Run Zed in release mode and use it for 5-10 seconds: `cargo run --release &> version-a`
3. **Test the second version:**
- Checkout another commit you want to compare
- Run Zed in release mode and use it for 5-10 seconds: `cargo run --release &> version-b`
4. **Generate comparison:**
```sh
script/histogram version-a version-b
```
The `script/histogram` tool can accept as many measurement files as you like and will generate a histogram visualization comparing the frame rendering performance data between the provided versions.
### Using `util_macros::perf`
For benchmarking unit tests, annotate them with the `#[perf]` attribute from the `util_macros` crate. Then run `cargo
perf-test -p $CRATE` to benchmark them. See the rustdoc documentation on `crates/util_macros` and `tooling/perf` for
in-depth examples and explanations.
## Contributor links
- [CONTRIBUTING.md](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md)
- [Debugging Crashes](./development/debugging-crashes.md)
- [Code of Conduct](https://zed.dev/code-of-conduct)
- [Zed Contributor License](https://zed.dev/cla)
docs/src/development/debuggers.md
-113
View File
@@ -1,113 +0,0 @@
# Using a debugger
> **DISCLAIMER**: This is not documentation for [configuring Zed's debugger](../debugger.md).
> Rather, it is intended to provide information on how to use a debugger while developing Zed itself to both Zed employees and external contributors.
## Using Zed's built-in debugger
While the Zed project is open you can open the `New Process Modal` and select the `Debug` tab. There you can see two debug configurations to debug Zed with, one for GDB and one for LLDB. Select the configuration you want and Zed will build and launch the binary.
Please note, GDB isn't supported on arm Macbooks
## Release build profile considerations
By default, builds using the release profile (release is the profile used for production builds, i.e. nightly, preview, and stable) include limited debug info.
This is done by setting the `profile.(release).debug` field in the root `Cargo.toml` field to `"limited"`.
The official documentation for the `debug` field can be found [here](https://doc.rust-lang.org/cargo/reference/profiles.html#debug).
But the TLDR is that `"limited"` strips type and variable level debug info.
In release builds, this is done to reduce the binary size, as type and variable level debug info is not required, and does not impact the usability of generated stack traces.
However, while the type and variable level debug info is not required for good stack traces, it is very important for a good experience using debuggers,
as without the type and variable level debug info, the debugger has no way to resolve local variables, inspect them, format them using pretty-printers, etc.
Therefore, in order to use a debugger to it's fullest extent when debugging a release build, you must compile a new Zed binary, with full debug info.
The simplest way to do this, is to use the `--config` flag to override the `debug` field in the root `Cargo.toml` file when running `cargo run` or `cargo build` like so:
```sh
cargo run --config 'profile.release.debug="full"'
cargo build --config 'profile.release.debug="full"'
```
> If you wish to avoid passing the `--config` flag on every invocation of `cargo`. You may also change the section in the [root `Cargo.toml`](https://github.com/zed-industries/zed/blob/main/Cargo.toml)
>
> from
>
> ```toml
> [profile.release]
> debug = "limited"
> ```
>
> to
>
> ```toml
> [profile.release]
> debug = "full"
> ```
>
> This will ensure all invocations of `cargo run --release` or `cargo build --release` will compile with full debug info.
>
> **WARNING:** Make sure to avoid committing these changes!
## Running Zed with a shell debugger GDB/LLDB
### Background
When installing rust through rustup, (the recommended way to do so when developing Zed, see the documentation for getting started on your platform [here](../development.md))
a few additional scripts are installed and put on your path to assist with debugging binaries compiled with rust.
These are `rust-gdb` and `rust-lldb` respectively.
You can read more information about these scripts and why they are useful [here](https://michaelwoerister.github.io/2015/03/27/rust-xxdb.html) if you are interested.
However, the summary is that they are simple shell scripts that wrap the standard `gdb` and `lldb` commands, injecting the relevant commands and flags to enable additional
rust-specific features such as pretty-printers and type information.
Therefore, in order to use `rust-gdb` or `rust-lldb`, you must have `gdb` or `lldb` installed on your system. If you don't have them installed, you will need to install them in a manner appropriate for your platform.
According to the [previously linked article](https://michaelwoerister.github.io/2015/03/27/rust-xxdb.html), "The minimum supported debugger versions are GDB 7.7 and LLDB 310. However, the general rule is: the newer the better." Therefore, it is recommended to install the latest version of `gdb` or `lldb` if possible.
> **Note**: `rust-gdb` is not installed by default on Windows, as `gdb` support for windows is not very stable. It is recommended to use `lldb` with `rust-lldb` instead on Windows.
If you are unfamiliar with `gdb` or `lldb`, you can learn more about them [here](https://www.gnu.org/software/gdb/) and [here](https://lldb.llvm.org/) respectively.
### Usage with Zed
After following the steps above for including full debug info when compiling Zed,
You can either run `rust-gdb` or `rust-lldb` on the compiled Zed binary after building it with `cargo build`, by running one of the following commands:
```
rust-gdb target/debug/zed
rust-lldb target/debug/zed
```
Alternatively, you can attach to a running instance of Zed (such as an instance of Zed started using `cargo run`) by running one of the following commands:
```
rust-gdb -p <pid>
rust-lldb -p <pid>
```
Where `<pid>` is the process ID of the Zed instance you want to attach to.
To get the process ID of a running Zed instance, you can use your systems process management tools such as `Task Manager` on windows or `Activity Monitor` on macOS.
Alternatively, you can run the `ps aux | grep zed` command on macOS and Linux or `Get-Process | Select-Object Id, ProcessName` in an instance of PowerShell on Windows.
#### Debugging Panics and Crashes
Debuggers can be an excellent tool for debugging the cause of panics and crashes in all programs, including Zed.
By default, when a process that `gdb` or `lldb` is attached to hits an exception such as a panic, the debugger will automatically stop at the point of the panic and allow you to inspect the state of the program.
Most likely, the point at which the debugger stops will be deep in the rust standard library panic or exception handling code, so you will need to navigate up the stack trace to find the actual cause of the panic.
This can be accomplished using the `backtrace` command in combination with the `frame select` command in `lldb`, with similar commands available in `gdb`.
Once the program is stopped, you will not be able to continue execution as you can before an exception is hit. However, you can jump around to different stack frames, and inspect the values of variables and expressions
within each frame, which can be very useful in identifying the root cause of the crash.
You can find additional information on debugging Zed crashes [here](./debugging-crashes.md).
docs/src/development/debugging-crashes.md
-20
View File
@@ -1,20 +0,0 @@
# Debugging Crashes
When Zed panics or otherwise crashes, Zed sends a message to a sidecar process which inspects the memory of the crashing editor to create a [minidump](https://chromium.googlesource.com/breakpad/breakpad/+/master/docs/getting_started_with_breakpad.md#the-minidump-file-format) file in `~/Library/Logs/Zed` or `$XDG_DATA_HOME/zed/logs`. This minidump can be used to generate backtraces for the stacks of all threads.
If you have enabled Zed's telemetry these will be uploaded to us when you restart the app. They end up in a [Slack channel](https://zed-industries.slack.com/archives/C0977J9MA1Y) and in [Sentry](https://zed-dev.sentry.io/issues) (both of which are Zed-staff-only).
These crash reports contain rich information; but they are hard to read because they don't contain spans or symbol information. You can still work with them locally by downloading sources and an unstripped binary (or separate symbols file) for your Zed release and running:
```sh
zstd -d ~/.local/share/zed/<uuid>.dmp -o minidump.dmp
minidump-stackwalk minidump.dmp
```
Alongside the minidump file in your logs dir, there should be a `<uuid>.json` which contains additional metadata like the panic message, span, and system specs.
## Using a Debugger
If you can reproduce the crash consistently, a debugger can be used to inspect the state of the program at the time of the crash, often providing useful insights into the cause of the crash.
You can read more about setting up and using a debugger with Zed, and specifically for debugging crashes [here](./debuggers.md#debugging-panics-and-crashes)
docs/src/development/freebsd.md
-51
View File
@@ -1,51 +0,0 @@
# Building Zed for FreeBSD
Note, FreeBSD is not currently a supported platform, and so this is a work-in-progress.
## Repository
Clone the [Zed repository](https://github.com/zed-industries/zed).
## Dependencies
- Install the necessary system packages and rustup:
```sh
script/freebsd
```
If preferred, you can inspect [`script/freebsd`](https://github.com/zed-industries/zed/blob/main/script/freebsd) and perform the steps manually.
## Building from source
Once the dependencies are installed, you can build Zed using [Cargo](https://doc.rust-lang.org/cargo/).
For a debug build of the editor:
```sh
cargo run
```
And to run the tests:
```sh
cargo test --workspace
```
In release mode, the primary user interface is the `cli` crate. You can run it in development with:
```sh
cargo run -p cli
```
### WebRTC Notice
Currently, building `webrtc-sys` on FreeBSD fails due to missing upstream support and unavailable prebuilt binaries. As a result, some collaboration features (audio calls and screensharing) that depend on WebRTC are temporarily disabled.
See [Issue #15309: FreeBSD Support] and [Discussion #29550: Unofficial FreeBSD port for Zed] for more.
## Troubleshooting
### Cargo errors claiming that a dependency is using unstable features
Try `cargo clean` and `cargo build`.
docs/src/development/glossary.md
-118
View File
@@ -1,118 +0,0 @@
# Zed Development: Glossary
These are some terms and structures frequently used throughout the zed codebase.
This is a best effort list and a work in progress.
<!--
TBD: Glossary Improvement
Questions:
- Can we generate this list from doc comments throughout zed?
- We should have a section that shows the various UI parts and their names. (Can't do that in the channel.)
-->
## Naming conventions
These are generally true for the whole codebase. Note that Name can be anything
here. An example would be `AnyElement` and `LspStore`.
- `AnyName`: A type erased version of _name_. Think `Box<dyn NameTrait>`.
- `NameStore`: A wrapper type which abstracts over whether operations are running locally or on a remote.
## GPUI
### State management
- `App`: A singleton which holds the full application state including all the entities. Crucially: `App` is not `Send`, which means that `App` only exists on the thread that created it (which is the main/UI thread, usually). Thus, if you see a `&mut App`, know that you're on UI thread.
- `Context`: A wrapper around the `App` struct with specialized behavior for a specific `Entity`. Think of it as `(&mut App, Entity<V>)`. The specialized behavior is surfaced in the API surface of `Context`. E.g., `App::spawn` takes an `AsyncFnOnce(AsyncApp) -> Ret`, whereas `Context::spawn` takes an `AsyncFnOnce(WeakEntity<V>, AsyncApp) -> Ret`.
- `AsyncApp`: An owned version of `App` for use in async contexts. This type is _still_ not `Send` (so `AsyncApp` = you're on the main thread) and any use of it may be fallible (to account for the fact that the `App` might've been terminated by the time this closure runs).
The convenience of `AsyncApp` lies in the fact that you usually interface with `App` via `&mut App`, which would be inconvenient to use with async closures; `AsyncApp` is owned, so you can use it in async closures with no sweat.
- `AppContext` A trait which abstracts over `App`, `AsyncApp` & `Context` and their Test versions.
- `Task`: A future running or scheduled to run on the background or foreground
executor. In contradiction to regular Futures Tasks do not need `.await` to start running. You do need to await them to get the result of the task.
- `Executor`: Used to spawn tasks that run either on the foreground or background thread. Try to run the tasks on the background thread.
- `BackgroundExecutor`: A threadpool running `Task`s.
- `ForegroundExecutor`: The main thread running `Task`s.
- `Entity`: A strong, well-typed reference to a struct which is managed by gpui. Effectively a pointer/map key into the `App::EntityMap`.
- `WeakEntity`: A runtime checked reference to an `Entity` which may no longer exist. Similar to [`std::rc::Weak`](https://doc.rust-lang.org/std/rc/struct.Weak.html).
- `Global`: A singleton type which has only one value, that is stored in the `App`.
- `Event`: A datatype which can be send by an `Entity` to subscribers
- `Action`: An event that represents a user's keyboard input that can be handled by listeners
Example: `file finder: toggle`
- `Observing`: reacting entities notifying they've changed
- `Subscription`: An event handler that is used to react to the changes of state in the application.
1. Emitted event handling
2. Observing `{new,release,on notify}` of an entity
### UI
- `View`: An `Entity` which can produce an `Element` through its implementation of `Render`.
- `Element`: A type that can be laid out and painted to the screen.
- `element expression`: An expression that builds an element tree, example:
```rust
h_flex()
.id(text[i])
.relative()
.when(selected, |this| {
this.child(
div()
.h_4()
.absolute()
etc etc
```
- `Component`: A builder which can be rendered turning it into an `Element`.
- `Dispatch tree`: TODO
- `Focus`: The place where keystrokes are handled first
- `Focus tree`: Path from the place that has the current focus to the UI Root. Example <img> TODO
## Zed UI
- `Window`: A struct in zed representing a zed window in your desktop environment (see image below). There can be multiple if you have multiple zed instances open. Mostly passed around for rendering.
- `Modal`: A UI element that floats on top of the rest of the UI
- `Picker`: A struct representing a list of items in floating on top of the UI (Modal). You can select an item and confirm. What happens on select or confirm is determined by the picker's delegate. (The 'Model' in the image below is a picker.)
- `PickerDelegate`: A trait used to specialize behavior for a `Picker`. The `Picker` stores the `PickerDelegate` in the field delegate.
- `Center`: The middle of the zed window, the center is split into multiple `Pane`s. In the codebase this is a field on the `Workspace` struct. (see image below).
- `Pane`: An area in the `Center` where we can place items, such as an editor, multi-buffer or terminal (see image below).
- `Panel`: An `Entity` implementing the `Panel` trait. These can be placed in a `Dock`. In the image below we see the: `ProjectPanel` in the left dock, the `DebugPanel` in the bottom dock, and `AgentPanel` in the right dock. Note `Editor` does not implement `Panel` and hence is not a `Panel`.
- `Dock`: A UI element similar to a `Pane` which can be opened and hidden. There can be up to 3 docks open at a time, left right and below the center. A dock contains one or more `Panel`s not `Pane`s. (see image).
<img width="1921" height="1080" alt="Screenshot for the Pane and Dock features" src="https://github.com/user-attachments/assets/2cb1170e-2850-450d-89bb-73622b5d07b2" />
- `Project`: One or more `Worktree`s
- `Worktree`: Represents either local or remote files.
<img width="552" height="1118" alt="Screenshot for the Worktree feature" src="https://github.com/user-attachments/assets/da5c58e4-b02e-4038-9736-27e3509fdbfa" />
- [Multibuffer](https://zed.dev/docs/multibuffers): A list of Editors, a multi-buffer allows editing multiple files simultaneously. A multi-buffer opens when an operation in Zed returns multiple locations, examples: _search_ or _go to definition_. See project search in the image below.
<img width="800" height="886" alt="Screenshot for the MultiBuffer feature" src="https://github.com/user-attachments/assets/d59dcecd-8ab6-4172-8fb6-b1fc3c3eaf9d" />
## Editor
- `Editor`: _The_ text editor, nearly everything in zed is an `Editor`, even single line inputs. Each pane in the image above contains one or more `Editor` instances.
- `Workspace`: The root of the window
- `Entry`: A file, dir, pending dir or unloaded dir.
- `Buffer`: The in-memory representation of a 'file' together with relevant data such as syntax trees, git status and diagnostics.
- `pending selection`: You have mouse down and you're dragging but you have not yet released.
## Collab
- `Collab session`: Multiple users working in a shared `Project`
- `Upstream client`: The zed client which has shared their workspace
- `Downstream client`: The zed client joining a shared workspace
## Debugger
- `DapStore`: Is an entity that manages debugger sessions
- `debugger::Session`: Is an entity that manages the lifecycle of a debug session and communication with DAPS
- `BreakpointStore`: Is an entity that manages breakpoints states in local and remote instances of Zed
- `DebugSession`: Manages a debug session's UI and running state
- `RunningState`: Directly manages all the views of a debug session
- `VariableList`: The variable and watch list view of a debug session
- `Console`: TODO
- `Terminal`: TODO
- `BreakpointList`: TODO
docs/src/development/linux.md
-224
View File
@@ -1,224 +0,0 @@
# Building Zed for Linux
## Repository
Clone down the [Zed repository](https://github.com/zed-industries/zed).
## Dependencies
- Install [rustup](https://www.rust-lang.org/tools/install)
- Install the necessary system libraries:
```sh
script/linux
```
If you prefer to install the system libraries manually, you can find the list of required packages in the `script/linux` file.
### Backend Dependencies (optional) {#backend-dependencies}
If you are looking to develop Zed collaboration features using a local collaboration server, please see: [Local Collaboration](./local-collaboration.md) docs.
### Linkers {#linker}
On Linux, Rust's default linker is [LLVM's `lld`](https://blog.rust-lang.org/2025/09/18/Rust-1.90.0/). Alternative linkers, especially [Wild](https://github.com/davidlattimore/wild) and [Mold](https://github.com/rui314/mold) can significantly improve clean and incremental build time.
At present Zed uses Mold in CI because it's more mature. For local development Wild is recommended because it's 5-20% faster than Mold.
These linkers can be installed with `script/install-mold` and `script/install-wild`.
To use Wild as your default, add these lines to your `~/.cargo/config.toml`:
```toml
[target.x86_64-unknown-linux-gnu]
linker = "clang"
rustflags = ["-C", "link-arg=--ld-path=wild"]
[target.aarch64-unknown-linux-gnu]
linker = "clang"
rustflags = ["-C", "link-arg=--ld-path=wild"]
```
To use Mold as your default:
```toml
[target.'cfg(target_os = "linux")']
rustflags = ["-C", "link-arg=-fuse-ld=mold"]
```
## Building from source
Once the dependencies are installed, you can build Zed using [Cargo](https://doc.rust-lang.org/cargo/).
For a debug build of the editor:
```sh
cargo run
```
And to run the tests:
```sh
cargo test --workspace
```
In release mode, the primary user interface is the `cli` crate. You can run it in development with:
```sh
cargo run -p cli
```
## Installing a development build
You can install a local build on your machine with:
```sh
./script/install-linux
```
This will build zed and the cli in release mode and make them available at `~/.local/bin/zed`, installing .desktop files to `~/.local/share`.
> **_Note_**: If you encounter linker errors similar to the following:
>
> ```bash
> error: linking with `cc` failed: exit status: 1 ...
> = note: /usr/bin/ld: /tmp/rustcISMaod/libaws_lc_sys-79f08eb6d32e546e.rlib(f8e4fd781484bd36-bcm.o): in function `aws_lc_0_25_0_handle_cpu_env':
> /aws-lc/crypto/fipsmodule/cpucap/cpu_intel.c:(.text.aws_lc_0_25_0_handle_cpu_env+0x63): undefined reference to `__isoc23_sscanf'
> /usr/bin/ld: /tmp/rustcISMaod/libaws_lc_sys-79f08eb6d32e546e.rlib(f8e4fd781484bd36-bcm.o): in function `pkey_rsa_ctrl_str':
> /aws-lc/crypto/fipsmodule/evp/p_rsa.c:741:(.text.pkey_rsa_ctrl_str+0x20d): undefined reference to `__isoc23_strtol'
> /usr/bin/ld: /aws-lc/crypto/fipsmodule/evp/p_rsa.c:752:(.text.pkey_rsa_ctrl_str+0x258): undefined reference to `__isoc23_strtol'
> collect2: error: ld returned 1 exit status
> = note: some `extern` functions couldn't be found; some native libraries may need to be installed or have their path specified
> = note: use the `-l` flag to specify native libraries to link
> = note: use the `cargo:rustc-link-lib` directive to specify the native libraries to link with Cargo (see https://doc.rust-lang.org/cargo/reference/build-scripts.html#rustc-link-lib)
> error: could not compile `remote_server` (bin "remote_server") due to 1 previous error
> ```
>
> **Cause**:
> this is caused by known bugs in aws-lc-rs(doesn't support GCC >= 14): [FIPS fails to build with GCC >= 14](https://github.com/aws/aws-lc-rs/issues/569)
> & [GCC-14 - build failure for FIPS module](https://github.com/aws/aws-lc/issues/2010)
>
> You can refer to [linux: Linker error for remote_server when using script/install-linux](https://github.com/zed-industries/zed/issues/24880) for more information.
>
> **Workarounds**:
> Set the remote server target to `x86_64-unknown-linux-gnu` like so `export REMOTE_SERVER_TARGET=x86_64-unknown-linux-gnu; script/install-linux`
## Wayland & X11
Zed supports both X11 and Wayland. By default, we pick whichever we can find at runtime. If you're on Wayland and want to run in X11 mode, use the environment variable `WAYLAND_DISPLAY=''`.
## Notes for packaging Zed
Thank you for taking on the task of packaging Zed!
### Technical requirements
Zed has two main binaries:
- You will need to build `crates/cli` and make its binary available in `$PATH` with the name `zed`.
- You will need to build `crates/zed` and put it at `$PATH/to/cli/../../libexec/zed-editor`. For example, if you are going to put the cli at `~/.local/bin/zed` put zed at `~/.local/libexec/zed-editor`. As some linux distributions (notably Arch) discourage the use of `libexec`, you can also put this binary at `$PATH/to/cli/../../lib/zed/zed-editor` (e.g. `~/.local/lib/zed/zed-editor`) instead.
- If you are going to provide a `.desktop` file you can find a template in `crates/zed/resources/zed.desktop.in`, and use `envsubst` to populate it with the values required. This file should also be renamed to `$APP_ID.desktop` so that the file [follows the FreeDesktop standards](https://github.com/zed-industries/zed/issues/12707#issuecomment-2168742761). You should also make this desktop file executable (`chmod 755`).
- You will need to ensure that the necessary libraries are installed. You can get the current list by [inspecting the built binary](https://github.com/zed-industries/zed/blob/935cf542aebf55122ce6ed1c91d0fe8711970c82/script/bundle-linux#L65-L67) on your system.
- For an example of a complete build script, see [script/bundle-linux](https://github.com/zed-industries/zed/blob/935cf542aebf55122ce6ed1c91d0fe8711970c82/script/bundle-linux).
- You can disable Zed's auto updates and provide instructions for users who try to update Zed manually by building (or running) Zed with the environment variable `ZED_UPDATE_EXPLANATION`. For example: `ZED_UPDATE_EXPLANATION="Please use flatpak to update zed."`.
- Make sure to update the contents of the `crates/zed/RELEASE_CHANNEL` file to 'nightly', 'preview', or 'stable', with no newline. This will cause Zed to use the credentials manager to remember a user's login.
### Other things to note
At Zed, our priority has been to move fast and bring the latest technology to our users. We've long been frustrated at having software that is slow, out of date, or hard to configure, and so we've built our editor to those tastes.
However, we realize that many distros have other priorities. We want to work with everyone to bring Zed to their favorite platforms. But there is a long way to go:
- Zed is a fast-moving early-phase project. We typically release 2-3 builds per week to fix user-reported issues and release major features.
- There are a couple of other `zed` binaries that may be present on Linux systems ([1](https://openzfs.github.io/openzfs-docs/man/v2.2/8/zed.8.html), [2](https://zed.brimdata.io/docs/commands/zed)). If you want to rename our CLI binary because of these issues, we suggest `zedit`, `zeditor`, or `zed-cli`.
- Zed automatically installs the correct version of common developer tools in the same way as rustup/rbenv/pyenv, etc. We understand this is contentious, [see here](https://github.com/zed-industries/zed/issues/12589).
- We allow users to install extensions locally and from [zed-industries/extensions](https://github.com/zed-industries/extensions). These extensions may install further tooling as needed, such as language servers. In the long run, we would like to make this safer, [see here](https://github.com/zed-industries/zed/issues/12358).
- Zed connects to several online services by default (AI, telemetry, collaboration). AI and our telemetry can be disabled by your users with their zed settings or by patching our [default settings file](https://github.com/zed-industries/zed/blob/main/assets/settings/default.json).
- As a result of the above issues, zed currently does not play nice with sandboxes, [see here](https://github.com/zed-industries/zed/pull/12006#issuecomment-2130421220)
## Flatpak
> Zed's current Flatpak integration exits the sandbox on startup. Workflows that rely on Flatpak's sandboxing may not work as expected.
To build & install the Flatpak package locally follow the steps below:
1. Install Flatpak for your distribution as outlined [here](https://flathub.org/setup).
2. Run the `script/flatpak/deps` script to install the required dependencies.
3. Run `script/flatpak/bundle-flatpak`.
4. Now the package has been installed and has a bundle available at `target/release/{app-id}.flatpak`.
## Memory profiling
[`heaptrack`](https://github.com/KDE/heaptrack) is quite useful for diagnosing memory leaks. To install it:
```sh
$ sudo apt install heaptrack heaptrack-gui
$ cargo install cargo-heaptrack
```
Then, to build and run Zed with the profiler attached:
```sh
$ cargo heaptrack -b zed
```
When this zed instance is exited, terminal output will include a command to run `heaptrack_interpret` to convert the `*.raw.zst` profile to a `*.zst` file which can be passed to `heaptrack_gui` for viewing.
## Perf recording
How to get a flamegraph with resolved symbols from a running zed instance. Use
when zed is using a lot of CPU. Not useful for hangs.
### During the incident
- Find the PID (process ID) using:
`ps -eo size,pid,comm | grep zed | sort | head -n 1 | cut -d ' ' -f 2`
Or find the pid of the command zed-editor with the most ram usage in something
like htop/btop/top.
- Install perf:
On Ubuntu (derivatives) run `sudo apt install linux-tools`.
- Perf Record:
run `sudo perf record -p <pid you just found>`, wait a few seconds to gather data then press Ctrl+C. You should now have a perf.data file
- Make the output file user owned:
run `sudo chown $USER:$USER perf.data`
- Get build info:
Run zed again and type `zed: about` in the command pallet to get the exact commit.
The `data.perf` file can be send to zed together with the exact commit.
### Later
This can be done by Zed staff.
- Build Zed with symbols:
Check out the commit found previously and modify `Cargo.toml`.
Apply the following diff then make a release build.
```diff
[profile.release]
-debug = "limited"
+debug = "full"
```
- Add the symbols to perf database:
`pref buildid-cache -v -a <path to release zed binary>`
- Resolve the symbols from the db:
`perf inject -i perf.data -o perf_with_symbols.data`
- Install flamegraph:
`cargo install cargo-flamegraph`
- Render the flamegraph:
`flamegraph --perfdata perf_with_symbols.data`
## Troubleshooting
### Cargo errors claiming that a dependency is using unstable features
Try `cargo clean` and `cargo build`.
docs/src/development/local-collaboration.md
-207
View File
@@ -1,207 +0,0 @@
# Local Collaboration
1. Ensure you have access to our cloud infrastructure. If you don't have access, you can't collaborate locally at this time.
2. Make sure you've installed Zed's dependencies for your platform:
- [macOS](#macos)
- [Linux](#linux)
- [Windows](#backend-windows)
Note that `collab` can be compiled only with MSVC toolchain on Windows
3. Clone down our cloud repository and follow the instructions in the cloud README
4. Setup the local database for your platform:
- [macOS & Linux](#database-unix)
- [Windows](#database-windows)
5. Run collab:
- [macOS & Linux](#run-collab-unix)
- [Windows](#run-collab-windows)
## Backend Dependencies
If you are developing collaborative features of Zed, you'll need to install the dependencies of zed's `collab` server:
- PostgreSQL
- LiveKit
- Foreman
You can install these dependencies natively or run them under Docker.
### macOS
1. Install [Postgres.app](https://postgresapp.com) or [postgresql via homebrew](https://formulae.brew.sh/formula/postgresql@15):
```sh
brew install postgresql@15
```
2. Install [Livekit](https://formulae.brew.sh/formula/livekit) and [Foreman](https://formulae.brew.sh/formula/foreman)
```sh
brew install livekit foreman
```
- Follow the steps in the [collab README](https://github.com/zed-industries/zed/blob/main/crates/collab/README.md) to configure the Postgres database for integration tests
Alternatively, if you have [Docker](https://www.docker.com/) installed you can bring up all the `collab` dependencies using Docker Compose.
### Linux
1. Install [Postgres](https://www.postgresql.org/download/linux/)
```sh
sudo apt-get install postgresql # Ubuntu/Debian
sudo pacman -S postgresql # Arch Linux
sudo dnf install postgresql postgresql-server # RHEL/Fedora
sudo zypper install postgresql postgresql-server # OpenSUSE
```
2. Install [Livekit](https://github.com/livekit/livekit-cli)
```sh
curl -sSL https://get.livekit.io/cli | bash
```
3. Install [Foreman](https://theforeman.org/manuals/3.15/quickstart_guide.html)
### Windows {#backend-windows}
> This section is still in development. The instructions are not yet complete.
- Install [Postgres](https://www.postgresql.org/download/windows/)
- Install [Livekit](https://github.com/livekit/livekit), optionally you can add the `livekit-server` binary to your `PATH`.
Alternatively, if you have [Docker](https://www.docker.com/) installed you can bring up all the `collab` dependencies using Docker Compose.
### Docker {#Docker}
If you have docker or podman available, you can run the backend dependencies inside containers with Docker Compose:
```sh
docker compose up -d
```
## Database setup
Before you can run the `collab` server locally, you'll need to set up a `zed` Postgres database.
### On macOS and Linux {#database-unix}
```sh
script/bootstrap
```
This script will set up the `zed` Postgres database, and populate it with some users. It requires internet access, because it fetches some users from the GitHub API.
The script will seed the database with various content defined by:
```sh
cat crates/collab/seed.default.json
```
To use a different set of admin users, you can create your own version of that json file and export the `SEED_PATH` environment variable. Note that the usernames listed in the admins list currently must correspond to valid GitHub users.
```json [settings]
{
"admins": ["admin1", "admin2"],
"channels": ["zed"]
}
```
### On Windows {#database-windows}
```powershell
.\script\bootstrap.ps1
```
## Testing collaborative features locally
### On macOS and Linux {#run-collab-unix}
Ensure that Postgres is configured and running, then run Zed's collaboration server and the `livekit` dev server:
```sh
foreman start
# OR
docker compose up
```
Alternatively, if you're not testing voice and screenshare, you can just run `collab` and `cloud`, and not the `livekit` dev server:
```sh
cargo run -p collab -- serve all
```
```sh
cd ../cloud; cargo make dev
```
In a new terminal, run two or more instances of Zed.
```sh
script/zed-local -3
```
This script starts one to four instances of Zed, depending on the `-2`, `-3` or `-4` flags. Each instance will be connected to the local `collab` server, signed in as a different user from `.admins.json` or `.admins.default.json`.
### On Windows {#run-collab-windows}
Since `foreman` is not available on Windows, you can run the following commands in separate terminals:
```powershell
cargo run --package=collab -- serve all
```
If you have added the `livekit-server` binary to your `PATH`, you can run:
```powershell
livekit-server --dev
```
Otherwise,
```powershell
.\path\to\livekit-serve.exe --dev
```
You'll also need to start the cloud server:
```powershell
cd ..\cloud; cargo make dev
```
In a new terminal, run two or more instances of Zed.
```powershell
node .\script\zed-local -2
```
Note that this requires `node.exe` to be in your `PATH`.
## Running a local collab server
> [!NOTE]
> Because of recent changes to our authentication system, Zed will not be able to authenticate itself with, and therefore use, a local collab server.
If you want to run your own version of the zed collaboration service, you can, but note that this is still under development, and there is no support for authentication nor extensions.
Configuration is done through environment variables. By default it will read the configuration from [`.env.toml`](https://github.com/zed-industries/zed/blob/main/crates/collab/.env.toml) and you should use that as a guide for setting this up.
By default Zed assumes that the DATABASE_URL is a Postgres database, but you can make it use Sqlite by compiling with `--features sqlite` and using a sqlite DATABASE_URL with `?mode=rwc`.
To authenticate you must first configure the server by creating a seed.json file that contains at a minimum your github handle. This will be used to create the user on demand.
```json [settings]
{
"admins": ["nathansobo"]
}
```
By default the collab server will seed the database when first creating it, but if you want to add more users you can explicitly reseed them with `SEED_PATH=./seed.json cargo run -p collab seed`
Then when running the zed client you must specify two environment variables, `ZED_ADMIN_API_TOKEN` (which should match the value of `API_TOKEN` in .env.toml) and `ZED_IMPERSONATE` (which should match one of the users in your seed.json)
docs/src/development/macos.md
-150
View File
@@ -1,150 +0,0 @@
# Building Zed for macOS
## Repository
Clone down the [Zed repository](https://github.com/zed-industries/zed).
## Dependencies
- Install [rustup](https://www.rust-lang.org/tools/install)
- Install [Xcode](https://apps.apple.com/us/app/xcode/id497799835?mt=12) from the macOS App Store, or from the [Apple Developer](https://developer.apple.com/download/all/) website. Note this requires a developer account.
> Ensure you launch Xcode after installing, and install the macOS components, which is the default option.
- Install [Xcode command line tools](https://developer.apple.com/xcode/resources/)
```sh
xcode-select --install
```
- Ensure that the Xcode command line tools are using your newly installed copy of Xcode:
```sh
sudo xcode-select --switch /Applications/Xcode.app/Contents/Developer
sudo xcodebuild -license accept
```
- Install `cmake` (required by [a dependency](https://docs.rs/wasmtime-c-api-impl/latest/wasmtime_c_api/))
```sh
brew install cmake
```
### Backend Dependencies (optional) {#backend-dependencies}
If you are looking to develop Zed collaboration features using a local collaboration server, please see: [Local Collaboration](./local-collaboration.md) docs.
## Building Zed from Source
Once you have the dependencies installed, you can build Zed using [Cargo](https://doc.rust-lang.org/cargo/).
For a debug build:
```sh
cargo run
```
For a release build:
```sh
cargo run --release
```
And to run the tests:
```sh
cargo test --workspace
```
## Troubleshooting
### Error compiling metal shaders
```sh
error: failed to run custom build command for gpui v0.1.0 (/Users/path/to/zed)`**
xcrun: error: unable to find utility "metal", not a developer tool or in PATH
```
Try `sudo xcode-select --switch /Applications/Xcode.app/Contents/Developer`
If you're on macOS 26, try `xcodebuild -downloadComponent MetalToolchain`
### Cargo errors claiming that a dependency is using unstable features
Try `cargo clean` and `cargo build`.
### Error: 'dispatch/dispatch.h' file not found
If you encounter an error similar to:
```sh
src/platform/mac/dispatch.h:1:10: fatal error: 'dispatch/dispatch.h' file not found
Caused by:
process didn't exit successfully
--- stdout
cargo:rustc-link-lib=framework=System
cargo:rerun-if-changed=src/platform/mac/dispatch.h
cargo:rerun-if-env-changed=TARGET
cargo:rerun-if-env-changed=BINDGEN_EXTRA_CLANG_ARGS_aarch64-apple-darwin
cargo:rerun-if-env-changed=BINDGEN_EXTRA_CLANG_ARGS_aarch64_apple_darwin
cargo:rerun-if-env-changed=BINDGEN_EXTRA_CLANG_ARGS
```
This file is part of Xcode. Ensure you have installed the Xcode command line tools and set the correct path:
```sh
xcode-select --install
sudo xcode-select --switch /Applications/Xcode.app/Contents/Developer
```
Additionally, set the `BINDGEN_EXTRA_CLANG_ARGS` environment variable:
```sh
export BINDGEN_EXTRA_CLANG_ARGS="--sysroot=$(xcrun --show-sdk-path)"
```
Then clean and rebuild the project:
```sh
cargo clean
cargo run
```
### Tests failing due to `Too many open files (os error 24)`
This error seems to be caused by OS resource constraints. Installing and running tests with `cargo-nextest` should resolve the issue.
- `cargo install cargo-nextest --locked`
- `cargo nextest run --workspace --no-fail-fast`
## Tips & Tricks
### Avoiding continual rebuilds
If you are finding that Zed is continually rebuilding root crates, it may be because
you are pointing your development Zed at the codebase itself.
This causes problems because `cargo run` exports a bunch of environment
variables which are picked up by the `rust-analyzer` that runs in the development
build of Zed. These environment variables are in turn passed to `cargo check`, which
invalidates the build cache of some of the crates we depend on.
You can easily avoid running the built binary on the checked-out Zed codebase using `cargo run
~/path/to/other/project` to ensure that you don't hit this.
### Speeding up verification
If you are building Zed a lot, you may find that macOS continually verifies new
builds which can add a few seconds to your iteration cycles.
To fix this, you can:
- Run `sudo spctl developer-mode enable-terminal` to enable the Developer Tools panel in System Settings.
- In System Settings, search for "Developer Tools" and add your terminal (e.g. iTerm or Ghostty) to the list under "Allow applications to use developer tools"
- Restart your terminal.
Thanks to the nextest developers for publishing [this](https://nexte.st/docs/installation/macos/#gatekeeper).
docs/src/development/release-notes.md
-29
View File
@@ -1,29 +0,0 @@
# Release Notes
Whenever you open a pull request, the body is automatically populated based on this [pull request template](https://github.com/zed-industries/zed/blob/main/.github/pull_request_template.md).
```md
...
Release Notes:
- N/A _or_ Added/Fixed/Improved ...
```
On Wednesdays, we run a [`get-preview-channel-changes`](https://github.com/zed-industries/zed/blob/main/script/get-preview-channel-changes) script that scrapes `Release Notes` lines from pull requests landing in preview, as documented in our [Release](https://zed.dev/docs/development/release-notes) docs.
The script outputs everything below the `Release Notes` line, including additional data such as the pull request author (if not a Zed team member) and a link to the pull request.
If you use `N/A`, the script skips your pull request entirely.
## Guidelines for crafting your `Release Notes` line(s)
- A `Release Notes` line should only be written if the user can see or feel the difference in Zed.
- A `Release Notes` line should be written such that a Zed user can understand what the change is.
Don't assume a user knows technical editor developer lingo; phrase your change in language they understand as a user of a text editor.
- If you want to include technical details about your pull request for other team members to see, do so above the `Release Notes` line.
- Changes to docs should be labeled as `N/A`.
- If your pull request adds/changes a setting or a keybinding, always mention that setting or keybinding.
Don't make the user dig into docs or the pull request to find this information (although it should be included in docs as well).
- For pull requests that are reverts:
- If the item being reverted **has already been shipped**, include a `Release Notes` line explaining why we reverted, as this is a breaking change.
- If the item being reverted **hasn't been shipped**, edit the original PR's `Release Notes` line to be `N/A`; otherwise, it will be included and the compiler of the release notes may not know to skip it, leading to a potentially-awkward situation where we are stating we shipped something we actually didn't.
docs/src/development/windows.md
-259
View File
@@ -1,259 +0,0 @@
# Building Zed for Windows
> The following commands may be executed in any shell.
## Repository
Clone down the [Zed repository](https://github.com/zed-industries/zed).
## Dependencies
- Install [rustup](https://www.rust-lang.org/tools/install)
- Install either [Visual Studio](https://visualstudio.microsoft.com/downloads/) with the optional components `MSVC v*** - VS YYYY C++ x64/x86 build tools` and `MSVC v*** - VS YYYY C++ x64/x86 Spectre-mitigated libs (latest)` (`v***` is your VS version and `YYYY` is year when your VS was released. Pay attention to the architecture and change it to yours if needed.)
- Or, if you prefer to have a slimmer installer of only the MSVC compiler tools, you can install the [build tools](https://visualstudio.microsoft.com/visual-cpp-build-tools/) (+libs as above) and the "Desktop development with C++" workload.
But beware this installation is not automatically picked up by rustup. You must initialize your environment variables by first launching the "developer" shell (cmd/powershell) this installation places in the start menu or in Windows Terminal and then compile.
- Install Windows 11 or 10 SDK depending on your system, but ensure that at least `Windows 10 SDK version 2104 (10.0.20348.0)` is installed on your machine. You can download it from the [Windows SDK Archive](https://developer.microsoft.com/windows/downloads/windows-sdk/)
- Install [CMake](https://cmake.org/download) (required by [a dependency](https://docs.rs/wasmtime-c-api-impl/latest/wasmtime_c_api/)). Or you can install it through Visual Studio Installer, then manually add the `bin` directory to your `PATH`, for example: `C:\Program Files\Microsoft Visual Studio\2022\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin`.
If you can't compile Zed, make sure that you have at least the following components installed in case of a Visual Studio installation:
```json [settings]
{
"version": "1.0",
"components": [
"Microsoft.VisualStudio.Component.CoreEditor",
"Microsoft.VisualStudio.Workload.CoreEditor",
"Microsoft.VisualStudio.Component.VC.Tools.x86.x64",
"Microsoft.VisualStudio.ComponentGroup.WebToolsExtensions.CMake",
"Microsoft.VisualStudio.Component.VC.CMake.Project",
"Microsoft.VisualStudio.Component.Windows11SDK.26100",
"Microsoft.VisualStudio.Component.VC.Runtimes.x86.x64.Spectre"
],
"extensions": []
}
```
Or if in case of just Build Tools, the following components:
```json [settings]
{
"version": "1.0",
"components": [
"Microsoft.VisualStudio.Component.Roslyn.Compiler",
"Microsoft.Component.MSBuild",
"Microsoft.VisualStudio.Component.CoreBuildTools",
"Microsoft.VisualStudio.Workload.MSBuildTools",
"Microsoft.VisualStudio.Component.Windows10SDK",
"Microsoft.VisualStudio.Component.VC.CoreBuildTools",
"Microsoft.VisualStudio.Component.VC.Tools.x86.x64",
"Microsoft.VisualStudio.Component.VC.Redist.14.Latest",
"Microsoft.VisualStudio.Component.Windows11SDK.26100",
"Microsoft.VisualStudio.Component.VC.CMake.Project",
"Microsoft.VisualStudio.Component.TextTemplating",
"Microsoft.VisualStudio.Component.VC.CoreIde",
"Microsoft.VisualStudio.ComponentGroup.NativeDesktop.Core",
"Microsoft.VisualStudio.Workload.VCTools",
"Microsoft.VisualStudio.Component.VC.Runtimes.x86.x64.Spectre"
],
"extensions": []
}
```
The list can be obtained as follows:
- Open the Visual Studio Installer
- Click on `More` in the `Installed` tab
- Click on `Export configuration`
### Backend Dependencies (optional) {#backend-dependencies}
If you are looking to develop Zed collaboration features using a local collaboration server, please see: [Local Collaboration](./local-collaboration.md) docs.
### Notes
You should modify the `pg_hba.conf` file in the `data` directory to use `trust` instead of `scram-sha-256` for the `host` method. Otherwise, the connection will fail with the error `password authentication failed`. The `pg_hba.conf` file typically locates at `C:\Program Files\PostgreSQL\17\data\pg_hba.conf`. After the modification, the file should look like this:
```conf
# IPv4 local connections:
host all all 127.0.0.1/32 trust
# IPv6 local connections:
host all all ::1/128 trust
```
Also, if you are using a non-latin Windows version, you must modify the`lc_messages` parameter in the `postgresql.conf` file in the `data` directory to `English_United States.1252` (or whatever UTF8-compatible encoding you have). Otherwise, the database will panic. The `postgresql.conf` file should look like this:
```conf
# lc_messages = 'Chinese (Simplified)_China.936' # locale for system error message strings
lc_messages = 'English_United States.1252'
```
After this, you should restart the `postgresql` service. Press the `win` key + `R` to launch the `Run` window. Type the `services.msc` and hit the `OK` button to open the Services Manager. Then, find the `postgresql-x64-XX` service, right-click on it, and select `Restart`.
## Building from source
Once you have the dependencies installed, you can build Zed using [Cargo](https://doc.rust-lang.org/cargo/).
For a debug build:
```sh
cargo run
```
For a release build:
```sh
cargo run --release
```
And to run the tests:
```sh
cargo test --workspace
```
## Installing from msys2
Zed does not support unofficial MSYS2 Zed packages built for Mingw-w64. Please report any issues you may have with [mingw-w64-zed](https://packages.msys2.org/base/mingw-w64-zed) to [msys2/MINGW-packages/issues](https://github.com/msys2/MINGW-packages/issues?q=is%3Aissue+is%3Aopen+zed).
Please refer to [MSYS2 documentation](https://www.msys2.org/docs/ides-editors/#zed) first.
## Troubleshooting
### Setting `RUSTFLAGS` env var breaks builds
If you set the `RUSTFLAGS` env var, it will override the `rustflags` settings in `.cargo/config.toml` which is required to properly build Zed.
Since these settings can vary from time to time, the build errors you receive may vary from linker errors, to other stranger errors.
If you'd like to add extra rust flags, you may do 1 of the following in `.cargo/config.toml`:
Add your flags in the build section
```toml
[build]
rustflags = ["-C", "symbol-mangling-version=v0", "--cfg", "tokio_unstable"]
```
Add your flags in the windows target section
```toml
[target.'cfg(target_os = "windows")']
rustflags = [
"--cfg",
"windows_slim_errors",
"-C",
"target-feature=+crt-static",
]
```
Or, you can create a new `.cargo/config.toml` in the same folder as the Zed repo (see below). This is particularly useful if you are doing CI builds since you don't have to edit the original `.cargo/config.toml`.
```
upper_dir
├── .cargo // <-- Make this folder
│ └── config.toml // <-- Make this file
└── zed
├── .cargo
│ └── config.toml
└── crates
├── assistant
└── ...
```
In the new (above) `.cargo/config.toml`, if we wanted to add `--cfg gles` to our rustflags, it would look like this
```toml
[target.'cfg(all())']
rustflags = ["--cfg", "gles"]
```
### Cargo errors claiming that a dependency is using unstable features
Try `cargo clean` and `cargo build`.
### `STATUS_ACCESS_VIOLATION`
This error can happen if you are using the "rust-lld.exe" linker. Consider trying a different linker.
If you are using a global config, consider moving the Zed repository to a nested directory and add a `.cargo/config.toml` with a custom linker config in the parent directory.
See this issue for more information [#12041](https://github.com/zed-industries/zed/issues/12041)
### Invalid RC path selected
Sometimes, depending on the security rules applied to your laptop, you may get the following error while compiling Zed:
```
error: failed to run custom build command for `zed(C:\Users\USER\src\zed\crates\zed)`
Caused by:
process didn't exit successfully: `C:\Users\USER\src\zed\target\debug\build\zed-b24f1e9300107efc\build-script-build` (exit code: 1)
--- stdout
cargo:rerun-if-changed=../../.git/logs/HEAD
cargo:rustc-env=ZED_COMMIT_SHA=25e2e9c6727ba9b77415588cfa11fd969612adb7
cargo:rustc-link-arg=/stack:8388608
cargo:rerun-if-changed=resources/windows/app-icon.ico
package.metadata.winresource does not exist
Selected RC path: 'bin\x64\rc.exe'
--- stderr
The system cannot find the path specified. (os error 3)
warning: build failed, waiting for other jobs to finish...
```
In order to fix this issue, you can manually set the `ZED_RC_TOOLKIT_PATH` environment variable to the RC toolkit path. Usually, you can set it to:
`C:\Program Files (x86)\Windows Kits\10\bin\<SDK_version>\x64`.
See this [issue](https://github.com/zed-industries/zed/issues/18393) for more information.
### Build fails: Path too long
You may receive an error like the following when building
```
error: failed to get `pet` as a dependency of package `languages v0.1.0 (D:\a\zed-windows-builds\zed-windows-builds\crates\languages)`
Caused by:
failed to load source for dependency `pet`
Caused by:
Unable to update https://github.com/microsoft/python-environment-tools.git?rev=ffcbf3f28c46633abd5448a52b1f396c322e0d6c#ffcbf3f2
Caused by:
path too long: 'C:/Users/runneradmin/.cargo/git/checkouts/python-environment-tools-903993894b37a7d2/ffcbf3f/crates/pet-conda/tests/unix/conda_env_without_manager_but_found_in_history/some_other_location/conda_install/conda-meta/python-fastjsonschema-2.16.2-py310hca03da5_0.json'; class=Filesystem (30)
```
In order to solve this, you can enable longpath support for git and Windows.
For git: `git config --system core.longpaths true`
And for Windows with this PS command:
```powershell
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem" -Name "LongPathsEnabled" -Value 1 -PropertyType DWORD -Force
```
For more information on this, please see [win32 docs](https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=powershell)
(note that you will need to restart your system after enabling longpath support)
### Graphics issues
#### Zed fails to launch
Currently, Zed uses Vulkan as its graphics API on Windows. However, Vulkan isn't always the most reliable on Windows, so if Zed fails to launch, it's likely a Vulkan-related issue.
You can check the Zed log at:
`C:\Users\YOU\AppData\Local\Zed\logs\Zed.log`
If you see messages like:
- `Zed failed to open a window: NoSupportedDeviceFound`
- `ERROR_INITIALIZATION_FAILED`
- `GPU Crashed`
- `ERROR_SURFACE_LOST_KHR`
Then Vulkan might not be working properly on your system. In most cases, updating your GPU drivers may help resolve this.
If there's nothing Vulkan-related in the logs and you happen to have Bandicam installed, try uninstalling it. Zed is currently not compatible with Bandicam.
docs/src/diagnostics.md
-70
View File
@@ -1,70 +0,0 @@
# Diagnostics
Zed gets its diagnostics from the language servers and supports both push and pull variants of the LSP which makes it compatible with all existing language servers.
# Regular diagnostics
By default, Zed displays all diagnostics as underlined text in the editor and the scrollbar.
Editor diagnostics could be filtered with the
```json [settings]
"diagnostics_max_severity": null
```
editor setting (possible values: `"off"`, `"error"`, `"warning"`, `"info"`, `"hint"`, `null` (default, all diagnostics)).
The scrollbar ones are configured with the
```json [settings]
"scrollbar": {
"diagnostics": "all",
}
```
configuration (possible values: `"none"`, `"error"`, `"warning"`, `"information"`, `"all"` (default))
The diagnostics could be hovered to display a tooltip with full, rendered diagnostic message.
Or, `editor::GoToDiagnostic` and `editor::GoToPreviousDiagnostic` could be used to navigate between diagnostics in the editor, showing a popover for the currently active diagnostic.
# Inline diagnostics (Error lens)
Zed supports showing diagnostic as lens to the right of the code.
This is disabled by default, but can either be temporarily turned on (or off) using the editor menu, or permanently, using the
```json [settings]
"diagnostics": {
"inline": {
"enabled": true,
"max_severity": null, // same values as the `diagnostics_max_severity` from the editor settings
}
}
```
# Other UI places
## Project Panel
Project panel can have its entries coloured based on the severity of the diagnostics in the file.
To configure, use
```json [settings]
"project_panel": {
"show_diagnostics": "all",
}
```
configuration (possible values: `"off"`, `"errors"`, `"all"` (default))
## Editor tabs
Similar to the project panel, editor tabs can be colorized with the
```json [settings]
"tabs": {
"show_diagnostics": "off",
}
```
configuration (possible values: `"off"` (default), `"errors"`, `"all"`)
docs/src/environment.md
-92
View File
@@ -1,92 +0,0 @@
# Environment Variables
_**Note**: The following only applies to Zed 0.152.0 and later._
Multiple features in Zed are affected by environment variables:
- Tasks
- Built-in terminal
- Look-up of language servers
- Language servers
In order to make the best use of these features, it's helpful to understand where Zed gets its environment variables from and how they're used.
## Where does Zed get its environment variables from?
How Zed was started — whether it's icon was clicked in the macOS Dock or in a Linux window manager, or whether it was started via the CLI `zed` that comes with Zed — influences which environment variables Zed can use.
### Launched from the CLI
If Zed is opened via the CLI (`zed`), it will inherit the environment variables from the surrounding shell session.
That means if you do
```
$ export MY_ENV_VAR=hello
$ zed .
```
the environment variable `MY_ENV_VAR` is now available inside Zed. For example, in the built-in terminal.
Starting with Zed 0.152.0, the CLI `zed` will _always_ pass along its environment to Zed, regardless of whether a Zed instance was previously running or not. Prior to Zed 0.152.0 this was not the case and only the first Zed instance would inherit the environment variables.
### Launched via window manager, Dock, or launcher
When Zed has been launched via the macOS Dock, or a GNOME or KDE icon on Linux, or an application launcher like Alfred or Raycast, it has no surrounding shell environment from which to inherit its environment variables.
In order to still have a useful environment, Zed spawns a login shell in the user's home directory and gets its environment. This environment is then set on the Zed _process_. That means all Zed windows and projects will inherit that home directory environment.
Since that can lead to problems for users that require different environment variables for a project (because they use `direnv`, or `asdf`, or `mise`, ... in that project), when opening project, Zed spawns another login shell. This time in the project's directory. The environment from that login shell is _not_ set on the process (because that would mean opening a new project changes the environment for all Zed windows). Instead, the environment is stored and passed along when running tasks, opening terminals, or spawning language servers.
## Where and how are environment variables used?
There are two sets of environment variables:
1. Environment variables of the Zed process
2. Environment variables stored per project
The variables from (1) are always used, since they are stored on the process itself and every spawned process (tasks, terminals, language servers, ...) will inherit them by default.
The variables from (2) are used explicitly, depending on the feature.
### Tasks
Tasks are spawned with an combined environment. In order of precedence (low to high, with the last overwriting the first):
- the Zed process environment
- if the project was opened from the CLI: the CLI environment
- if the project was not opened from the CLI: the project environment variables obtained by running a login shell in the project's root folder
- optional, explicitly configured environment in settings
### Built-in terminal
Built-in terminals, like tasks, are spawned with an combined environment. In order of precedence (low to high):
- the Zed process environment
- if the project was opened from the CLI: the CLI environment
- if the project was not opened from the CLI: the project environment variables obtained by running a login shell in the project's root folder
- optional, explicitly configured environment in settings
### Look-up of language servers
For some languages the language server adapters lookup the binary in the user's `$PATH`. Examples:
- Go
- Zig
- Rust (if [configured to do so](./languages/rust.md#binary))
- C
- TypeScript
For this look-up, Zed uses the following the environment:
- if the project was opened from the CLI: the CLI environment
- if the project was not opened from the CLI: the project environment variables obtained by running a login shell in the project's root folder
### Language servers
After looking up a language server, Zed starts them.
These language server processes always inherit Zed's process environment. But, depending on the language server look-up, additional environment variables might be set or overwrite the process environment.
- If the language server was found in the project environment's `$PATH`, then the project environment's is passed along to the language server process. Where the project environment comes from depends on how the project was opened, via CLI or not. See previous point on look-up of language servers.
- If the language servers was not found in the project environment, Zed tries to install it globally and start it globally. In that case, the process will inherit Zed's process environment, and — if the project was opened via ClI — from the CLI.
docs/src/extensions.md
-14
View File
@@ -1,14 +0,0 @@
# Extensions
Zed lets you add new functionality using user-defined extensions.
- [Installing Extensions](./extensions/installing-extensions.md)
- [Extension Capabilities](./extensions/capabilities.md)
- [Developing Extensions](./extensions/developing-extensions.md)
- [Developing Language Extensions](./extensions/languages.md)
- [Developing Debugger Extensions](./extensions/debugger-extensions.md)
- [Developing Themes](./extensions/themes.md)
- [Developing Icon Themes](./extensions/icon-themes.md)
- [Developing Slash Commands](./extensions/slash-commands.md)
- [Developing Agent Servers](./extensions/agent-servers.md)
- [Developing MCP Servers](./extensions/mcp-extensions.md)
docs/src/extensions/agent-servers.md
-173
View File
@@ -1,173 +0,0 @@
# Agent Server Extensions
Agent Servers are programs that provide AI agent implementations through the [Agent Client Protocol (ACP)](https://agentclientprotocol.com).
Agent Server Extensions let you package up an Agent Server so that users can install the extension and have your agent easily available to use in Zed.
You can see the current Agent Server extensions either by opening the Extensions tab in Zed (execute the `zed: extensions` command) and changing the filter from `All` to `Agent Servers`, or by visiting [the Zed website](https://zed.dev/extensions?filter=agent-servers).
## Defining Agent Server Extensions
An extension can register one or more agent servers in the `extension.toml` like so:
```toml
[agent_servers.my-agent]
name = "My Agent"
[agent_servers.my-agent.targets.darwin-aarch64]
archive = "https://github.com/owner/repo/releases/download/v1.0.0/agent-darwin-arm64.tar.gz"
cmd = "./agent"
args = ["--serve"]
[agent_servers.my-agent.targets.linux-x86_64]
archive = "https://github.com/owner/repo/releases/download/v1.0.0/agent-linux-x64.tar.gz"
cmd = "./agent"
args = ["--serve"]
[agent_servers.my-agent.targets.windows-x86_64]
archive = "https://github.com/owner/repo/releases/download/v1.0.0/agent-windows-x64.zip"
cmd = "./agent.exe"
args = ["--serve"]
```
### Required Fields
- `name`: A human-readable display name for the agent server (shown in menus)
- `targets`: Platform-specific configurations for downloading and running the agent
### Target Configuration
Each target key uses the format `{os}-{arch}` where:
- **os**: `darwin` (macOS), `linux`, or `windows`
- **arch**: `aarch64` (ARM64) or `x86_64`
Each target must specify:
- `archive`: URL to download the archive from (supports `.tar.gz`, `.zip`, etc.)
- `cmd`: Command to run the agent server (relative to the extracted archive)
- `args`: Command-line arguments to pass to the agent server (optional)
- `sha256`: SHA-256 hash string of the archive's bytes (optional, but recommended for security)
- `env`: Environment variables specific to this target (optional, overrides agent-level env vars with the same name)
### Optional Fields
You can also optionally specify at the agent server level:
- `env`: Environment variables to set in the agent's spawned process. These apply to all targets by default.
- `icon`: Path to an SVG icon (relative to extension root) for display in menus.
### Environment Variables
Environment variables can be configured at two levels:
1. **Agent-level** (`[agent_servers.my-agent.env]`): Variables that apply to all platforms
2. **Target-level** (`[agent_servers.my-agent.targets.{platform}.env]`): Variables specific to a platform
When both are specified, target-level environment variables override agent-level variables with the same name. Variables defined only at the agent level are inherited by all targets.
### Complete Example
Here's a more complete example with all optional fields:
```toml
[agent_servers.example-agent]
name = "Example Agent"
icon = "icon/agent.svg"
[agent_servers.example-agent.env]
AGENT_LOG_LEVEL = "info"
AGENT_MODE = "production"
[agent_servers.example-agent.targets.darwin-aarch64]
archive = "https://github.com/example/agent/releases/download/v2.0.0/agent-darwin-arm64.tar.gz"
cmd = "./bin/agent"
args = ["serve", "--port", "8080"]
sha256 = "abc123def456..."
[agent_servers.example-agent.targets.linux-x86_64]
archive = "https://github.com/example/agent/releases/download/v2.0.0/agent-linux-x64.tar.gz"
cmd = "./bin/agent"
args = ["serve", "--port", "8080"]
sha256 = "def456abc123..."
[agent_servers.example-agent.targets.linux-x86_64.env]
AGENT_MEMORY_LIMIT = "2GB" # Linux-specific override
```
## Installation Process
When a user installs your extension and selects the agent server:
1. Zed downloads the appropriate archive for the user's platform
2. The archive is extracted to a cache directory
3. Zed launches the agent using the specified command and arguments
4. Environment variables are set as configured
5. The agent server runs in the background, ready to assist the user
Archives are cached locally, so subsequent launches are fast.
## Distribution Best Practices
### Use GitHub Releases
GitHub Releases are a reliable way to distribute agent server binaries:
1. Build your agent for each platform (macOS ARM64, macOS x86_64, Linux x86_64, Windows x86_64)
2. Package each build as a compressed archive (`.tar.gz` or `.zip`)
3. Create a GitHub release and upload the archives
4. Use the release URLs in your `extension.toml`
## SHA-256 Hashes
It's good for security to include SHA-256 hashes of your archives in `extension.toml`. Here's how to generate it:
### macOS and Linux
```bash
shasum -a 256 agent-darwin-arm64.tar.gz
```
### Windows
```bash
certutil -hashfile agent-windows-x64.zip SHA256
```
Then add that string to your target configuration:
```toml
[agent_servers.my-agent.targets.darwin-aarch64]
archive = "https://github.com/owner/repo/releases/download/v1.0.0/agent-darwin-arm64.tar.gz"
cmd = "./agent"
sha256 = "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
```
## Testing
To test your Agent Server Extension:
1. [Install it as a dev extension](./developing-extensions.md#developing-an-extension-locally)
2. Open the [Agent Panel](../ai/agent-panel.md)
3. Select your Agent Server from the list
4. Verify that it downloads, installs, and launches correctly
5. Test its functionality by conversing with it and watching the [ACP logs](../ai/external-agents.md#debugging-agents)
## Icon Guideline
In case your agent server has a logo, we highly recommend adding it as an SVG icon.
For optimal display, follow these guidelines:
- Make sure you resize your SVG to fit a 16x16 bounding box, with a padding of around one or two pixels
- Ensure you have a clean SVG code by processing it through [SVGOMG](https://jakearchibald.github.io/svgomg/)
- Avoid including icons with gradients as they will often make the SVG more complicated and possibly not render perfectly
Note that we'll automatically convert your icon to monochrome to preserve Zed's design consistency.
(You can still use opacity in different paths of your SVG to add visual layering.)
---
This is all you need to distribute an agent server through Zed's extension system!
## Publishing
Once your extension is ready, see [Publishing your extension](./developing-extensions.md#publishing-your-extension) to learn how to submit it to the Zed extension registry.
docs/src/extensions/capabilities.md
-96
View File
@@ -1,96 +0,0 @@
# Extension Capabilities
The operations that Zed extensions are able to perform are governed by a capability system.
## Restricting capabilities
As a user, you have the option of restricting the capabilities that are granted to extensions.
This is controlled via the `granted_extension_capabilities` setting.
Restricting or removing a capability will cause an error to be returned when an extension attempts to call the corresponding extension API without sufficient capabilities.
For instance, if you wanted to restrict downloads to just files from GitHub, you could modify `host` for the `download_file` capability:
```diff
{
"granted_extension_capabilities": [
{ "kind": "process:exec", "command": "*", "args": ["**"] },
- { "kind": "download_file", "host": "*", "path": ["**"] },
+ { "kind": "download_file", "host": "github.com", "path": ["**"] },
{ "kind": "npm:install", "package": "*" }
]
}
```
If you don't want extensions to be able to perform _any_ capabilities, you can remove all granted capabilities:
```json
{
"granted_extension_capabilities": []
}
```
> Note that this will likely make many extensions non-functional, at least in their default configuration.
## Capabilities
### `process:exec`
The `process:exec` capability grants extensions the ability to invoke commands using [`zed_extension_api::process::Command`](https://docs.rs/zed_extension_api/latest/zed_extension_api/process/struct.Command.html).
#### Examples
To allow any command to be executed with any arguments:
```toml
{ kind = "process:exec", command = "*", args = ["**"] }
```
To allow a specific command (e.g., `gem`) to be executed with any arguments:
```toml
{ kind = "process:exec", command = "gem", args = ["**"] }
```
### `download_file`
The `download_file` capability grants extensions the ability to download files using [`zed_extension_api::download_file`](https://docs.rs/zed_extension_api/latest/zed_extension_api/fn.download_file.html).
#### Examples
To allow any file to be downloaded:
```toml
{ kind = "download_file", host = "github.com", path = ["**"] }
```
To allow any file to be downloaded from `github.com`:
```toml
{ kind = "download_file", host = "github.com", path = ["**"] }
```
To allow any file to be downloaded from a specific GitHub repository:
```toml
{ kind = "download_file", host = "github.com", path = ["zed-industries", "zed", "**"] }
```
### `npm:install`
The `npm:install` capability grants extensions the ability to install npm packages using [`zed_extension_api::npm_install_package`](https://docs.rs/zed_extension_api/latest/zed_extension_api/fn.npm_install_package.html).
#### Examples
To allow any npm package to be installed:
```toml
{ kind = "npm:install", package = "*" }
```
To allow a specific npm package (e.g., `typescript`) to be installed:
```toml
{ kind = "npm:install", package = "typescript" }
```
docs/src/extensions/debugger-extensions.md
-117
View File
@@ -1,117 +0,0 @@
# Debugger Extensions
[Debug Adapter Protocol](https://microsoft.github.io/debug-adapter-protocol) Servers can be exposed as extensions for use in the [debugger](../debugger.md).
## Defining Debugger Extensions
A given extension may provide one or more DAP servers.
Each DAP server must be registered in the `extension.toml`:
```toml
[debug_adapters.my-debug-adapter]
# Optional relative path to the JSON schema for the debug adapter configuration schema. Defaults to `debug_adapter_schemas/$DEBUG_ADAPTER_NAME_ID.json`.
# Note that while this field is optional, a schema is mandatory.
schema_path = "relative/path/to/schema.json"
```
Then, in the Rust code for your extension, implement the `get_dap_binary` method on your extension:
```rust
impl zed::Extension for MyExtension {
fn get_dap_binary(
&mut self,
adapter_name: String,
config: DebugTaskDefinition,
user_provided_debug_adapter_path: Option<String>,
worktree: &Worktree,
) -> Result<DebugAdapterBinary, String>;
}
```
This method should return the command to start up a debug adapter protocol server, along with any arguments or environment variables necessary for it to function.
If you need to download the DAP server from an external source—like GitHub Releases or npm—you can also do that in this function. Make sure to check for updates only periodically, as this function is called whenever a user spawns a new debug session with your debug adapter.
You must also implement `dap_request_kind`. This function is used to determine whether a given debug scenario will _launch_ a new debuggee or _attach_ to an existing one.
We also use it to determine that a given debug scenario requires running a _locator_.
```rust
impl zed::Extension for MyExtension {
fn dap_request_kind(
&mut self,
_adapter_name: String,
_config: Value,
) -> Result<StartDebuggingRequestArgumentsRequest, String>;
}
```
These two functions are sufficient to expose your debug adapter in `debug.json`-based user workflows, but you should strongly consider implementing `dap_config_to_scenario` as well.
```rust
impl zed::Extension for MyExtension {
fn dap_config_to_scenario(
&mut self,
_adapter_name: DebugConfig,
) -> Result<DebugScenario, String>;
}
```
`dap_config_to_scenario` is used when the user spawns a session via new process modal UI. At a high level, it takes a generic debug configuration (that isn't specific to any
debug adapter) and tries to turn it into a concrete debug scenario for your adapter.
Put another way, it is supposed to answer the question: "Given a program, a list of arguments, current working directory and environment variables, what would the configuration for spawning this debug adapter look like?".
## Defining Debug Locators
Zed offers an automatic way to create debug scenarios with _debug locators_.
A locator locates the debug target and figures out how to spawn a debug session for it. Thanks to locators, we can automatically convert existing user tasks (e.g. `cargo run`) and convert them into debug scenarios (e.g. `cargo build` followed by spawning a debugger with `target/debug/my_program` as the program to debug).
> Your extension can define its own debug locators even if it does not expose a debug adapter. We strongly recommend doing so when your extension already exposes language tasks, as it allows users to spawn a debug session without having to manually configure the debug adapter.
Locators can (but don't have to) be agnostic to the debug adapter they are used with. They are simply responsible for locating the debug target and figuring out how to spawn a debug session for it. This allows for a more flexible and extensible debugging experience.
Your extension can define one or more debug locators. Each debug locator must be registered in the `extension.toml`:
```toml
[debug_locators.my-debug-locator]
```
Locators have two components.
First, each locator is ran on each available task to figure out if any of the available locators can provide a debug scenario for a given task. This is done by calling `dap_locator_create_scenario`.
```rust
impl zed::Extension for MyExtension {
fn dap_locator_create_scenario(
&mut self,
_locator_name: String,
_build_task: TaskTemplate,
_resolved_label: String,
_debug_adapter_name: String,
) -> Option<DebugScenario>;
}
```
This function should return `Some` debug scenario when that scenario defines a debugging counterpart to a given user task.
Note that a `DebugScenario` can include a [build task](../debugger.md#build-tasks). If there is one, we will execute `run_dap_locator` after a build task is finished successfully.
```rust
impl zed::Extension for MyExtension {
fn run_dap_locator(
&mut self,
_locator_name: String,
_build_task: TaskTemplate,
) -> Result<DebugRequest, String>;
}
```
`run_dap_locator` is useful in case you cannot determine a build target deterministically. Some build systems may produce artifacts whose names are not known up-front.
Note however that you do _not_ need to go through a 2-phase resolution; if you can determine the full debug configuration with just `dap_locator_create_scenario`, you can omit `build` property on a returned `DebugScenario`. Please also note that your locator **will be** called with tasks it's unlikely to accept; thus you should take some effort to return `None` early before performing any expensive operations.
## Available Extensions
Check out all the DAP servers that have already been exposed as extensions [on Zed's site](https://zed.dev/extensions?filter=debug-adapters).
We recommend taking a look at their repositories as a way to understand how they are generally created and structured.
## Testing
To test your new Debug Adapter Protocol server extension, you can [install it as a dev extension](./developing-extensions.md#developing-an-extension-locally).
docs/src/extensions/developing-extensions.md
-182
View File
@@ -1,182 +0,0 @@
# Developing Extensions
## Extension Features
Extensions are able to provide the following features to Zed:
- [Languages](./languages.md)
- [Debuggers](./debugger-extensions.md)
- [Themes](./themes.md)
- [Icon Themes](./icon-themes.md)
- [Slash Commands](./slash-commands.md)
- [MCP Servers](./mcp-extensions.md)
## Developing an Extension Locally
Before starting to develop an extension for Zed, be sure to [install Rust via rustup](https://www.rust-lang.org/tools/install).
> Rust must be installed via rustup. If you have Rust installed via homebrew or otherwise, installing dev extensions will not work.
When developing an extension, you can use it in Zed without needing to publish it by installing it as a _dev extension_.
From the extensions page, click the `Install Dev Extension` button (or the {#action zed::InstallDevExtension} action) and select the directory containing your extension.
If you need to troubleshoot, you can check the Zed.log ({#action zed::OpenLog}) for additional output. For debug output, close and relaunch zed with the `zed --foreground` from the command line which show more verbose INFO level logging.
If you already have the published version of the extension installed, the published version will be uninstalled prior to the installation of the dev extension. After successful installation, the `Extensions` page will indicate that the upstream extension is "Overridden by dev extension".
## Directory Structure of a Zed Extension
A Zed extension is a Git repository that contains an `extension.toml`. This file must contain some
basic information about the extension:
```toml
id = "my-extension"
name = "My extension"
version = "0.0.1"
schema_version = 1
authors = ["Your Name <you@example.com>"]
description = "My cool extension"
repository = "https://github.com/your-name/my-zed-extension"
```
In addition to this, there are several other optional files and directories that can be used to add functionality to a Zed extension. An example directory structure of an extension that provides all capabilities is as follows:
```
my-extension/
extension.toml
Cargo.toml
src/
lib.rs
languages/
my-language/
config.toml
highlights.scm
themes/
my-theme.json
```
## WebAssembly
Procedural parts of extensions are written in Rust and compiled to WebAssembly. To develop an extension that includes custom code, include a `Cargo.toml` like this:
```toml
[package]
name = "my-extension"
version = "0.0.1"
edition = "2021"
[lib]
crate-type = ["cdylib"]
[dependencies]
zed_extension_api = "0.1.0"
```
Use the latest version of the [`zed_extension_api`](https://crates.io/crates/zed_extension_api) available on crates.io. Make sure it's still [compatible with Zed versions](https://github.com/zed-industries/zed/blob/main/crates/extension_api#compatible-zed-versions) you want to support.
In the `src/lib.rs` file in your Rust crate you will need to define a struct for your extension and implement the `Extension` trait, as well as use the `register_extension!` macro to register your extension:
```rs
use zed_extension_api as zed;
struct MyExtension {
// ... state
}
impl zed::Extension for MyExtension {
// ...
}
zed::register_extension!(MyExtension);
```
> `stdout`/`stderr` is forwarded directly to the Zed process. In order to see `println!`/`dbg!` output from your extension, you can start Zed in your terminal with a `--foreground` flag.
## Forking and cloning the repo
1. Fork the repo
> Note: It is very helpful if you fork the `zed-industries/extensions` repo to a personal GitHub account instead of a GitHub organization, as this allows Zed staff to push any needed changes to your PR to expedite the publishing process.
2. Clone the repo to your local machine
```sh
# Substitute the url of your fork here:
# git clone https://github.com/zed-industries/extensions
cd extensions
git submodule init
git submodule update
```
## Extension License Requirements
As of October 1st, 2025, extension repositories must include a license.
The following licenses are accepted:
- [Apache 2.0](https://www.apache.org/licenses/LICENSE-2.0)
- [BSD 3-Clause](https://opensource.org/license/bsd-3-clause)
- [GNU GPLv3](https://www.gnu.org/licenses/gpl-3.0.en.html)
- [MIT](https://opensource.org/license/mit)
This allows us to distribute the resulting binary produced from your extension code to our users.
Without a valid license, the pull request to add or update your extension in the following steps will fail CI.
Your license file should be at the root of your extension repository. Any filename that has `LICENCE` or `LICENSE` as a prefix (case insensitive) will be inspected to ensure it matches one of the accepted licenses. See the [license validation source code](https://github.com/zed-industries/extensions/blob/main/src/lib/license.js).
> This license requirement applies only to your extension code itself (the code that gets compiled into the extension binary).
> It does not apply to any tools your extension may download or interact with, such as language servers or other external dependencies.
> If your repository contains both extension code and other projects (like a language server), you are not required to relicense those other projects—only the extension code needs to be one of the aforementioned accepted licenses.
## Publishing your extension
To publish an extension, open a PR to [the `zed-industries/extensions` repo](https://github.com/zed-industries/extensions).
In your PR, do the following:
1. Add your extension as a Git submodule within the `extensions/` directory
```sh
git submodule add https://github.com/your-username/foobar-zed.git extensions/foobar
git add extensions/foobar
```
> All extension submodules must use HTTPS URLs and not SSH URLS (`git@github.com`).
2. Add a new entry to the top-level `extensions.toml` file containing your extension:
```toml
[my-extension]
submodule = "extensions/my-extension"
version = "0.0.1"
```
> If your extension is in a subdirectory within the submodule you can use the `path` field to point to where the extension resides.
3. Run `pnpm sort-extensions` to ensure `extensions.toml` and `.gitmodules` are sorted
Once your PR is merged, the extension will be packaged and published to the Zed extension registry.
> Extension IDs and names should not contain `zed` or `Zed`, since they are all Zed extensions.
## Updating an extension
To update an extension, open a PR to [the `zed-industries/extensions` repo](https://github.com/zed-industries/extensions).
In your PR do the following:
1. Update the extension's submodule to the commit of the new version. For this, you can run
```sh
# From the root of the repository:
git submodule update --remote extensions/your-extension-name
```
to update your extension to the latest commit available in your remote repository.
2. Update the `version` field for the extension in `extensions.toml`
- Make sure the `version` matches the one set in `extension.toml` at the particular commit.
If you'd like to automate this process, there is a [community GitHub Action](https://github.com/huacnlee/zed-extension-action) you can use.
> **Note:** If your extension repository has a different license, you'll need to update it to be one of the [accepted extension licenses](#extension-license-requirements) before publishing your update.
docs/src/extensions/icon-themes.md
-78
View File
@@ -1,78 +0,0 @@
# Icon Themes
Extensions may provide icon themes in order to change the icons Zed uses for folders and files.
## Example extension
The [Material Icon Theme](https://github.com/zed-extensions/material-icon-theme) serves as an example for the structure of an extension containing an icon theme.
## Directory structure
There are two important directories for an icon theme extension:
- `icon_themes`: This directory will contain one or more JSON files containing the icon theme definitions.
- `icons`: This directory contains the icon assets that will be distributed with the extension. You can created subdirectories in this directory, if so desired.
Each icon theme file should adhere to the JSON schema specified at [`https://zed.dev/schema/icon_themes/v0.3.0.json`](https://zed.dev/schema/icon_themes/v0.3.0.json).
Here is an example of the structure of an icon theme:
```json [icon-theme]
{
"$schema": "https://zed.dev/schema/icon_themes/v0.3.0.json",
"name": "My Icon Theme",
"author": "Your Name",
"themes": [
{
"name": "My Icon Theme",
"appearance": "dark",
"directory_icons": {
"collapsed": "./icons/folder.svg",
"expanded": "./icons/folder-open.svg"
},
"named_directory_icons": {
"stylesheets": {
"collapsed": "./icons/folder-stylesheets.svg",
"expanded": "./icons/folder-stylesheets-open.svg"
}
},
"chevron_icons": {
"collapsed": "./icons/chevron-right.svg",
"expanded": "./icons/chevron-down.svg"
},
"file_stems": {
"Makefile": "make"
},
"file_suffixes": {
"mp3": "audio",
"rs": "rust"
},
"file_icons": {
"audio": { "path": "./icons/audio.svg" },
"default": { "path": "./icons/file.svg" },
"make": { "path": "./icons/make.svg" },
"rust": { "path": "./icons/rust.svg" }
// ...
}
}
]
}
```
Each icon path is resolved relative to the root of the extension directory.
In this example, the extension would have a structure like so:
```
extension.toml
icon_themes/
my-icon-theme.json
icons/
audio.svg
chevron-down.svg
chevron-right.svg
file.svg
folder-open.svg
folder.svg
rust.svg
```
docs/src/extensions/installing-extensions.md
-20
View File
@@ -1,20 +0,0 @@
# Installing Extensions
You can search for extensions by launching the Zed Extension Gallery by pressing {#kb zed::Extensions} , opening the command palette and selecting {#action zed::Extensions} or by selecting "Zed > Extensions" from the menu bar.
Here you can view the extensions that you currently have installed or search and install new ones.
## Installation Location
- On macOS, extensions are installed in `~/Library/Application Support/Zed/extensions`.
- On Linux, they are installed in either `$XDG_DATA_HOME/zed/extensions` or `~/.local/share/zed/extensions`.
- On Windows, the directory is `%LOCALAPPDATA%\Zed\extensions`.
This directory contains two subdirectories:
- `installed`, which contains the source code for each extension.
- `work` which contains files created by the extension itself, such as downloaded language servers.
## Auto installing
To automate extension installation/uninstallation see the docs for [auto_install_extensions](../configuring-zed.md#auto-install-extensions).
docs/src/extensions/languages.md
-420
View File
@@ -1,420 +0,0 @@
# Language Extensions
Language support in Zed has several components:
- Language metadata and configuration
- Grammar
- Queries
- Language servers
## Language Metadata
Each language supported by Zed must be defined in a subdirectory inside the `languages` directory of your extension.
This subdirectory must contain a file called `config.toml` file with the following structure:
```toml
name = "My Language"
grammar = "my-language"
path_suffixes = ["myl"]
line_comments = ["# "]
```
- `name` (required) is the human readable name that will show up in the Select Language dropdown.
- `grammar` (required) is the name of a grammar. Grammars are registered separately, described below.
- `path_suffixes` is an array of file suffixes that should be associated with this language. Unlike `file_types` in settings, this does not support glob patterns.
- `line_comments` is an array of strings that are used to identify line comments in the language. This is used for the `editor::ToggleComments` keybind: {#kb editor::ToggleComments} for toggling lines of code.
- `tab_size` defines the indentation/tab size used for this language (default is `4`).
- `hard_tabs` whether to indent with tabs (`true`) or spaces (`false`, the default).
- `first_line_pattern` is a regular expression, that in addition to `path_suffixes` (above) or `file_types` in settings can be used to match files which should use this language. For example Zed uses this to identify Shell Scripts by matching the [shebangs lines](https://github.com/zed-industries/zed/blob/main/crates/languages/src/bash/config.toml) in the first line of a script.
- `debuggers` is an array of strings that are used to identify debuggers in the language. When launching a debugger's `New Process Modal`, Zed will order available debuggers by the order of entries in this array.
<!--
TBD: Document `language_name/config.toml` keys
- autoclose_before
- brackets (start, end, close, newline, not_in: ["comment", "string"])
- word_characters
- prettier_parser_name
- opt_into_language_servers
- code_fence_block_name
- scope_opt_in_language_servers
- increase_indent_pattern, decrease_indent_pattern
- collapsed_placeholder
- auto_indent_on_paste, auto_indent_using_last_non_empty_line
- overrides: `[overrides.element]`, `[overrides.string]`
-->
## Grammar
Zed uses the [Tree-sitter](https://tree-sitter.github.io) parsing library to provide built-in language-specific features. There are grammars available for many languages, and you can also [develop your own grammar](https://tree-sitter.github.io/tree-sitter/creating-parsers#writing-the-grammar). A growing list of Zed features are built using pattern matching over syntax trees with Tree-sitter queries. As mentioned above, every language that is defined in an extension must specify the name of a Tree-sitter grammar that is used for parsing. These grammars are then registered separately in extensions' `extension.toml` file, like this:
```toml
[grammars.gleam]
repository = "https://github.com/gleam-lang/tree-sitter-gleam"
rev = "58b7cac8fc14c92b0677c542610d8738c373fa81"
```
The `repository` field must specify a repository where the Tree-sitter grammar should be loaded from, and the `rev` field must contain a Git revision to use, such as the SHA of a Git commit. If you're developing an extension locally and want to load a grammar from the local filesystem, you can use a `file://` URL for `repository`. An extension can provide multiple grammars by referencing multiple tree-sitter repositories.
## Tree-sitter Queries
Zed uses the syntax tree produced by the [Tree-sitter](https://tree-sitter.github.io) query language to implement
several features:
- Syntax highlighting
- Bracket matching
- Code outline/structure
- Auto-indentation
- Code injections
- Syntax overrides
- Text redactions
- Runnable code detection
- Selecting classes, functions, etc.
The following sections elaborate on how [Tree-sitter queries](https://tree-sitter.github.io/tree-sitter/using-parsers#query-syntax) enable these
features in Zed, using [JSON syntax](https://www.json.org/json-en.html) as a guiding example.
### Syntax highlighting
In Tree-sitter, the `highlights.scm` file defines syntax highlighting rules for a particular syntax.
Here's an example from a `highlights.scm` for JSON:
```scheme
(string) @string
(pair
key: (string) @property.json_key)
(number) @number
```
This query marks strings, object keys, and numbers for highlighting. The following is a comprehensive list of captures supported by themes:
| Capture | Description |
| ------------------------ | -------------------------------------- |
| @attribute | Captures attributes |
| @boolean | Captures boolean values |
| @comment | Captures comments |
| @comment.doc | Captures documentation comments |
| @constant | Captures constants |
| @constructor | Captures constructors |
| @embedded | Captures embedded content |
| @emphasis | Captures emphasized text |
| @emphasis.strong | Captures strongly emphasized text |
| @enum | Captures enumerations |
| @function | Captures functions |
| @hint | Captures hints |
| @keyword | Captures keywords |
| @label | Captures labels |
| @link_text | Captures link text |
| @link_uri | Captures link URIs |
| @number | Captures numeric values |
| @operator | Captures operators |
| @predictive | Captures predictive text |
| @preproc | Captures preprocessor directives |
| @primary | Captures primary elements |
| @property | Captures properties |
| @punctuation | Captures punctuation |
| @punctuation.bracket | Captures brackets |
| @punctuation.delimiter | Captures delimiters |
| @punctuation.list_marker | Captures list markers |
| @punctuation.special | Captures special punctuation |
| @string | Captures string literals |
| @string.escape | Captures escaped characters in strings |
| @string.regex | Captures regular expressions |
| @string.special | Captures special strings |
| @string.special.symbol | Captures special symbols |
| @tag | Captures tags |
| @tag.doctype | Captures doctypes (e.g., in HTML) |
| @text.literal | Captures literal text |
| @title | Captures titles |
| @type | Captures types |
| @variable | Captures variables |
| @variable.special | Captures special variables |
| @variant | Captures variants |
### Bracket matching
The `brackets.scm` file defines matching brackets.
Here's an example from a `brackets.scm` file for JSON:
```scheme
("[" @open "]" @close)
("{" @open "}" @close)
("\"" @open "\"" @close)
```
This query identifies opening and closing brackets, braces, and quotation marks.
| Capture | Description |
| ------- | --------------------------------------------- |
| @open | Captures opening brackets, braces, and quotes |
| @close | Captures closing brackets, braces, and quotes |
Zed uses these to highlight matching brackets: painting each bracket pair with a different color ("rainbow brackets") and highlighting the brackets if the cursor is inside the bracket pair.
To opt out of rainbow brackets colorization, add the following to the corresponding `brackets.scm` entry:
```scheme
(("\"" @open "\"" @close) (#set! rainbow.exclude))
```
### Code outline/structure
The `outline.scm` file defines the structure for the code outline.
Here's an example from an `outline.scm` file for JSON:
```scheme
(pair
key: (string (string_content) @name)) @item
```
This query captures object keys for the outline structure.
| Capture | Description |
| -------------- | ------------------------------------------------------------------------------------ |
| @name | Captures the content of object keys |
| @item | Captures the entire key-value pair |
| @context | Captures elements that provide context for the outline item |
| @context.extra | Captures additional contextual information for the outline item |
| @annotation | Captures nodes that annotate outline item (doc comments, attributes, decorators)[^1] |
[^1]: These annotations are used by Assistant when generating code modification steps.
### Auto-indentation
The `indents.scm` file defines indentation rules.
Here's an example from an `indents.scm` file for JSON:
```scheme
(array "]" @end) @indent
(object "}" @end) @indent
```
This query marks the end of arrays and objects for indentation purposes.
| Capture | Description |
| ------- | -------------------------------------------------- |
| @end | Captures closing brackets and braces |
| @indent | Captures entire arrays and objects for indentation |
### Code injections
The `injections.scm` file defines rules for embedding one language within another, such as code blocks in Markdown or SQL queries in Python strings.
Here's an example from an `injections.scm` file for Markdown:
```scheme
(fenced_code_block
(info_string
(language) @injection.language)
(code_fence_content) @injection.content)
((inline) @content
(#set! injection.language "markdown-inline"))
```
This query identifies fenced code blocks, capturing the language specified in the info string and the content within the block. It also captures inline content and sets its language to "markdown-inline".
| Capture | Description |
| ------------------- | ---------------------------------------------------------- |
| @injection.language | Captures the language identifier for a code block |
| @injection.content | Captures the content to be treated as a different language |
Note that we couldn't use JSON as an example here because it doesn't support language injections.
### Syntax overrides
The `overrides.scm` file defines syntactic _scopes_ that can be used to override certain editor settings within specific language constructs.
For example, there is a language-specific setting called `word_characters` that controls which non-alphabetic characters are considered part of a word, for example when you double click to select a variable. In JavaScript, "$" and "#" are considered word characters.
There is also a language-specific setting called `completion_query_characters` that controls which characters trigger autocomplete suggestions. In JavaScript, when your cursor is within a _string_, "-" is should be considered a completion query character. To achieve this, the JavaScript `overrides.scm` file contains the following pattern:
```scheme
[
(string)
(template_string)
] @string
```
And the JavaScript `config.toml` contains this setting:
```toml
word_characters = ["#", "$"]
[overrides.string]
completion_query_characters = ["-"]
```
You can also disable certain auto-closing brackets in a specific scope. For example, to prevent auto-closing `'` within strings, you could put the following in the JavaScript `config.toml`:
```toml
brackets = [
{ start = "'", end = "'", close = true, newline = false, not_in = ["string"] },
# other pairs...
]
```
#### Range inclusivity
By default, the ranges defined in `overrides.scm` are _exclusive_. So in the case above, if you cursor was _outside_ the quotation marks delimiting the string, the `string` scope would not take effect. Sometimes, you may want to make the range _inclusive_. You can do this by adding the `.inclusive` suffix to the capture name in the query.
For example, in JavaScript, we also disable auto-closing of single quotes within comments. And the comment scope must extend all the way to the newline after a line comment. To achieve this, the JavaScript `overrides.scm` contains the following pattern:
```scheme
(comment) @comment.inclusive
```
### Text objects
The `textobjects.scm` file defines rules for navigating by text objects. This was added in Zed v0.165 and is currently used only in Vim mode.
Vim provides two levels of granularity for navigating around files. Section-by-section with `[]` etc., and method-by-method with `]m` etc. Even languages that don't support functions and classes can work well by defining similar concepts. For example CSS defines a rule-set as a method, and a media-query as a class.
For languages with closures, these typically should not count as functions in Zed. This is best-effort however, as languages like JavaScript do not syntactically differentiate syntactically between closures and top-level function declarations.
For languages with declarations like C, provide queries that match `@class.around` or `@function.around`. The `if` and `ic` text objects will default to these if there is no inside.
If you are not sure what to put in textobjects.scm, both [nvim-treesitter-textobjects](https://github.com/nvim-treesitter/nvim-treesitter-textobjects), and the [Helix editor](https://github.com/helix-editor/helix) have queries for many languages. You can refer to the Zed [built-in languages](https://github.com/zed-industries/zed/tree/main/crates/languages/src) to see how to adapt these.
| Capture | Description | Vim mode |
| ---------------- | ----------------------------------------------------------------------- | ------------------------------------------------ |
| @function.around | An entire function definition or equivalent small section of a file. | `[m`, `]m`, `[M`,`]M` motions. `af` text object |
| @function.inside | The function body (the stuff within the braces). | `if` text object |
| @class.around | An entire class definition or equivalent large section of a file. | `[[`, `]]`, `[]`, `][` motions. `ac` text object |
| @class.inside | The contents of a class definition. | `ic` text object |
| @comment.around | An entire comment (e.g. all adjacent line comments, or a block comment) | `gc` text object |
| @comment.inside | The contents of a comment | `igc` text object (rarely supported) |
For example:
```scheme
; include only the content of the method in the function
(method_definition
body: (_
"{"
(_)* @function.inside
"}")) @function.around
; match function.around for declarations with no body
(function_signature_item) @function.around
; join all adjacent comments into one
(comment)+ @comment.around
```
### Text redactions
The `redactions.scm` file defines text redaction rules. When collaborating and sharing your screen, it makes sure that certain syntax nodes are rendered in a redacted mode to avoid them from leaking.
Here's an example from a `redactions.scm` file for JSON:
```scheme
(pair value: (number) @redact)
(pair value: (string) @redact)
(array (number) @redact)
(array (string) @redact)
```
This query marks number and string values in key-value pairs and arrays for redaction.
| Capture | Description |
| ------- | ------------------------------ |
| @redact | Captures values to be redacted |
### Runnable code detection
The `runnables.scm` file defines rules for detecting runnable code.
Here's an example from a `runnables.scm` file for JSON:
```scheme
(
(document
(object
(pair
key: (string
(string_content) @_name
(#eq? @_name "scripts")
)
value: (object
(pair
key: (string (string_content) @run @script)
)
)
)
)
)
(#set! tag package-script)
(#set! tag composer-script)
)
```
This query detects runnable scripts in package.json and composer.json files.
The `@run` capture specifies where the run button should appear in the editor. Other captures, except those prefixed with an underscore, are exposed as environment variables with a prefix of `ZED_CUSTOM_$(capture_name)` when running the code.
| Capture | Description |
| ------- | ------------------------------------------------------ |
| @\_name | Captures the "scripts" key |
| @run | Captures the script name |
| @script | Also captures the script name (for different purposes) |
<!--
TBD: `#set! tag`
-->
## Language Servers
Zed uses the [Language Server Protocol](https://microsoft.github.io/language-server-protocol/) to provide advanced language support.
An extension may provide any number of language servers. To provide a language server from your extension, add an entry to your `extension.toml` with the name of your language server and the language(s) it applies to. The entry in the list of `languages` has to match the `name` field from the `config.toml` file for that language:
```toml
[language_servers.my-language-server]
name = "My Language LSP"
languages = ["My Language"]
```
Then, in the Rust code for your extension, implement the `language_server_command` method on your extension:
```rust
impl zed::Extension for MyExtension {
fn language_server_command(
&mut self,
language_server_id: &LanguageServerId,
worktree: &zed::Worktree,
) -> Result<zed::Command> {
Ok(zed::Command {
command: get_path_to_language_server_executable()?,
args: get_args_for_language_server()?,
env: get_env_for_language_server()?,
})
}
}
```
You can customize the handling of the language server using several optional methods in the `Extension` trait. For example, you can control how completions are styled using the `label_for_completion` method. For a complete list of methods, see the [API docs for the Zed extension API](https://docs.rs/zed_extension_api).
### Multi-Language Support
If your language server supports additional languages, you can use `language_ids` to map Zed `languages` to the desired [LSP-specific `languageId`](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocumentItem) identifiers:
```toml
[language-servers.my-language-server]
name = "Whatever LSP"
languages = ["JavaScript", "HTML", "CSS"]
[language-servers.my-language-server.language_ids]
"JavaScript" = "javascript"
"TSX" = "typescriptreact"
"HTML" = "html"
"CSS" = "css"
```
docs/src/extensions/mcp-extensions.md
-44
View File
@@ -1,44 +0,0 @@
# MCP Server Extensions
[Model Context Protocol servers](../ai/mcp.md) can be exposed as extensions for use in the Agent Panel.
## Defining MCP Extensions
A given extension may provide one or more MCP servers.
Each MCP server must be registered in the `extension.toml`:
```toml
[context_servers.my-context-server]
```
Then, in the Rust code for your extension, implement the `context_server_command` method on your extension:
```rust
impl zed::Extension for MyExtension {
fn context_server_command(
&mut self,
context_server_id: &ContextServerId,
project: &zed::Project,
) -> Result<zed::Command> {
Ok(zed::Command {
command: get_path_to_context_server_executable()?,
args: get_args_for_context_server()?,
env: get_env_for_context_server()?,
})
}
}
```
This method should return the command to start up an MCP server, along with any arguments or environment variables necessary for it to function.
If you need to download the MCP server from an external source—like GitHub Releases or npm—you can also do that in this function.
## Available Extensions
Check out all the MCP servers that have already been exposed as extensions [on Zed's site](https://zed.dev/extensions?filter=context-servers).
We recommend taking a look at their repositories as a way to understand how they are generally created and structured.
## Testing
To test your new MCP server extension, you can [install it as a dev extension](./developing-extensions.md#developing-an-extension-locally).
docs/src/extensions/slash-commands.md
-138
View File
@@ -1,138 +0,0 @@
# Slash Commands
Extensions may provide slash commands for use in the Assistant.
## Example extension
To see a working example of an extension that provides slash commands, check out the [`slash-commands-example` extension](https://github.com/zed-industries/zed/tree/main/extensions/slash-commands-example).
This extension can be [installed as a dev extension](./developing-extensions.md#developing-an-extension-locally) if you want to try it out for yourself.
## Defining slash commands
A given extension may provide one or more slash commands. Each slash command must be registered in the `extension.toml`.
For example, here is an extension that provides two slash commands: `/echo` and `/pick-one`:
```toml
[slash_commands.echo]
description = "echoes the provided input"
requires_argument = true
[slash_commands.pick-one]
description = "pick one of three options"
requires_argument = true
```
Each slash command may define the following properties:
- `description`: A description of the slash command that will be shown when completing available commands.
- `requires_argument`: Indicates whether a slash command requires at least one argument to run.
## Implementing slash command behavior
To implement behavior for your slash commands, implement `run_slash_command` for your extension.
This method accepts the slash command that will be run, the list of arguments passed to it, and an optional `Worktree`.
This method returns `SlashCommandOutput`, which contains the textual output of the command in the `text` field. The output may also define `SlashCommandOutputSection`s that contain ranges into the output. These sections are then rendered as creases in the Assistant's context editor.
Your extension should `match` on the command name (without the leading `/`) and then execute behavior accordingly:
```rs
impl zed::Extension for MyExtension {
fn run_slash_command(
&self,
command: SlashCommand,
args: Vec<String>,
_worktree: Option<&Worktree>,
) -> Result<SlashCommandOutput, String> {
match command.name.as_str() {
"echo" => {
if args.is_empty() {
return Err("nothing to echo".to_string());
}
let text = args.join(" ");
Ok(SlashCommandOutput {
sections: vec![SlashCommandOutputSection {
range: (0..text.len()).into(),
label: "Echo".to_string(),
}],
text,
})
}
"pick-one" => {
let Some(selection) = args.first() else {
return Err("no option selected".to_string());
};
match selection.as_str() {
"option-1" | "option-2" | "option-3" => {}
invalid_option => {
return Err(format!("{invalid_option} is not a valid option"));
}
}
let text = format!("You chose {selection}.");
Ok(SlashCommandOutput {
sections: vec![SlashCommandOutputSection {
range: (0..text.len()).into(),
label: format!("Pick One: {selection}"),
}],
text,
})
}
command => Err(format!("unknown slash command: \"{command}\"")),
}
}
}
```
## Auto-completing slash command arguments
For slash commands that have arguments, you may also choose to implement `complete_slash_command_argument` to provide completions for your slash commands.
This method accepts the slash command that will be run and the list of arguments passed to it. It returns a list of `SlashCommandArgumentCompletion`s that will be shown in the completion menu.
A `SlashCommandArgumentCompletion` consists of the following properties:
- `label`: The label that will be shown in the completion menu.
- `new_text`: The text that will be inserted when the completion is accepted.
- `run_command`: Whether the slash command will be run when the completion is accepted.
Once again, your extension should `match` on the command name (without the leading `/`) and return the desired argument completions:
```rs
impl zed::Extension for MyExtension {
fn complete_slash_command_argument(
&self,
command: SlashCommand,
_args: Vec<String>,
) -> Result<Vec<SlashCommandArgumentCompletion>, String> {
match command.name.as_str() {
"echo" => Ok(vec![]),
"pick-one" => Ok(vec![
SlashCommandArgumentCompletion {
label: "Option One".to_string(),
new_text: "option-1".to_string(),
run_command: true,
},
SlashCommandArgumentCompletion {
label: "Option Two".to_string(),
new_text: "option-2".to_string(),
run_command: true,
},
SlashCommandArgumentCompletion {
label: "Option Three".to_string(),
new_text: "option-3".to_string(),
run_command: true,
},
]),
command => Err(format!("unknown slash command: \"{command}\"")),
}
}
}
```
docs/src/extensions/themes.md
-53
View File
@@ -1,53 +0,0 @@
# Themes
The `themes` directory in an extension should contain one or more theme files.
Each theme file should adhere to the JSON schema specified at [`https://zed.dev/schema/themes/v0.2.0.json`](https://zed.dev/schema/themes/v0.2.0.json).
See [this blog post](https://zed.dev/blog/user-themes-now-in-preview) for more details about creating themes.
## Theme JSON Structure
The structure of a Zed theme is defined in the [Zed Theme JSON Schema](https://zed.dev/schema/themes/v0.2.0.json).
A Zed theme consists of a Theme Family object including:
- `name`: The name for the theme family
- `author`: The name of the author of the theme family
- `themes`: An array of Themes belonging to the theme family
The core components a Theme object include:
1. Theme Metadata:
- `name`: The name of the theme
- `appearance`: Either "light" or "dark"
2. Style Properties under the `style`, such as:
- `background`: The main background color
- `foreground`: The main text color
- `accent`: The accent color used for highlighting and emphasis
3. Syntax Highlighting:
- `syntax`: An object containing color definitions for various syntax elements (e.g., keywords, strings, comments)
4. UI Elements:
- Colors for various UI components such as:
- `element.background`: Background color for UI elements
- `border`: Border colors for different states (normal, focused, selected)
- `text`: Text colors for different states (normal, muted, accent)
5. Editor-specific Colors:
- Colors for editor-related elements such as:
- `editor.background`: Editor background color
- `editor.gutter`: Gutter colors
- `editor.line_number`: Line number colors
6. Terminal Colors:
- ANSI color definitions for the integrated terminal
We recommend looking at our [existing themes](https://github.com/zed-industries/zed/tree/main/assets/themes) to get a more comprehensive idea of what can be styled.
docs/src/getting-started.md
-19
View File
@@ -1,19 +0,0 @@
# Getting Started
Welcome to Zed! We are excited to have you. Zed is a powerful multiplayer code editor designed to stay out of your way and help you build what's next.
## Key Features
- [Smooth Editing](./configuring-zed.md): Built in Rust, Zed is responsive and intuitive, with a minimalistic aesthetic and pixel-level editing controls.
- [Agentic Editing](./ai/overview.md): Use Zed's hosted models to collaborate with agents directly in an IDE. You can also plug into a third-party agent or bring your own keys.
- [Debugger](./debugger.md): Debug your code in seconds, not hours, with minimal setup required.
- [Remote Development](./remote-development.md): Offload the heavy lifting to the cloud, so you can focus on writing code.
- [Extensions](./extensions.md): Leverage Zed's extensions to customize how you work.
## Join the Zed Community
Zed is proudly open source, and we get better with every contribution. Join us on GitHub or in Discord to contribute code, report bugs, or suggest features.
- [Join Discord](https://discord.com/invite/zedindustries)
- [GitHub Discussions](https://github.com/zed-industries/zed/discussions)
- [Zed Reddit](https://www.reddit.com/r/ZedEditor)
docs/src/git.md
-250
View File
@@ -1,250 +0,0 @@
---
description: Zed is a text editor that supports lots of Git features
title: Zed Editor Git integration documentation
---
# Git
Zed currently offers a set of fundamental Git features, with support coming in the future for more advanced ones, like conflict resolution tools, line by line staging, and more.
Here's an overview of all currently supported features:
- Committing
- Staging, pushing, pulling, and fetching
- Project Diff: A multibuffer view of all changes
- Diff indicators in buffers and editor scrollbars
- Inline diff toggle and reverts in the editor for unstaged changes
- Git status in the Project Panel
- Branch creating and switching
- Git blame viewing
- Git stash pop, apply, drop and view
## Git Panel
The Git Panel gives you a birds-eye view of the state of your working tree and of Git's staging area.
You can open the Git Panel using {#action git_panel::ToggleFocus}, or by clicking the Git icon in the status bar.
In the panel you can see the state of your project at a glance—which repository and branch are active, what files have changed and the current staging state of each file.
Zed monitors your repository so that changes you make on the command line are instantly reflected.
### Configuration
You can configure how Zed hard wraps commit messages with the `preferred-line-length` setting of the "Git Commit" language. The default is `72`, but it can be set to any number of characters `0` or more.
The Git Panel also allows configuring the `soft_wrap` setting to adjust how commit messages display while you are typing them in the Git Panel. The default setting is `editor_width`, however, `none`, `preferred_line_length`, and `bounded` are also options.
#### Example
```json
"languages": {
"Git Commit": {
"soft_wrap": "editor_width",
"preferred_line_length": 72
},
}
```
## Project Diff
You can see all of the changes captured by Git in Zed by opening the Project Diff ({#kb git::Diff}), accessible via the {#action git::Diff} action in the Command Palette or the Git Panel.
All of the changes displayed in the Project Diff behave exactly the same as any other multibuffer: they are all editable excerpts of files.
You can stage or unstage each hunk as well as a whole file by hitting the buttons on the tab bar or their corresponding keybindings.
<!-- Add media -->
## Fetch, push, and pull
Fetch, push, or pull from your Git repository in Zed via the buttons available on the Git Panel or via the Command Palette by looking at the respective actions: {#action git::Fetch}, {#action git::Push}, and {#action git::Pull}.
## Staging Workflow
Zed has two primary staging workflows, using either the Project Diff or the panel directly.
### Using the Project Diff
In the Project Diff view, you can focus on each hunk and stage them individually by clicking on the tab bar buttons or via the keybindings {#action git::StageAndNext} ({#kb git::StageAndNext}).
Similarly, stage all hunks at the same time with the {#action git::StageAll} ({#kb git::StageAll}) keybinding and then immediately commit with {#action git::Commit} ({#kb git::Commit}).
### Using the Git Panel
From the panel, you can simply type a commit message and hit the commit button, or {#action git::Commit}. This will automatically stage all tracked files (indicated by a `[·]` in the entry's checkbox) and commit them.
<!-- Show a set of changes with default staged -->
Entries can be staged using each individual entry's checkbox. All changes can be staged using the button at the top of the panel, or {#action git::StageAll}.
<!-- Add media -->
## Committing
Zed offers two commit textareas:
1. The first one is available right at the bottom of the Git Panel. Hitting {#kb git::Commit} immediately commits all of your staged changes.
2. The second is available via the action {#action git::ExpandCommitEditor} or via hitting the {#kb git::ExpandCommitEditor} while focused in the Git Panel commit textarea.
### Undoing a Commit
As soon as you commit in Zed, in the Git Panel, you'll see a bar right under the commit textarea, which will show the recently submitted commit.
In there, you can use the "Uncommit" button, which performs the `git reset HEADˆ--soft` command.
### Configuring Commit Line Length
By default, Zed sets the commit line length to `72` but it can be configured in your local `settings.json` file.
Find more information about setting the `preferred-line-length` in the [Configuration](#configuration) section.
## Stashing
Git stash allows you to temporarily save your uncommitted changes and revert your working directory to a clean state. This is particularly useful when you need to quickly switch branches or pull updates without committing incomplete work.
### Creating Stashes
To stash all your current changes, use the {#action git::StashAll} action. This will save both staged and unstaged changes to a new stash entry and clean your working directory.
### Managing Stashes
Zed provides a comprehensive stash picker accessible via {#action git::ViewStash}. From the stash picker, you can:
- **View stash list**: Browse all your saved stashes with their descriptions and timestamps
- **Open diffs**: See exactly what changes are stored in each stash
- **Apply stashes**: Apply stash changes to your working directory while keeping the stash entry
- **Pop stashes**: Apply stash changes and remove the stash entry from the list
- **Drop stashes**: Delete unwanted stash entries without applying them
### Quick Stash Operations
For faster workflows, Zed provides direct actions to work with the most recent stash:
- **Apply latest stash**: Use {#action git::StashApply} to apply the most recent stash without removing it
- **Pop latest stash**: Use {#action git::StashPop} to apply and remove the most recent stash
### Stash Diff View
When viewing a specific stash in the diff view, you have additional options available through the interface:
- Apply the current stash to your working directory
- Pop the current stash (apply and remove)
- Remove the stash without applying changes
To open the stash diff view, select a stash from the stash picker and use the {#action stash_picker::ShowStashItem} ({#kb stash_picker::ShowStashItem}) keybinding.
## AI Support in Git
Zed currently supports LLM-powered commit message generation.
You can ask AI to generate a commit message by focusing on the message editor within the Git Panel and either clicking on the pencil icon in the bottom left, or reaching for the {#action git::GenerateCommitMessage} ({#kb git::GenerateCommitMessage}) keybinding.
> Note that you need to have an LLM provider configured for billing purposes, either via your own API keys or trialing/paying for Zed's hosted AI models. Visit [the AI configuration page](./ai/configuration.md) to learn how to do so.
You can specify your preferred model to use by providing a `commit_message_model` agent setting. See [Feature-specific models](./ai/agent-settings.md#feature-specific-models) for more information.
```json [settings]
{
"agent": {
"version": "2",
"commit_message_model": {
"provider": "anthropic",
"model": "claude-3-5-haiku"
}
}
}
```
<!-- Add media -->
More advanced AI integration with Git features may come in the future.
## Git Integrations
Zed integrates with popular Git hosting services to ensure that Git commit hashes and references to Issues, Pull Requests, and Merge Requests become clickable links.
Zed currently supports links to the hosted versions of
[GitHub](https://github.com),
[GitLab](https://gitlab.com),
[Bitbucket](https://bitbucket.org),
[SourceHut](https://sr.ht) and
[Codeberg](https://codeberg.org).
For self-hosted GitHub, GitLab, or Bitbucket instances, add them to the `git_hosting_providers` setting so commit hashes and permalinks resolve to your domain:
```json [settings]
{
"git_hosting_providers": [
{
"provider": "gitlab",
"name": "Corp GitLab",
"base_url": "https://git.example.corp"
}
]
}
```
Zed also has a Copy Permalink feature to create a permanent link to a code snippet on your Git hosting service.
These links are useful for sharing a specific line or range of lines in a file at a specific commit.
Trigger this action via the [Command Palette](./getting-started.md#command-palette) (search for `permalink`),
by creating a [custom key bindings](key-bindings.md#custom-key-bindings) to the
`editor::CopyPermalinkToLine` or `editor::OpenPermalinkToLine` actions
or by simply right clicking and selecting `Copy Permalink` with line(s) selected in your editor.
## Diff Hunk Keyboard Shortcuts
When viewing files with changes, Zed displays diff hunks that can be expanded or collapsed for detailed review:
- **Expand all diff hunks**: {#action editor::ExpandAllDiffHunks} ({#kb editor::ExpandAllDiffHunks})
- **Collapse all diff hunks**: Press `Escape` (bound to {#action editor::Cancel})
- **Toggle selected diff hunks**: {#action editor::ToggleSelectedDiffHunks} ({#kb editor::ToggleSelectedDiffHunks})
- **Navigate between hunks**: {#action editor::GoToHunk} and {#action editor::GoToPreviousHunk}
> **Tip:** The `Escape` key is the quickest way to collapse all expanded diff hunks and return to an overview of your changes.
## Action Reference
| Action | Keybinding |
| ----------------------------------------- | ------------------------------------- |
| {#action git::Add} | {#kb git::Add} |
| {#action git::StageAll} | {#kb git::StageAll} |
| {#action git::UnstageAll} | {#kb git::UnstageAll} |
| {#action git::ToggleStaged} | {#kb git::ToggleStaged} |
| {#action git::StageAndNext} | {#kb git::StageAndNext} |
| {#action git::UnstageAndNext} | {#kb git::UnstageAndNext} |
| {#action git::Commit} | {#kb git::Commit} |
| {#action git::ExpandCommitEditor} | {#kb git::ExpandCommitEditor} |
| {#action git::Push} | {#kb git::Push} |
| {#action git::ForcePush} | {#kb git::ForcePush} |
| {#action git::Pull} | {#kb git::Pull} |
| {#action git::PullRebase} | {#kb git::PullRebase} |
| {#action git::Fetch} | {#kb git::Fetch} |
| {#action git::Diff} | {#kb git::Diff} |
| {#action git::Restore} | {#kb git::Restore} |
| {#action git::RestoreFile} | {#kb git::RestoreFile} |
| {#action git::Branch} | {#kb git::Branch} |
| {#action git::Switch} | {#kb git::Switch} |
| {#action git::CheckoutBranch} | {#kb git::CheckoutBranch} |
| {#action git::Blame} | {#kb git::Blame} |
| {#action git::StashAll} | {#kb git::StashAll} |
| {#action git::StashPop} | {#kb git::StashPop} |
| {#action git::StashApply} | {#kb git::StashApply} |
| {#action git::ViewStash} | {#kb git::ViewStash} |
| {#action editor::ToggleGitBlameInline} | {#kb editor::ToggleGitBlameInline} |
| {#action editor::ExpandAllDiffHunks} | {#kb editor::ExpandAllDiffHunks} |
| {#action editor::ToggleSelectedDiffHunks} | {#kb editor::ToggleSelectedDiffHunks} |
> Not all actions have default keybindings, but can be bound by [customizing your keymap](./key-bindings.md#user-keymaps).
## Git CLI Configuration
If you would like to also use Zed for your [git commit message editor](https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration#_core_editor) when committing from the command line you can use `zed --wait`:
```sh
git config --global core.editor "zed --wait"
```
Or add the following to your shell environment (in `~/.zshrc`, `~/.bashrc`, etc):
```sh
export GIT_EDITOR="zed --wait"
```
docs/src/globs.md
-80
View File
@@ -1,80 +0,0 @@
# Globs
Zed supports the use of [glob](<https://en.wikipedia.org/wiki/Glob_(programming)>) patterns that are the formal name for Unix shell-style path matching wildcards like `*.md` or `docs/src/**/*.md` supported by sh, bash, zsh, etc. A glob is similar but distinct from a [regex (regular expression)](https://en.wikipedia.org/wiki/Regular_expression). You may be In Zed these are commonly used when matching filenames.
## Glob Flavor
Zed uses two different rust crates for matching glob patterns:
- [ignore crate](https://docs.rs/ignore/latest/ignore/) for matching glob patterns stored in `.gitignore` files
- [glob crate](https://docs.rs/glob/latest/glob/) for matching file paths in Zed
While simple expressions are portable across environments (e.g. running `ls *.py` or `*.tmp` in a gitignore) there is significant divergence in the support for and syntax of more advanced features varies (character classes, exclusions, `**`, etc) across implementations. For the rest of this document we will be describing globs as supported in Zed via the `glob` crate implementation. Please see [References](#references) below for documentation links for glob pattern syntax for `.gitignore`, shells and other programming languages.
The `glob` crate is implemented entirely in rust and does not rely on the `glob` / `fnmatch` interfaces provided by your platforms libc. This means that globs in Zed should behave similarly with across platforms.
## Introduction
A glob "pattern" is used to match a file name or complete file path. For example, when using "Search all files" {#kb project_search::ToggleFocus} you can click the funnel shaped Toggle Filters" button or {#kb project_search::ToggleFilters} and it will show additional search fields for "Include" and "Exclude" which support specifying glob patterns for matching file paths and file names.
When creating a glob pattern you can use one or multiple special characters:
| Special Character | Meaning |
| ----------------- | ----------------------------------------------------------------- |
| `?` | Matches any single character |
| `*` | Matches any (possibly empty) sequence of characters |
| `**` | Matches the current directory and arbitrary subdirectories |
| `[abc]` | Matches any one character in the brackets |
| `[a-z]` | Matches any of a range of characters (ordered by Unicode) |
| `[!...]` | The negation of `[...]` (matches a character not in the brackets) |
Notes:
1. Shell-style brace-expansions like `{a,b,c}` are not supported.
2. To match a literal `-` character inside brackets it must come first `[-abc]` or last `[abc-]`.
3. To match the literal `[` character use `[[]` or put it as the first character in the group `[[abc]`.
4. To match the literal `]` character use `[]]` or put it as the last character in the group `[abc]]`.
## Examples
### Matching file extensions
If you wanted to only search Markdown files add `*.md` to the "Include" search field.
### Case insensitive matching
Globs in Zed are case-sensitive, so `*.c` will not match `main.C` (even on case-insensitive filesystems like HFS+/APFS on macOS). Instead use brackets to match characters. So instead of `*.c` use `*.[cC]`.
### Matching directories
If you wanted to search the [zed repository](https://github.com/zed-industries/zed) for examples of [Configuring Language Servers](https://zed.dev/docs/configuring-languages#configuring-language-servers) (under `"lsp"` in Zed settings.json) you could search for `"lsp"` and in the "Include" filter specify `docs/**/*.md`. This would only match files whose path was under the `docs` directory or any nested subdirectories `**/` of that folder with a filename that ends in `.md`.
If instead you wanted to restrict yourself only to [Zed Language-Specific Documentation](https://zed.dev/docs/languages) pages you could define a narrower pattern of: `docs/src/languages/*.md` this would match [`docs/src/languages/rust.md`](https://github.com/zed-industries/zed/blob/main/docs/src/languages/rust.md) and [`docs/src/languages/cpp.md`](https://github.com/zed-industries/zed/blob/main/docs/src/languages/cpp.md) but not [`docs/src/configuring-languages.md`](https://github.com/zed-industries/zed/blob/main/docs/src/configuring-languages.md).
### Implicit Wildcards
When using the "Include" / "Exclude" filters on a Project Search each glob is wrapped in implicit wildcards. For example to exclude any files with license in the path or filename from your search just type `license` in the exclude box. Behind the scenes Zed transforms `license` to `**license**`. This means that files named `license.*`, `*.license` or inside a `license` subdirectory will all be filtered out. This enables users to easily filter for `*.ts` without having to remember to type `**/*.ts` every time.
Alternatively, if in your Zed settings you wanted a [`file_types`](./configuring-zed.md#file-types) override which only applied to a certain directory you must explicitly include the wildcard globs. For example, if you had a directory of template files with the `html` extension that you wanted to recognize as Jinja2 template you could use the following:
```json [settings]
{
"file_types": {
"C++": ["[cC]"],
"Jinja2": ["**/templates/*.html"]
}
}
```
## References
While globs in Zed are implemented as described above, when writing code using globs in other languages, please reference your platform's glob documentation:
- [macOS fnmatch](https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/fnmatch.3.html) (BSD C Standard Library)
- [Linux fnmatch](https://www.gnu.org/software/libc/manual/html_node/Wildcard-Matching.html) (GNU C Standard Library)
- [POSIX fnmatch](https://pubs.opengroup.org/onlinepubs/9699919799/functions/fnmatch.html) (POSIX Specification)
- [node-glob](https://github.com/isaacs/node-glob) (Node.js `glob` package)
- [Python glob](https://docs.python.org/3/library/glob.html) (Python Standard Library)
- [Golang glob](https://pkg.go.dev/path/filepath#Match) (Go Standard Library)
- [gitignore patterns](https://git-scm.com/docs/gitignore) (Gitignore Pattern Format)
- [PowerShell: About Wildcards](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_wildcards) (Wildcards in PowerShell)
docs/src/helix.md
-15
View File
@@ -1,15 +0,0 @@
# Helix Mode
_Work in progress! Not all Helix keybindings are implemented yet._
Zed's Helix mode is an emulation layer that brings Helix-style keybindings and modal editing to Zed. It builds upon Zed's [Vim mode](./vim.md), so much of the core functionality is shared. Enabling `helix_mode` will also enable `vim_mode`.
For a guide on Vim-related features that are also available in Helix mode, please refer to our [Vim mode documentation](./vim.md).
To check the current status of Helix mode, or to request a missing Helix feature, checkout out the ["Are we Helix yet?" discussion](https://github.com/zed-industries/zed/discussions/33580).
For a detailed list of Helix's default keybindings, please visit the [official Helix documentation](https://docs.helix-editor.com/keymap.html).
## Core differences
Any text object that works with `m i` or `m a` also works with `]` and `[`, so for example `] (` selects the next pair of parentheses after the cursor.
docs/src/icon-themes.md
-35
View File
@@ -1,35 +0,0 @@
# Icon Themes
Zed comes with a built-in icon theme, with more icon themes available as extensions.
## Selecting an Icon Theme
See what icon themes are installed and preview them via the Icon Theme Selector, which you can open from the command palette with `icon theme selector: toggle`.
Navigating through the icon theme list by moving up and down will change the icon theme in real time and hitting enter will save it to your settings file.
## Installing more Icon Themes
More icon themes are available from the Extensions page, which you can access via the command palette with `zed: extensions` or the [Zed website](https://zed.dev/extensions?filter=icon-themes).
## Configuring Icon Themes
Your selected icon theme is stored in your settings file.
You can open your settings file from the command palette with {#action zed::OpenSettingsFile} (bound to {#kb zed::OpenSettingsFile}).
Just like with themes, Zed allows for configuring different icon themes for light and dark mode.
You can set the mode to `"light"` or `"dark"` to ignore the current system mode.
```json [settings]
{
"icon_theme": {
"mode": "system",
"light": "Light Icon Theme",
"dark": "Dark Icon Theme"
}
}
```
## Icon Theme Development
See: [Developing Zed Icon Themes](./extensions/icon-themes.md)
docs/src/installation.md
-109
View File
@@ -1,109 +0,0 @@
# Installing Zed
## Download Zed
### macOS
Get the latest stable builds via [the download page](https://zed.dev/download). If you want to download our preview build, you can find it on its [releases page](https://zed.dev/releases/preview). After the first manual installation, Zed will periodically check for install updates.
You can also install Zed stable via Homebrew:
```sh
brew install --cask zed
```
As well as Zed preview:
```sh
brew install --cask zed@preview
```
### Windows
Get the latest stable builds via [the download page](https://zed.dev/download). If you want to download our preview build, you can find it on its [releases page](https://zed.dev/releases/preview). After the first manual installation, Zed will periodically check for install updates.
### Linux
For most Linux users, the easiest way to install Zed is through our installation script:
```sh
curl -f https://zed.dev/install.sh | sh
```
If you'd like to help us test our new features, you can also install our preview build:
```sh
curl -f https://zed.dev/install.sh | ZED_CHANNEL=preview sh
```
This script supports `x86_64` and `AArch64`, as well as common Linux distributions: Ubuntu, Arch, Debian, RedHat, CentOS, Fedora, and more.
If Zed is installed using this installation script, it can be uninstalled at any time by running the shell command `zed --uninstall`. The shell will then prompt you whether you'd like to keep your preferences or delete them. After making a choice, you should see a message that Zed was successfully uninstalled.
If this script is insufficient for your use case, you run into problems running Zed, or there are errors in uninstalling Zed, please see our [Linux-specific documentation](./linux.md).
## System Requirements
### macOS
Zed supports the follow macOS releases:
| Version | Codename | Apple Status | Zed Status |
| ------------- | -------- | -------------- | ------------------- |
| macOS 26.x | Tahoe | Supported | Supported |
| macOS 15.x | Sequoia | Supported | Supported |
| macOS 14.x | Sonoma | Supported | Supported |
| macOS 13.x | Ventura | Supported | Supported |
| macOS 12.x | Monterey | EOL 2024-09-16 | Supported |
| macOS 11.x | Big Sur | EOL 2023-09-26 | Partially Supported |
| macOS 10.15.x | Catalina | EOL 2022-09-12 | Partially Supported |
The macOS releases labelled "Partially Supported" (Big Sur and Catalina) do not support screen sharing via Zed Collaboration. These features use the [LiveKit SDK](https://livekit.io) which relies upon [ScreenCaptureKit.framework](https://developer.apple.com/documentation/screencapturekit/) only available on macOS 12 (Monterey) and newer.
#### Mac Hardware
Zed supports machines with Intel (x86_64) or Apple (aarch64) processors that meet the above macOS requirements:
- MacBook Pro (Early 2015 and newer)
- MacBook Air (Early 2015 and newer)
- MacBook (Early 2016 and newer)
- Mac Mini (Late 2014 and newer)
- Mac Pro (Late 2013 or newer)
- iMac (Late 2015 and newer)
- iMac Pro (all models)
- Mac Studio (all models)
### Linux
Zed supports 64-bit Intel/AMD (x86_64) and 64-bit Arm (aarch64) processors.
Zed requires a Vulkan 1.3 driver and the following desktop portals:
- `org.freedesktop.portal.FileChooser`
- `org.freedesktop.portal.OpenURI`
- `org.freedesktop.portal.Secret` or `org.freedesktop.Secrets`
### Windows
Zed supports the following Windows releases:
| Version | Zed Status |
| ------------------------- | ------------------- |
| Windows 11, version 22H2 and later | Supported |
| Windows 10, version 1903 and later | Supported |
A 64-bit operating system is required to run Zed.
#### Windows Hardware
Zed supports machines with x64 (Intel, AMD) or Arm64 (Qualcomm) processors that meet the following requirements:
- Graphics: A GPU that supports DirectX 11 (most PCs from 2012+).
- Driver: Current NVIDIA/AMD/Intel/Qualcomm driver (not the Microsoft Basic Display Adapter).
### FreeBSD
Not yet available as an official download. Can be built [from source](./development/freebsd.md).
### Web
Not supported at this time. See our [Platform Support issue](https://github.com/zed-industries/zed/issues/5391).
docs/src/key-bindings.md
-299
View File
@@ -1,299 +0,0 @@
# Key bindings
Zed has a very customizable key binding system—you can tweak everything to work exactly how your fingers expect!
## Predefined Keymaps
If you're used to a specific editor's defaults, you can change your `base_keymap` through the settings window ({#kb zed::OpenSettings}) or directly through your `settings.json` file ({#kb zed::OpenSettingsFile}).
We currently support:
- VS Code (default)
- Atom
- Emacs (Beta)
- JetBrains
- Sublime Text
- TextMate
- Cursor
- None (disables _all_ key bindings)
This setting can also be changed via the command palette through the `zed: toggle base keymap selector` action.
You can also enable `vim_mode` or `helix_mode`, which add modal bindings.
For more information, see the documentation for [Vim mode](./vim.md) and [Helix mode](./helix.md).
## Keymap Editor
You can access the keymap editor through the {#kb zed::OpenKeymap} action or by running {#action zed::OpenKeymap} action from the command palette. You can easily add or change a keybind for an action with the `Change Keybinding` or `Add Keybinding` button on the command pallets left bottom corner.
In there, you can see all of the existing actions in Zed as well as the associated keybindings set to them by default.
You can also customize them right from there, either by clicking on the pencil icon that appears when you hover over a particular action, by double-clicking on the action row, or by pressing the `enter` key.
Anything that you end up doing on the keymap editor also gets reflected on the `keymap.json` file.
## User Keymaps
The keymap file is stored in the following locations for each platform:
- macOS/Linux: `~/.config/zed/keymap.json`
- Windows: `~\AppData\Roaming\Zed/keymap.json`
You can open the keymap with the {#action zed::OpenKeymapFile} action from the command palette.
This file contains a JSON array of objects with `"bindings"`.
If no `"context"` is set, the bindings are always active.
If it is set, the binding is only active when the [context matches](#contexts).
Within each binding section, a [key sequence](#keybinding-syntax) is mapped to [an action](#actions).
If conflicts are detected, they are resolved as [described below](#precedence).
If you are using a non-QWERTY, Latin-character keyboard, you may want to set `use_key_equivalents` to `true`. See [Non-QWERTY keyboards](#non-qwerty-keyboards) for more information.
For example:
```json [keymap]
[
{
"bindings": {
"ctrl-right": "editor::SelectLargerSyntaxNode",
"ctrl-left": "editor::SelectSmallerSyntaxNode"
}
},
{
"context": "ProjectPanel && not_editing",
"bindings": {
"o": "project_panel::Open"
}
}
]
```
You can see all of Zed's default bindings for each platform in the default keymaps files:
- [macOS](https://github.com/zed-industries/zed/blob/main/assets/keymaps/default-macos.json)
- [Windows](https://github.com/zed-industries/zed/blob/main/assets/keymaps/default-windows.json)
- [Linux](https://github.com/zed-industries/zed/blob/main/assets/keymaps/default-linux.json).
If you want to debug problems with custom keymaps, you can use `dev: Open Key Context View` from the command palette.
Please file [an issue](https://github.com/zed-industries/zed) if you run into something you think should work but isn't.
### Keybinding Syntax
Zed has the ability to match against not just a single keypress, but a sequence of keys typed in order. Each key in the `"bindings"` map is a sequence of keypresses separated with a space.
Each keypress is a sequence of modifiers followed by a key. The modifiers are:
- `ctrl-` The control key
- `cmd-`, `win-` or `super-` for the platform modifier (Command on macOS, Windows key on Windows, and the Super key on Linux).
- `alt-` for alt (option on macOS)
- `shift-` The shift key
- `fn-` The function key
- `secondary-` Equivalent to `cmd` when Zed is running on macOS and `ctrl` when on Windows and Linux
The keys can be any single Unicode codepoint that your keyboard generates (for example `a`, `0`, `£` or `ç`), or any named key (`tab`, `f1`, `shift`, or `cmd`). If you are using a non-Latin layout (e.g. Cyrillic), you can bind either to the Cyrillic character or the Latin character that key generates with `cmd` pressed.
A few examples:
```json [settings]
"bindings": {
"cmd-k cmd-s": "zed::OpenKeymap", // matches ⌘-k then ⌘-s
"space e": "editor::Complete", // type space then e
"ç": "editor::Complete", // matches ⌥-c
"shift shift": "file_finder::Toggle", // matches pressing and releasing shift twice
}
```
The `shift-` modifier can only be used in combination with a letter to indicate the uppercase version. For example, `shift-g` matches typing `G`. Although on many keyboards shift is used to type punctuation characters like `(`, the keypress is not considered to be modified, and so `shift-(` does not match.
The `alt-` modifier can be used on many layouts to generate a different key. For example, on a macOS US keyboard, the combination `alt-c` types `ç`. You can match against either in your keymap file, though by convention, Zed spells this combination as `alt-c`.
It is possible to match against typing a modifier key on its own. For example, `shift shift` can be used to implement JetBrains' 'Search Everywhere' shortcut. In this case, the binding happens on key release instead of on keypress.
### Contexts
If a binding group has a `"context"` key, it will be matched against the currently active contexts in Zed.
Zed's contexts make up a tree, with the root being `Workspace`. Workspaces contain Panes and Panels, and Panes contain Editors, etc. The easiest way to see what contexts are active at a given moment is the key context view, which you can get to with the `dev: open key context view` command in the command palette.
For example:
```
# in an editor, it might look like this:
Workspace os=macos keyboard_layout=com.apple.keylayout.QWERTY
Pane
Editor mode=full extension=md vim_mode=insert
# in the project panel
Workspace os=macos
Dock
ProjectPanel not_editing
```
Context expressions can contain the following syntax:
- `X && Y`, `X || Y` to and/or two conditions
- `!X` to check that a condition is false
- `(X)` for grouping
- `X > Y` to match if an ancestor in the tree matches X and this layer matches Y.
For example:
- `"context": "Editor"` - matches any editor (including inline inputs)
- `"context": "Editor && mode == full"` - matches the main editors used for editing code
- `"context": "!Editor && !Terminal"` - matches anywhere except where an Editor or Terminal is focused
- `"context": "os == macos > Editor"` - matches any editor on macOS.
It's worth noting that attributes are only available on the node they are defined on. This means that if you want to (for example) only enable a keybinding when the debugger is stopped in vim normal mode, you need to do `debugger_stopped > vim_mode == normal`.
> Note: Before Zed v0.197.x, the `!` operator only looked at one node at a time, and `>` meant "parent" not "ancestor". This meant that `!Editor` would match the context `Workspace > Pane > Editor`, because (confusingly) the Pane matches `!Editor`, and that `os == macos > Editor` did not match the context `Workspace > Pane > Editor` because of the intermediate `Pane` node.
If you're using Vim mode, we have information on how [vim modes influence the context](./vim.md#contexts). Helix mode is built on top of Vim mode and uses the same contexts.
### Actions
Almost all of Zed's functionality is exposed as actions.
Although there is no explicitly documented list, you can find most of them by searching in the command palette, by looking in the default keymaps for [macOS](https://github.com/zed-industries/zed/blob/main/assets/keymaps/default-macos.json), [Windows](https://github.com/zed-industries/zed/blob/main/assets/keymaps/default-windows.json) or [Linux](https://github.com/zed-industries/zed/blob/main/assets/keymaps/default-linux.json), or by using Zed's autocomplete in your keymap file.
Most actions do not require any arguments, and so you can bind them as strings: `"ctrl-a": "language_selector::Toggle"`. Some require a single argument and must be bound as an array: `"cmd-1": ["workspace::ActivatePane", 0]`. Some actions require multiple arguments and are bound as an array of a string and an object: `"ctrl-a": ["pane::DeploySearch", { "replace_enabled": true }]`.
### Precedence
When multiple keybindings have the same keystroke and are active at the same time, precedence is resolved in two ways:
- Bindings that match on lower nodes in the context tree win. This means that if you have a binding with a context of `Editor`, it will take precedence over a binding with a context of `Workspace`. Bindings with no context match at the lowest level in the tree.
- If there are multiple bindings that match at the same level in the tree, then the binding defined later takes precedence. As user keybindings are loaded after system keybindings, this allows user bindings to take precedence over built-in keybindings.
The other kind of conflict that arises is when you have two bindings, one of which is a prefix of the other. For example, if you have `"ctrl-w":"editor::DeleteToNextWordEnd"` and `"ctrl-w left":"editor::DeleteToEndOfLine"`.
When this happens, and both bindings are active in the current context, Zed will wait for 1 second after you type `ctrl-w` to see if you're about to type `left`. If you don't type anything, or if you type a different key, then `DeleteToNextWordEnd` will be triggered. If you do, then `DeleteToEndOfLine` will be triggered.
### Non-QWERTY keyboards
Zed's support for non-QWERTY keyboards is still a work in progress.
If your keyboard can type the full ASCII range (DVORAK, COLEMAK, etc.), then shortcuts should work as you expect.
Otherwise, read on...
#### macOS
On Cyrillic, Hebrew, Armenian, and other keyboards that are mostly non-ASCII, macOS automatically maps keys to the ASCII range when `cmd` is held. Zed takes this a step further, and it can always match key-presses against either the ASCII layout or the real layout, regardless of modifiers and the `use_key_equivalents` setting. For example, in Thai, pressing `ctrl-ๆ` will match bindings associated with `ctrl-q` or `ctrl-ๆ`.
On keyboards that support extended Latin alphabets (French AZERTY, German QWERTZ, etc.), it is often not possible to type the entire ASCII range without `option`. This introduces an ambiguity: `option-2` produces `@`. To ensure that all the built-in keyboard shortcuts can still be typed on these keyboards, we move key bindings around. For example, shortcuts bound to `@` on QWERTY are moved to `"` on a Spanish layout. This mapping is based on the macOS system defaults and can be seen by running `dev: open key context view` from the command palette.
If you are defining shortcuts in your personal keymap, you can opt into the key equivalent mapping by setting `use_key_equivalents` to `true` in your keymap:
```json [keymap]
[
{
"use_key_equivalents": true,
"bindings": {
"ctrl->": "editor::Indent" // parsed as ctrl-: when a German QWERTZ keyboard is active
}
}
]
```
### Linux
Since v0.196.0, on Linux, if the key that you type doesn't produce an ASCII character, then we use the QWERTY-layout equivalent key for keyboard shortcuts. This means that many shortcuts can be typed on many layouts.
We do not yet move shortcuts around to ensure that all the built-in shortcuts can be typed on every layout, so if there are some ASCII characters that cannot be typed, and your keyboard layout has different ASCII characters on the same keys as would be needed to type them, you may need to add custom key bindings to make this work. We do intend to fix this at some point, and help is very much appreciated!
## Tips and tricks
### Disabling a binding
If you'd like a given binding to do nothing in a given context, you can use
`null` as the action. This is useful if you hit the key binding by accident and
want to disable it, or if you want to type the character that would be typed by
the sequence, or if you want to disable multikey bindings starting with that key.
```json [keymap]
[
{
"context": "Workspace",
"bindings": {
"cmd-r": null // cmd-r will do nothing when the Workspace context is active
}
}
]
```
A `null` binding follows the same precedence rules as normal actions, so it disables all bindings that would match further up in the tree too. If you'd like a binding that matches further up in the tree to take precedence over a lower binding, you need to rebind it to the action you want in the context you want.
This is useful for preventing Zed from falling back to a default key binding when the action you specified is conditional and propagates. For example, `buffer_search::DeployReplace` only triggers when the search bar is not in view. If the search bar is in view, it would propagate and trigger the default action set for that key binding, such as opening the right dock. To prevent this from happening:
```json [keymap]
[
{
"context": "Workspace",
"bindings": {
"cmd-r": null // cmd-r will do nothing when the search bar is in view
}
},
{
"context": "Workspace",
"bindings": {
"cmd-r": "buffer_search::DeployReplace" // cmd-r will deploy replace when the search bar is not in view
}
}
]
```
### Remapping keys
A common request is to be able to map from a single keystroke to a sequence. You can do this with the `workspace::SendKeystrokes` action.
```json [keymap]
[
{
"bindings": {
// Move down four times
"alt-down": ["workspace::SendKeystrokes", "down down down down"],
// Expand the selection (editor::SelectLargerSyntaxNode);
// copy to the clipboard; and then undo the selection expansion.
"cmd-alt-c": [
"workspace::SendKeystrokes",
"ctrl-shift-right ctrl-shift-right ctrl-shift-right cmd-c ctrl-shift-left ctrl-shift-left ctrl-shift-left"
]
}
},
{
"context": "Editor && vim_mode == insert",
"bindings": {
"j k": ["workspace::SendKeystrokes", "escape"]
}
}
]
```
There are some limitations to this, notably:
- Any asynchronous operation will not happen until after all your key bindings have been dispatched. For example, this means that while you can use a binding to open a file (as in the `cmd-alt-r` example), you cannot send further keystrokes and hope to have them interpreted by the new view.
- Other examples of asynchronous things are: opening the command palette, communicating with a language server, changing the language of a buffer, anything that hits the network.
- There is a limit of 100 simulated keys at a time.
The argument to `SendKeystrokes` is a space-separated list of keystrokes (using the same syntax as above). Due to the way that keystrokes are parsed, any segment that is not recognized as a keypress will be sent verbatim to the currently focused input field.
If the argument to `SendKeystrokes` contains the binding used to trigger it, it will use the next-highest-precedence definition of that binding. This allows you to extend the default behavior of a key binding.
### Forward keys to terminal
If you're on Linux or Windows, you might find yourself wanting to forward key combinations to the built-in terminal instead of them being handled by Zed.
For example, `ctrl-n` creates a new tab in Zed on Linux. If you want to send `ctrl-n` to the built-in terminal when it's focused, add the following to your keymap:
```json [settings]
{
"context": "Terminal",
"bindings": {
"ctrl-n": ["terminal::SendKeystroke", "ctrl-n"]
}
}
```
### Task Key bindings
You can also bind keys to launch Zed Tasks defined in your `tasks.json`.
See the [tasks documentation](tasks.md#custom-keybindings-for-tasks) for more.
docs/src/languages.md
-168
View File
@@ -1,168 +0,0 @@
# Language Support in Zed
Zed supports hundreds of programming languages and text formats.
Some work out-of-the box and others rely on 3rd party extensions.
> The ones included out-of-the-box, natively built into Zed, are marked with \*.
## Languages with Documentation
- [Ansible](./languages/ansible.md)
- [AsciiDoc](./languages/asciidoc.md)
- [Astro](./languages/astro.md)
- [Bash](./languages/bash.md)
- [Biome](./languages/biome.md)
- [C](./languages/c.md) \*
- [C++](./languages/cpp.md) \*
- [C#](./languages/csharp.md)
- [Clojure](./languages/clojure.md)
- [CSS](./languages/css.md) \*
- [Dart](./languages/dart.md)
- [Deno](./languages/deno.md)
- [Diff](./languages/diff.md) \*
- [Docker](./languages/docker.md)
- [Elixir](./languages/elixir.md)
- [Elm](./languages/elm.md)
- [Emmet](./languages/emmet.md)
- [Erlang](./languages/erlang.md)
- [Fish](./languages/fish.md)
- [GDScript](./languages/gdscript.md)
- [Gleam](./languages/gleam.md)
- [GLSL](./languages/glsl.md)
- [Go](./languages/go.md) \*
- [Groovy](./languages/groovy.md)
- [Haskell](./languages/haskell.md)
- [Helm](./languages/helm.md)
- [HTML](./languages/html.md)
- [Java](./languages/java.md)
- [JavaScript](./languages/javascript.md) \*
- [Julia](./languages/julia.md)
- [JSON](./languages/json.md) \*
- [Jsonnet](./languages/jsonnet.md)
- [Kotlin](./languages/kotlin.md)
- [Lua](./languages/lua.md)
- [Luau](./languages/luau.md)
- [Makefile](./languages/makefile.md)
- [Markdown](./languages/markdown.md) \*
- [Nim](./languages/nim.md)
- [OCaml](./languages/ocaml.md)
- [PHP](./languages/php.md)
- [Prisma](./languages/prisma.md)
- [Proto](./languages/proto.md)
- [PureScript](./languages/purescript.md)
- [Python](./languages/python.md) \*
- [R](./languages/r.md)
- [Rego](./languages/rego.md)
- [ReStructuredText](./languages/rst.md)
- [Racket](./languages/racket.md)
- [Roc](./languages/roc.md)
- [Ruby](./languages/ruby.md)
- [Rust](./languages/rust.md) \* (Zed's written in Rust)
- [Scala](./languages/scala.md)
- [Scheme](./languages/scheme.md)
- [Shell Script](./languages/sh.md)
- [Svelte](./languages/svelte.md)
- [Swift](./languages/swift.md)
- [Tailwind CSS](./languages/tailwindcss.md) \*
- [Terraform](./languages/terraform.md)
- [TOML](./languages/toml.md)
- [TypeScript](./languages/typescript.md) \*
- [Uiua](./languages/uiua.md)
- [Vue](./languages/vue.md)
- [XML](./languages/xml.md)
- [YAML](./languages/yaml.md) \*
- [Yara](./languages/yarn.md)
- [Yarn](./languages/yarn.md)
- [Zig](./languages/zig.md)
## Additional Community Language Extensions
- [Ada](https://github.com/wisn/zed-ada-language)
- [Aiken](https://github.com/aiken-lang/zed-aiken)
- [Amber](https://github.com/amber-lang/zed-amber-extension)
- [Assembly](https://github.com/DevBlocky/zed-asm)
- [AWK](https://github.com/dangh/zed-awk)
- [Beancount](https://github.com/zed-extensions/beancount)
- [Bend](https://github.com/mrpedrobraga/zed-bend)
- [Blade](https://github.com/bajrangCoder/zed-laravel-blade)
- [Blueprint](https://github.com/tfuxu/zed-blueprint)
- [BQN](https://github.com/DavidZwitser/zed-bqn)
- [Brainfuck](https://github.com/JosephTLyons/zed-brainfuck)
- [Cadence](https://github.com/janezpodhostnik/cadence.zed)
- [Cairo](https://github.com/trbutler4/zed-cairo)
- [Cap'n Proto](https://github.com/cmackenzie1/zed-capnp)
- [Cedar](https://github.com/chrnorm/zed-cedar)
- [CFEngine policy language](https://github.com/olehermanse/zed-cfengine)
- [CSV](https://github.com/huacnlee/zed-csv)
- [Cucumber/Gherkin](https://github.com/thlcodes/zed-extension-cucumber)
- [CUE](https://github.com/jkasky/zed-cue)
- [Curry](https://github.com/fwcd/zed-curry)
- [D](https://github.com/staysail/zed-d)
- [Database Markup Language (DBML)](https://github.com/shuklaayush/zed-dbml)
- [Earthfile](https://github.com/glehmann/earthfile.zed)
- [EJS template](https://github.com/dangh/zed-ejs)
- [Elisp](https://github.com/JosephTLyons/zed-elisp)
- [Ember](https://github.com/jylamont/zed-ember)
- [Env](https://github.com/zarifpour/zed-env)
- [Exograph](https://github.com/exograph/zed-extension)
- [Fortran](https://github.com/Xavier-Maruff/zed-fortran)
- [F#](https://github.com/nathanjcollins/zed-fsharp)
- [Gemini gemtext](https://github.com/clseibold/gemini-zed)
- [Git Firefly](https://github.com/d1y/git_firefly)
- [GraphQL](https://github.com/11bit/zed-extension-graphql)
- [Groq](https://github.com/juice49/zed-groq)
- [INI](https://github.com/bajrangCoder/zed-ini)
- [Java](https://github.com/zed-extensions/java)
- [Justfiles](https://github.com/jackTabsCode/zed-just)
- [LaTeX](https://github.com/rzukic/zed-latex)
- [Ledger](https://github.com/mrkstwrt/zed-ledger)
- [Less](https://github.com/jimliang/zed-less)
- [LilyPond](https://github.com/nwhetsell/lilypond-zed-extension)
- [Liquid](https://github.com/TheBeyondGroup/zed-shopify-liquid)
- [Log](https://github.com/evrensen467/zed-log)
- [Lox](https://github.com/arian81/zed-lox)
- [Markdown Oxide](https://github.com/Feel-ix-343/markdown-oxide-zed)
- [Marksman](https://github.com/vitallium/zed-marksman)
- [Matlab](https://github.com/rzukic/zed-matlab)
- [Meson](https://github.com/hqnna/zed-meson)
- [Navi](https://github.com/navi-language/zed-navi)
- [NeoCMake](https://github.com/k0tran/zed_neocmake)
- [Nginx](https://github.com/d1y/nginx-zed)
- [Nim](https://github.com/foxoman/zed-nim)
- [Nix](https://github.com/zed-extensions/nix)
- [Noir](https://github.com/shuklaayush/zed-noir)
- [Nu](https://github.com/zed-extensions/nu)
- [Odin](https://github.com/rxptr/zed-odin)
- [Pact](https://github.com/kadena-community/pact-zed)
- [Pest](https://github.com/pest-parser/zed-pest)
- [PICA200 assembly](https://github.com/Squareheron942/zed-pica200)
- [Pkl](https://github.com/Moshyfawn/pkl-zed)
- [PlaydateSDK](https://github.com/notpeter/playdate-zed-extension)
- [QML](https://github.com/lkroll/zed-qml)
- [Rainbow CSV](https://github.com/weartist/zed-rainbow-csv)
- [Rego](https://github.com/StyraInc/zed-rego)
- [Rescript](https://github.com/humaans/rescript-zed)
- [Roclang](https://github.com/h2000/zed-roc)
- [Ron](https://github.com/onbjerg/zed-ron)
- [Metals](https://github.com/scalameta/metals-zed)
- [SCSS](https://github.com/bajrangCoder/zed-scss)
- [Slim](https://github.com/calmyournerves/zed-slim)
- [Slint](https://gitlab.com/flukejones/zed-slint)
- [Smithy](https://github.com/joshrutkowski/zed-smithy)
- [Solidity](https://github.com/zarifpour/zed-solidity)
- [SQL](https://github.com/evrensen467/zed-sql)
- [Strace](https://github.com/sigmaSd/zed-strace)
- [Swift](https://github.com/zed-extensions/swift)
- [Templ](https://github.com/makifdb/zed-templ)
- [Tmux](https://github.com/dangh/zed-tmux)
- [Twig](https://github.com/YussufSassi/zed-twig)
- [Typst](https://github.com/WeetHet/typst.zed)
- [Unison](https://github.com/zetashift/unison-zed)
- [UnoCSS](https://github.com/bajrangCoder/zed-unocss)
- [Vlang](https://github.com/lv37/zed-v)
- [Vala](https://github.com/FyraLabs/zed-vala)
- [Vale](https://github.com/koozz/zed-vale)
- [Verilog](https://github.com/someone13574/zed-verilog-extension)
- [VHS](https://github.com/eth0net/zed-vhs)
- [Wgsl](https://github.com/luan/zed-wgsl)
- [WIT](https://github.com/valentinegb/zed-wit)
docs/src/languages/ansible.md
-130
View File
@@ -1,130 +0,0 @@
# Ansible
Support for Ansible in Zed is provided via a community-maintained [Ansible extension](https://github.com/kartikvashistha/zed-ansible).
- Tree-sitter: [zed-industries/tree-sitter-yaml](https://github.com/zed-industries/tree-sitter-yaml)
- Language Server: [ansible/vscode-ansible](https://github.com/ansible/vscode-ansible/tree/main/packages/ansible-language-server)
## Setup
### File detection
To avoid mishandling non-Ansible YAML files, the Ansible Language is not associated with any file extensions by default. To change this behavior you can add a `"file_types"` section to Zed settings inside your project (`.zed/settings.json`) or your Zed user settings (`~/.config/zed/settings.json`) to match your folder/naming conventions. For example:
```json [settings]
"file_types": {
"Ansible": [
"**.ansible.yml",
"**.ansible.yaml",
"**/defaults/*.yml",
"**/defaults/*.yaml",
"**/meta/*.yml",
"**/meta/*.yaml",
"**/tasks/*.yml",
"**/tasks/*.yaml",
"**/handlers/*.yml",
"**/handlers/*.yaml",
"**/group_vars/*.yml",
"**/group_vars/*.yaml",
"**/host_vars/*.yml",
"**/host_vars/*.yaml",
"**/playbooks/*.yml",
"**/playbooks/*.yaml",
"**playbook*.yml",
"**playbook*.yaml"
]
}
```
Feel free to modify this list as per your needs.
#### Inventory
If your inventory file is in the YAML format, you can either:
- Append the `ansible-lint` inventory json schema to it via the following comment at the top of your inventory file:
```yml
# yaml-language-server: $schema=https://raw.githubusercontent.com/ansible/ansible-lint/main/src/ansiblelint/schemas/inventory.json
```
- Or configure the yaml language server settings to set this schema for all your inventory files, that match your inventory pattern, under your Zed settings ([ref](https://zed.dev/docs/languages/yaml)):
```json [settings]
"lsp": {
"yaml-language-server": {
"settings": {
"yaml": {
"schemas": {
"https://raw.githubusercontent.com/ansible/ansible-lint/main/src/ansiblelint/schemas/inventory.json": [
"./inventory/*.yaml",
"hosts.yml",
]
}
}
}
}
},
```
### LSP Configuration
By default, the following default config is passed to the Ansible language server. It conveniently mirrors the defaults set by [nvim-lspconfig](https://github.com/neovim/nvim-lspconfig/blob/03bc581e05e81d33808b42b2d7e76d70adb3b595/lua/lspconfig/configs/ansiblels.lua) for the Ansible language server:
```json [settings]
{
"ansible": {
"ansible": {
"path": "ansible"
},
"executionEnvironment": {
"enabled": false
},
"python": {
"interpreterPath": "python3"
},
"validation": {
"enabled": true,
"lint": {
"enabled": true,
"path": "ansible-lint"
}
}
}
}
```
> [!NOTE]
> In order for linting to work, ensure that `ansible-lint` is installed and discoverable on your PATH
When desired, any of the above default settings can be overridden under the `"lsp"` section of your Zed settings file. For example:
```json [settings]
"lsp": {
// Note, the Zed Ansible extension prefixes all settings with `ansible`
// so instead of using `ansible.ansible.path` use `ansible.path`.
"ansible-language-server": {
"settings": {
"ansible": {
"path": "ansible"
},
"executionEnvironment": {
"enabled": false
},
"python": {
"interpreterPath": "python3"
},
"validation": {
"enabled": false, // disable validation
"lint": {
"enabled": false, // disable ansible-lint
"path": "ansible-lint"
}
}
}
}
}
```
A full list of options/settings, that can be passed to the server, can be found at the project's page [here](https://github.com/ansible/vscode-ansible/blob/5a89836d66d470fb9d20e7ea8aa2af96f12f61fb/docs/als/settings.md).
Feel free to modify option values as needed.
docs/src/languages/asciidoc.md
-6
View File
@@ -1,6 +0,0 @@
# AsciiDoc
AsciiDoc language support in Zed is provided by the community-maintained [AsciiDoc extension](https://github.com/andreicek/zed-asciidoc).
Report issues to: [https://github.com/andreicek/zed-asciidoc/issues](https://github.com/andreicek/zed-asciidoc/issues)
- Tree-sitter: [cathaysia/tree-sitter-asciidoc](https://github.com/cathaysia/tree-sitter-asciidoc)
docs/src/languages/astro.md
-10
View File
@@ -1,10 +0,0 @@
# Astro
Astro support is available through the [Astro extension](https://github.com/zed-extensions/astro).
- Tree-sitter: [virchau13/tree-sitter-astro](https://github.com/virchau13/tree-sitter-astro)
- Language Server: [withastro/language-tools](https://github.com/withastro/astro/tree/main/packages/language-tools/language-server)
<!--
TBD: Documentation Astro usage / configuration
-->
docs/src/languages/bash.md
-36
View File
@@ -1,36 +0,0 @@
# Bash
Bash language support in Zed is provided by the community-maintained [Basher extension](https://github.com/d1y/bash.zed).
Report issues to: [https://github.com/d1y/bash.zed/issues](https://github.com/d1y/bash.zed/issues)
- Tree-sitter: [tree-sitter/tree-sitter-bash](https://github.com/tree-sitter/tree-sitter-bash)
- Language Server: [bash-lsp/bash-language-server](https://github.com/bash-lsp/bash-language-server)
## Configuration
When `shellcheck` is available `bash-language-server` will use it internally to provide diagnostics.
### Install `shellcheck`:
```sh
brew install shellcheck # macOS (HomeBrew)
apt-get install shellcheck # Ubuntu/Debian
pacman -S shellcheck # ArchLinux
dnf install shellcheck # Fedora
yum install shellcheck # CentOS/RHEL
zypper install shellcheck # openSUSE
choco install shellcheck # Windows (Chocolatey)
```
And verify it is available from your path:
```sh
which shellcheck
shellcheck --version
```
If you wish to customize the warnings/errors reported you just need to create a `.shellcheckrc` file. You can do this in the root of your project or in your home directory (`~/.shellcheckrc`). See: [shellcheck documentation](https://github.com/koalaman/shellcheck/wiki/Ignore#ignoring-one-or-more-types-of-errors-forever) for more.
### See also:
- [Zed Docs: Language Support: Shell Scripts](./sh.md)
docs/src/languages/biome.md
-35
View File
@@ -1,35 +0,0 @@
# Biome
[Biome](https://biomejs.dev/) support in Zed is provided by the community-maintained [Biome extension](https://github.com/biomejs/biome-zed).
Report issues to: [https://github.com/biomejs/biome-zed/issues](https://github.com/biomejs/biome-zed/issues)
- Language Server: [biomejs/biome](https://github.com/biomejs/biome)
## Biome Language Support
The Biome extension includes support for the following languages:
- JavaScript
- TypeScript
- JSX
- TSX
- JSON
- JSONC
- Vue.js
- Astro
- Svelte
- CSS
## Configuration
By default, the `biome.json` file is required to be in the root of the workspace.
```json [settings]
{
"$schema": "https://biomejs.dev/schemas/1.8.3/schema.json"
}
```
For a full list of `biome.json` options see [Biome Configuration](https://biomejs.dev/reference/configuration/) documentation.
See the [Biome Zed Extension README](https://github.com/biomejs/biome-zed) for a complete list of features and configuration options.
docs/src/languages/c.md
-91
View File
@@ -1,91 +0,0 @@
# C
C support is available natively in Zed.
- Tree-sitter: [tree-sitter/tree-sitter-c](https://github.com/tree-sitter/tree-sitter-c)
- Language Server: [clangd/clangd](https://github.com/clangd/clangd)
- Debug Adapter: [CodeLLDB](https://github.com/vadimcn) (primary), [GDB](https://sourceware.org/gdb/) (secondary, not available on Apple silicon)
## Clangd: Force detect as C
Clangd out of the box assumes mixed C++/C projects. If you have a C-only project you may wish to instruct clangd to treat all files as C using the `-xc` flag. To do this, create a `.clangd` file in the root of your project with the following:
```yaml
# yaml-language-server: $schema=https://json.schemastore.org/clangd.json
CompileFlags:
Add: [-xc]
```
By default clang and gcc will recognize `*.C` and `*.H` (uppercase extensions) as C++ and not C and so Zed too follows this convention. If you are working with a C-only project (perhaps one with legacy uppercase pathing like `FILENAME.C`) you can override this behavior by adding this to your settings:
```json [settings]
{
"file_types": {
"C": ["C", "H"]
}
}
```
## Formatting
By default Zed will use the `clangd` language server for formatting C code like the `clang-format` CLI tool. To configure this you can add a `.clang-format` file. For example:
```yaml
# yaml-language-server: $schema=https://json.schemastore.org/clang-format-21.x.json
---
BasedOnStyle: GNU
IndentWidth: 2
---
```
See [Clang-Format Style Options](https://clang.llvm.org/docs/ClangFormatStyleOptions.html) for a complete list of options.
You can trigger formatting via {#kb editor::Format} or the `editor: format` action from the command palette or by adding `format_on_save` to your Zed settings:
```json [settings]
"languages": {
"C": {
"format_on_save": "on",
"tab_size": 2
}
}
```
## Compile Commands
For some projects Clangd requires a `compile_commands.json` file to properly analyze your project. This file contains the compilation database that tells clangd how your project should be built.
### CMake Compile Commands
With CMake, you can generate `compile_commands.json` automatically by adding the following line to your `CMakeLists.txt`:
```cmake
set(CMAKE_EXPORT_COMPILE_COMMANDS ON)
```
After building your project, CMake will generate the `compile_commands.json` file in the build directory and clangd will automatically pick it up.
## Debugging
You can use CodeLLDB or GDB to debug native binaries. (Make sure that your build process passes `-g` to the C compiler, so that debug information is included in the resulting binary.) See below for examples of debug configurations that you can add to `.zed/debug.json`.
- [CodeLLDB configuration documentation](https://github.com/vadimcn/codelldb/blob/master/MANUAL.md#starting-a-new-debug-session)
- [GDB configuration documentation](https://sourceware.org/gdb/current/onlinedocs/gdb.html/Debugger-Adapter-Protocol.html)
### Build and Debug Binary
```json [debug]
[
{
"label": "Debug native binary",
"build": {
"command": "make",
"args": ["-j8"],
"cwd": "$ZED_WORKTREE_ROOT"
},
"program": "$ZED_WORKTREE_ROOT/build/prog",
"request": "launch",
"adapter": "CodeLLDB"
}
]
```
docs/src/languages/clojure.md
-10
View File
@@ -1,10 +0,0 @@
# Clojure
Clojure support is available through the [Clojure extension](https://github.com/zed-extensions/clojure).
- Tree-sitter: [prcastro/tree-sitter-clojure](https://github.com/prcastro/tree-sitter-clojure)
- Language Server: [clojure-lsp/clojure-lsp](https://github.com/clojure-lsp/clojure-lsp)
<!--
TBD: Add some Clojure Docs
-->
docs/src/languages/cpp.md
-160
View File
@@ -1,160 +0,0 @@
# C++
C++ support is available natively in Zed.
- Tree-sitter: [tree-sitter/tree-sitter-cpp](https://github.com/tree-sitter/tree-sitter-cpp)
- Language Server: [clangd/clangd](https://github.com/clangd/clangd)
## Binary
You can configure which `clangd` binary Zed should use.
By default, Zed will try to find a `clangd` in your `$PATH` and try to use that. If that binary successfully executes, it's used. Otherwise, Zed will fall back to installing its own `clangd` version and use that.
If you want to install a pre-release `clangd` version instead you can instruct Zed to do so by setting `pre_release` to `true` in your `settings.json`:
```json [settings]
{
"lsp": {
"clangd": {
"fetch": {
"pre_release": true
}
}
}
}
```
If you want to disable Zed looking for a `clangd` binary, you can set `ignore_system_version` to `true` in your `settings.json`:
```json [settings]
{
"lsp": {
"clangd": {
"binary": {
"ignore_system_version": true
}
}
}
}
```
If you want to use a binary in a custom location, you can specify a `path` and optional `arguments`:
```json [settings]
{
"lsp": {
"clangd": {
"binary": {
"path": "/path/to/clangd",
"arguments": []
}
}
}
}
```
This `"path"` has to be an absolute path.
## Arguments
You can pass any number of arguments to clangd. To see a full set of available options, run `clangd --help` from the command line. For example with `--function-arg-placeholders=0` completions contain only parentheses for function calls, while the default (`--function-arg-placeholders=1`) completions also contain placeholders for method parameters.
```json [settings]
{
"lsp": {
"clangd": {
"binary": {
"path": "/path/to/clangd",
"arguments": ["--function-arg-placeholders=0"]
}
}
}
}
```
## Formatting
By default Zed will use the `clangd` language server for formatting C++ code. The Clangd is the same as the `clang-format` CLI tool. To configure this you can add a `.clang-format` file. For example:
```yaml
# yaml-language-server: $schema=https://json.schemastore.org/clang-format-21.x.json
---
BasedOnStyle: LLVM
IndentWidth: 4
---
Language: Cpp
# Force pointers to the type for C++.
DerivePointerAlignment: false
PointerAlignment: Left
---
```
See [Clang-Format Style Options](https://clang.llvm.org/docs/ClangFormatStyleOptions.html) for a complete list of options.
You can trigger formatting via {#kb editor::Format} or the `editor: format` action from the command palette or by adding `format_on_save` to your Zed settings:
```json [settings]
"languages": {
"C++": {
"format_on_save": "on",
"tab_size": 2
}
}
```
## More server configuration
In the root of your project, it is generally common to create a `.clangd` file to set extra configuration.
```yaml
# yaml-language-server: $schema=https://json.schemastore.org/clangd.json
CompileFlags:
Add:
- "--include-directory=/path/to/include"
Diagnostics:
MissingIncludes: Strict
UnusedIncludes: Strict
```
For more advanced usage of clangd configuration file, take a look into their [official page](https://clangd.llvm.org/config.html).
## Compile Commands
For some projects Clangd requires a `compile_commands.json` file to properly analyze your project. This file contains the compilation database that tells clangd how your project should be built.
### CMake Compile Commands
With CMake, you can generate `compile_commands.json` automatically by adding the following line to your `CMakeLists.txt`:
```cmake
set(CMAKE_EXPORT_COMPILE_COMMANDS ON)
```
After building your project, CMake will generate the `compile_commands.json` file in the build directory and clangd will automatically pick it up.
## Debugging
You can use CodeLLDB or GDB to debug native binaries. (Make sure that your build process passes `-g` to the C++ compiler, so that debug information is included in the resulting binary.) See below for examples of debug configurations that you can add to `.zed/debug.json`.
- [CodeLLDB configuration documentation](https://github.com/vadimcn/codelldb/blob/master/MANUAL.md#starting-a-new-debug-session)
- [GDB configuration documentation](https://sourceware.org/gdb/current/onlinedocs/gdb.html/Debugger-Adapter-Protocol.html)
- GDB needs to be at least v14.1
### Build and Debug Binary
```json [debug]
[
{
"label": "Debug native binary",
"build": {
"command": "make",
"args": ["-j8"],
"cwd": "$ZED_WORKTREE_ROOT"
},
"program": "$ZED_WORKTREE_ROOT/build/prog",
"request": "launch",
"adapter": "CodeLLDB"
}
]
```
docs/src/languages/csharp.md
-25
View File
@@ -1,25 +0,0 @@
# C#
Note language name is "CSharp" for settings not "C#'
C# support is available through the [C# extension](https://github.com/zed-extensions/csharp).
- Tree-sitter: [tree-sitter/tree-sitter-c-sharp](https://github.com/tree-sitter/tree-sitter-c-sharp)
- Language Server: [OmniSharp/omnisharp-roslyn](https://github.com/OmniSharp/omnisharp-roslyn)
## Configuration
The `OmniSharp` binary can be configured in a Zed settings file with:
```json [settings]
{
"lsp": {
"omnisharp": {
"binary": {
"path": "/path/to/OmniSharp",
"arguments": ["optional", "additional", "args", "-lsp"]
}
}
}
}
```
docs/src/languages/css.md
-20
View File
@@ -1,20 +0,0 @@
# CSS
Zed has built-in support for CSS.
- Tree-sitter: [tree-sitter/tree-sitter-css](https://github.com/tree-sitter/tree-sitter-css)
- Language Servers:
- [microsoft/vscode-css-languageservice](https://github.com/microsoft/vscode-css-languageservice)
- [tailwindcss-language-server](https://github.com/tailwindlabs/tailwindcss-intellisense)
## Tailwind CSS
Zed also supports [Tailwind CSS](./tailwindcss.md) out-of-the-box for languages and frameworks like JavaScript, Astro, Svelte, and more.
<!-- TBD: Document CS -->
## Recommended Reading
- [HTML](./html.md)
- [TypeScript](./typescript.md)
- [JavaScript](./javascript.md)
docs/src/languages/dart.md
-54
View File
@@ -1,54 +0,0 @@
# Dart
Dart support is available through the [Dart extension](https://github.com/zed-extensions/dart).
- Tree-sitter: [UserNobody14/tree-sitter-dart](https://github.com/UserNobody14/tree-sitter-dart)
- Language Server: [dart language-server](https://github.com/dart-lang/sdk)
## Pre-requisites
You will need to install the Dart SDK.
You can install dart from [dart.dev/get-dart](https://dart.dev/get-dart) or via the [Flutter Version Management CLI (fvm)](https://fvm.app/documentation/getting-started/installation)
## Configuration
The dart extension requires no configuration if you have `dart` in your path:
```sh
which dart
dart --version
```
If you would like to use a specific dart binary or use dart via FVM you can specify the `dart` binary in your Zed settings.jsons file:
```json [settings]
{
"lsp": {
"dart": {
"binary": {
"path": "/opt/homebrew/bin/fvm",
"arguments": ["dart", "language-server", "--protocol=lsp"]
}
}
}
}
```
### Formatting
Dart by-default uses a very conservative maximum line length (80). If you would like the dart LSP to permit a longer line length when auto-formatting, add the following to your Zed settings.json:
```json [settings]
{
"lsp": {
"dart": {
"settings": {
"lineLength": 140
}
}
}
}
```
Please see the Dart documentation for more information on [dart language-server capabilities](https://github.com/dart-lang/sdk/blob/main/pkg/analysis_server/tool/lsp_spec/README.md).
docs/src/languages/deno.md
-127
View File
@@ -1,127 +0,0 @@
# Deno
Deno support is available through the [Deno extension](https://github.com/zed-extensions/deno).
- Language server: [Deno Language Server](https://docs.deno.com/runtime/manual/advanced/language_server/overview/)
## Deno Configuration
To use the Deno Language Server with TypeScript and TSX files, you will likely wish to disable the default language servers and enable deno by adding the following to your `settings.json`:
```json [settings]
{
"lsp": {
"deno": {
"settings": {
"deno": {
"enable": true
}
}
}
},
"languages": {
"JavaScript": {
"language_servers": [
"deno",
"!typescript-language-server",
"!vtsls",
"!eslint"
],
"formatter": "language_server"
},
"TypeScript": {
"language_servers": [
"deno",
"!typescript-language-server",
"!vtsls",
"!eslint"
],
"formatter": "language_server"
},
"TSX": {
"language_servers": [
"deno",
"!typescript-language-server",
"!vtsls",
"!eslint"
],
"formatter": "language_server"
}
}
}
```
See [Configuring supported languages](../configuring-languages.md) in the Zed documentation for more information.
<!--
TBD: Deno TypeScript REPL instructions [docs/repl#typescript-deno](../repl.md#typescript-deno)
-->
## Configuration completion
To get completions for `deno.json` or `package.json` you can add the following to your `settings.json`: (More info here https://zed.dev/docs/languages/json)
```json [settings]
"lsp": {
"json-language-server": {
"settings": {
"json": {
"schemas": [
{
"fileMatch": [
"deno.json",
"deno.jsonc"
],
"url": "https://raw.githubusercontent.com/denoland/deno/refs/heads/main/cli/schemas/config-file.v1.json"
},
{
"fileMatch": [
"package.json"
],
"url": "https://www.schemastore.org/package"
}
]
}
}
}
}
```
## DAP support
To debug deno programs, add this to `.zed/debug.json`
```json [debug]
[
{
"adapter": "JavaScript",
"label": "Deno",
"request": "launch",
"type": "pwa-node",
"cwd": "$ZED_WORKTREE_ROOT",
"program": "$ZED_FILE",
"runtimeExecutable": "deno",
"runtimeArgs": ["run", "--allow-all", "--inspect-wait"],
"attachSimplePort": 9229
}
]
```
## Runnable support
To run deno tasks like tests from the ui, add this to `.zed/tasks.json`
```json [tasks]
[
{
"label": "deno test",
"command": "deno test -A --filter '/^$ZED_CUSTOM_DENO_TEST_NAME$/' '$ZED_FILE'",
"tags": ["js-test"]
}
]
```
## See also:
- [TypeScript](./typescript.md)
- [JavaScript](./javascript.md)
docs/src/languages/diff.md
-17
View File
@@ -1,17 +0,0 @@
# Diff
Diff support is available natively in Zed.
- Tree-sitter: [zed-industries/the-mikedavis/tree-sitter-diff](https://github.com/the-mikedavis/tree-sitter-diff)
## Configuration
Zed will not attempt to format diff files and has [`remove_trailing_whitespace_on_save`](https://zed.dev/docs/configuring-zed#remove-trailing-whitespace-on-save) and [`ensure-final-newline-on-save`](https://zed.dev/docs/configuring-zed#ensure-final-newline-on-save) set to false.
Zed will automatically recognize files with `patch` and `diff` extensions as Diff files. To recognize other extensions, add them to `file_types` in your Zed settings.json:
```json [settings]
"file_types": {
"Diff": ["dif"]
},
```
docs/src/languages/docker.md
-16
View File
@@ -1,16 +0,0 @@
# Docker
Support for `Dockerfile` and `docker-compose.yaml` in Zed is provided by community-maintained extensions.
## Docker Compose
Docker `compose.yaml` language support in Zed is provided by the [Docker Compose extension](https://github.com/eth0net/zed-docker-compose). Please report issues to: [https://github.com/eth0net/zed-docker-compose/issues](https://github.com/eth0net/zed-docker-compose/issues).
- Language Server: [microsoft/compose-language-service](https://github.com/microsoft/compose-language-service)
## Dockerfile
`Dockerfile` language support in Zed is provided by the [Dockerfile extension](https://github.com/d1y/dockerfile.zed). Please report issues to: [https://github.com/d1y/dockerfile.zed/issues](https://github.com/d1y/dockerfile.zed/issues).
- Tree-sitter: [camdencheek/tree-sitter-dockerfile](https://github.com/camdencheek/tree-sitter-dockerfile)
- Language Server: [rcjsuen/dockerfile-language-server](https://github.com/rcjsuen/dockerfile-language-server)
docs/src/languages/elixir.md
-125
View File
@@ -1,125 +0,0 @@
# Elixir
Elixir support is available through the [Elixir extension](https://github.com/zed-extensions/elixir).
- Tree-sitter:
- [elixir-lang/tree-sitter-elixir](https://github.com/elixir-lang/tree-sitter-elixir)
- [phoenixframework/tree-sitter-heex](https://github.com/phoenixframework/tree-sitter-heex)
- Language servers:
- [elixir-lang/expert](https://github.com/elixir-lang/expert)
- [elixir-lsp/elixir-ls](https://github.com/elixir-lsp/elixir-ls)
- [elixir-tools/next-ls](https://github.com/elixir-tools/next-ls)
- [lexical-lsp/lexical](https://github.com/lexical-lsp/lexical)
## Choosing a language server
The Elixir extension offers language server support for `expert`, `elixir-ls`, `next-ls`, and `lexical`.
`elixir-ls` is enabled by default.
### Expert
To switch to `expert`, add the following to your `settings.json`:
```json [settings]
"languages": {
"Elixir": {
"language_servers": ["expert", "!elixir-ls", "!next-ls", "!lexical", "..."]
},
"HEEX": {
"language_servers": ["expert", "!elixir-ls", "!next-ls", "!lexical", "..."]
}
}
```
### Next LS
To switch to `next-ls`, add the following to your `settings.json`:
```json [settings]
"languages": {
"Elixir": {
"language_servers": ["next-ls", "!expert", "!elixir-ls", "!lexical", "..."]
},
"HEEX": {
"language_servers": ["next-ls", "!expert", "!elixir-ls", "!lexical", "..."]
}
}
```
### Lexical
To switch to `lexical`, add the following to your `settings.json`:
```json [settings]
"languages": {
"Elixir": {
"language_servers": ["lexical", "!expert", "!elixir-ls", "!next-ls", "..."]
},
"HEEX": {
"language_servers": ["lexical", "!expert", "!elixir-ls", "!next-ls", "..."]
}
}
```
## Setting up `elixir-ls`
1. Install `elixir`:
```sh
brew install elixir
```
2. Install `elixir-ls`:
```sh
brew install elixir-ls
```
3. Restart Zed
> If `elixir-ls` is not running in an elixir project, check the error log via the command palette action `zed: open log`. If you find an error message mentioning: `invalid LSP message header "Shall I install Hex? (if running non-interactively, use \"mix local.hex --force\") [Yn]`, you might need to install [`Hex`](https://hex.pm). You run `elixir-ls` from the command line and accept the prompt to install `Hex`.
### Formatting with Mix
If you prefer to format your code with [Mix](https://hexdocs.pm/mix/Mix.html), use the following snippet in your `settings.json` file to configure it as an external formatter. Formatting will occur on file save.
```json [settings]
{
"languages": {
"Elixir": {
"format_on_save": "on",
"formatter": {
"external": {
"command": "mix",
"arguments": ["format", "--stdin-filename", "{buffer_path}", "-"]
}
}
}
}
}
```
### Additional workspace configuration options
You can pass additional elixir-ls workspace configuration options via lsp settings in `settings.json`.
The following example disables dialyzer:
```json [settings]
"lsp": {
"elixir-ls": {
"settings": {
"dialyzerEnabled": false
}
}
}
```
See [ElixirLS configuration settings](https://github.com/elixir-lsp/elixir-ls#elixirls-configuration-settings) for more options.
### HEEx
Zed also supports HEEx templates. HEEx is a mix of [EEx](https://hexdocs.pm/eex/1.12.3/EEx.html) (Embedded Elixir) and HTML, and is used in Phoenix LiveView applications.
- Tree-sitter: [phoenixframework/tree-sitter-heex](https://github.com/phoenixframework/tree-sitter-heex)
docs/src/languages/elm.md
-40
View File
@@ -1,40 +0,0 @@
# Elm
Elm support is available through the [Elm extension](https://github.com/zed-extensions/elm).
- Tree-sitter: [elm-tooling/tree-sitter-elm](https://github.com/elm-tooling/tree-sitter-elm)
- Language Server: [elm-tooling/elm-language-server](https://github.com/elm-tooling/elm-language-server)
## Setup
Zed support for Elm requires installation of `elm`, `elm-format`, and `elm-review`.
1. [Install Elm](https://guide.elm-lang.org/install/elm.html) (or run `brew install elm` on macOS).
2. Install `elm-review` to support code linting:
```sh
npm install elm-review --save-dev
```
3. Install `elm-format` to support automatic formatting
```sh
npm install -g elm-format
```
## Configuring `elm-language-server`
Elm language server can be configured in your `settings.json`, e.g.:
```json [settings]
{
"lsp": {
"elm-language-server": {
"initialization_options": {
"disableElmLSDiagnostics": true,
"onlyUpdateDiagnosticsOnSave": false,
"elmReviewDiagnostics": "warning"
}
}
}
}
```
`elm-format`, `elm-review` and `elm` need to be installed and made available in the environment or configured in the settings. See the [full list of server settings here](https://github.com/elm-tooling/elm-language-server?tab=readme-ov-file#server-settings).
docs/src/languages/emmet.md
-11
View File
@@ -1,11 +0,0 @@
# Emmet
Emmet support is available through the [Emmet extension](https://github.com/zed-extensions/emmet).
[Emmet](https://emmet.io/) is a web-developer’s toolkit that can greatly improve your HTML & CSS workflow.
- Language Server: [olrtg/emmet-language-server](https://github.com/olrtg/emmet-language-server)
<!--
TBD: Document Emmet usage in zed with: HTML, PHP, ERB, Javascript, TSX, CSS
-->
docs/src/languages/erlang.md
-31
View File
@@ -1,31 +0,0 @@
# Erlang
Erlang support is available through the [Erlang extension](https://github.com/zed-extensions/erlang).
- Tree-sitter: [WhatsApp/tree-sitter-erlang](https://github.com/WhatsApp/tree-sitter-erlang)
- Language Servers:
- [erlang-ls/erlang_ls](https://github.com/erlang-ls/erlang_ls)
- [WhatsApp/erlang-language-platform](https://github.com/WhatsApp/erlang-language-platform)
## Choosing a language server
The Erlang extension offers language server support for `erlang_ls` and `erlang-language-platform`.
`erlang_ls` is enabled by default.
To switch to `erlang-language-platform`, add the following to your `settings.json`:
```json [settings]
{
"languages": {
"Erlang": {
"language_servers": ["elp", "!erlang-ls", "..."]
}
}
}
```
## See also:
- [Elixir](./elixir.md)
- [Gleam](./gleam.md)
docs/src/languages/fish.md
-31
View File
@@ -1,31 +0,0 @@
# Fish
Fish language support in Zed is provided by the community-maintained [Fish extension](https://github.com/hasit/zed-fish).
Report issues to: [https://github.com/hasit/zed-fish/issues](https://github.com/hasit/zed-fish/issues)
- Tree-sitter: [ram02z/tree-sitter-fish](https://github.com/ram02z/tree-sitter-fish)
### Formatting
Zed supports auto-formatting fish code using external tools like [`fish_indent`](https://fishshell.com/docs/current/cmds/fish_indent.html), which is included with fish.
1. Ensure `fish_indent` is available in your path and check the version:
```sh
which fish_indent
fish_indent --version
```
2. Configure Zed to automatically format fish code with `fish_indent`:
```json [settings]
"languages": {
"Fish": {
"formatter": {
"external": {
"command": "fish_indent"
}
}
}
},
```
docs/src/languages/gdscript.md
-26
View File
@@ -1,26 +0,0 @@
# GDScript
Godot [GDScript](https://gdscript.com/) language support in Zed is provided by the community-maintained [GDScript extension](https://github.com/GDQuest/zed-gdscript).
Report issues to: [https://github.com/GDQuest/zed-gdscript/issues](https://github.com/GDQuest/zed-gdscript/issues)
- Tree-sitter: [PrestonKnopp/tree-sitter-gdscript](https://github.com/PrestonKnopp/tree-sitter-gdscript) and [PrestonKnopp/tree-sitter-godot-resource](https://github.com/PrestonKnopp/tree-sitter-godot-resource)
- Language Server: [gdscript-language-server](https://github.com/godotengine/godot)
## Pre-requisites
You will need:
- [Godot](https://godotengine.org/download/).
- netcat (`nc` or `ncat`) on your system PATH.
## Setup
1. Inside your Godot editor, open Editor Settings, look for `Text Editor -> External` and set the following options:
- Exec Path: `/path/to/zed`
- Exec Flags: `{project} {file}:{line}:{col}`
- Use External Editor: "✅ On"
2. Open any \*.gd file through Godot and Zed will launch.
## Usage
When Godot is running, the GDScript extension will connect to the language server provided by the Godot runtime and will provide `jump to definition`, hover states when you hold Ctrl/cmd and other language server features.
docs/src/languages/gleam.md
-11
View File
@@ -1,11 +0,0 @@
# Gleam
Gleam support is available through the [Gleam extension](https://github.com/gleam-lang/zed-gleam). To learn about Gleam, see the [docs](https://gleam.run/documentation/) or check out the [`stdlib` reference](https://hexdocs.pm/gleam_stdlib/). The Gleam language server has a variety of features, including go-to definition, automatic imports, and [more](https://gleam.run/language-server/).
- Tree-sitter: [gleam-lang/tree-sitter-gleam](https://github.com/gleam-lang/tree-sitter-gleam)
- Language Server: [gleam lsp](https://github.com/gleam-lang/gleam/tree/main/compiler-core/src/language_server)
See also:
- [Elixir](./elixir.md)
- [Erlang](./erlang.md)
docs/src/languages/glsl.md
-6
View File
@@ -1,6 +0,0 @@
# GLSL
GLSL (OpenGL Shading Language) support is available through the [GLSL Extension](https://github.com/zed-industries/zed/tree/main/extensions/glsl/)
- Tree-sitter: [theHamsta/tree-sitter-glsl](https://github.com/theHamsta/tree-sitter-glsl)
- Language Server: [nolanderc/glsl_analyzer](https://github.com/nolanderc/glsl_analyzer)
docs/src/languages/go.md
-198
View File
@@ -1,198 +0,0 @@
# Go
Go support is available natively in Zed.
- Tree-sitter: [tree-sitter/tree-sitter-go](https://github.com/tree-sitter/tree-sitter-go)
- Language Server: [golang/tools/tree/master/gopls](https://github.com/golang/tools/tree/master/gopls)
- Debug Adapter: [delve](https://github.com/go-delve/delve)
## Setup
We recommend installing gopls via go's package manager and not via Homebrew or your Linux distribution's package manager.
1. Make sure you have uninstalled any version of gopls you have installed via your package manager:
```sh
# MacOS homebrew
brew remove gopls
# Ubuntu
sudo apt-get remove gopls
sudo snap remove gopls
# Arch
sudo pacman -R gopls
```
2. Install/Update `gopls` to the latest version using the go module tool:
```sh
go install golang.org/x/tools/gopls@latest
```
3. Ensure that `gopls` is in your path:
```sh
which gopls
gopls version
```
If `gopls` is not found you will likely need to add `export PATH="$PATH:$HOME/go/bin"` to your `.zshrc` / `.bash_profile`
## Inlay Hints
Zed sets the following initialization options for inlay hints:
```json [settings]
"hints": {
"assignVariableTypes": true,
"compositeLiteralFields": true,
"compositeLiteralTypes": true,
"constantValues": true,
"functionTypeParameters": true,
"parameterNames": true,
"rangeVariableTypes": true
}
```
to make the language server send back inlay hints when Zed has them enabled in the settings.
Use
```json [settings]
"lsp": {
"gopls": {
"initialization_options": {
"hints": {
// ....
}
}
}
}
```
to override these settings.
See [gopls inlayHints documentation](https://github.com/golang/tools/blob/master/gopls/doc/inlayHints.md) for more information.
## Debugging
Zed supports zero-configuration debugging of Go tests and entry points (`func main`) using Delve. Run {#action debugger::Start} ({#kb debugger::Start}) to see a contextual list of these preconfigured debug tasks.
For more control, you can add debug configurations to `.zed/debug.json`. See below for examples.
- [Delve configuration documentation](https://github.com/go-delve/delve/blob/master/Documentation/api/dap/README.md#launch-and-attach-configurations)
### Debug Go Packages
To debug a specific package, you can do so by setting the Delve mode to "debug". In this case "program" should be set to the package name.
```json [debug]
[
{
"label": "Go (Delve)",
"adapter": "Delve",
"program": "$ZED_FILE",
"request": "launch",
"mode": "debug"
},
{
"label": "Run server",
"adapter": "Delve",
"request": "launch",
"mode": "debug",
// For Delve, the program can be a package name
"program": "./cmd/server"
// "args": [],
// "buildFlags": [],
}
]
```
### Debug Go Tests
To debug the tests for a package, set the Delve mode to "test".
The "program" is still the package name, and you can use the "buildFlags" to do things like set tags, and the "args" to set args on the test binary. (See `go help testflags` for more information on doing that).
```json [debug]
[
{
"label": "Run integration tests",
"adapter": "Delve",
"request": "launch",
"mode": "test",
"program": ".",
"buildFlags": ["-tags", "integration"]
// To filter down to just the test your cursor is in:
// "args": ["-test.run", "$ZED_SYMBOL"]
}
]
```
### Build and debug separately
If you need to build your application with a specific command, you can use the "exec" mode of Delve. In this case "program" should point to an executable,
and the "build" command should build that.
```json [debug]
[
{
"label": "Debug Prebuilt Unit Tests",
"adapter": "Delve",
"request": "launch",
"mode": "exec",
"program": "${ZED_WORKTREE_ROOT}/__debug_unit",
"args": ["-test.v", "-test.run=${ZED_SYMBOL}"],
"build": {
"command": "go",
"args": [
"test",
"-c",
"-tags",
"unit",
"-gcflags\"all=-N -l\"",
"-o",
"__debug_unit",
"./pkg/..."
]
}
}
]
```
### Attaching to an existing instance of Delve
You might find yourself needing to connect to an existing instance of Delve that's not necessarily running on your machine; in such case, you can use `tcp_arguments` to instrument Zed's connection to Delve.
```json [debug]
[
{
"adapter": "Delve",
"label": "Connect to a running Delve instance",
"program": "/Users/zed/Projects/language_repositories/golang/hello/hello",
"cwd": "/Users/zed/Projects/language_repositories/golang/hello",
"args": [],
"env": {},
"request": "launch",
"mode": "exec",
"stopOnEntry": false,
"tcp_connection": { "host": "127.0.0.1", "port": 53412 }
}
]
```
In such case Zed won't spawn a new instance of Delve, as it opts to use an existing one. The consequence of this is that _there will be no terminal_ in Zed; you have to interact with the Delve instance directly, as it handles stdin/stdout of the debuggee.
## Go Mod
- Tree-sitter: [camdencheek/tree-sitter-go-mod](https://github.com/camdencheek/tree-sitter-go-mod)
- Language Server: N/A
## Go Sum
- Tree-sitter: [amaanq/tree-sitter-go-sum](https://github.com/amaanq/tree-sitter-go-sum)
- Language Server: N/A
## Go Work
- Tree-sitter:
[tree-sitter-go-work](https://github.com/d1y/tree-sitter-go-work)
- Language Server: N/A
docs/src/languages/groovy.md
-7
View File
@@ -1,7 +0,0 @@
# Groovy
Groovy language support in Zed is provided by the community-maintained [Groovy extension](https://github.com/valentinegb/zed-groovy).
Report issues to: [https://github.com/valentinegb/zed-groovy/issues](https://github.com/valentinegb/zed-groovy/issues)
- Tree-sitter: [murtaza64/tree-sitter-groovy](https://github.com/murtaza64/tree-sitter-groovy)
- Language Server: [GroovyLanguageServer/groovy-language-server](https://github.com/GroovyLanguageServer/groovy-language-server)
docs/src/languages/haskell.md
-51
View File
@@ -1,51 +0,0 @@
# Haskell
Haskell support is available through the [Haskell extension](https://github.com/zed-extensions/haskell).
- Tree-sitter: [tree-sitter-haskell](https://github.com/tree-sitter/tree-sitter-haskell)
- Language Server: [haskell-language-server](https://github.com/haskell/haskell-language-server)
## Installing HLS
Recommended method to [install haskell-language-server](https://haskell-language-server.readthedocs.io/en/latest/installation.html) (HLS) is via [ghcup](https://www.haskell.org/ghcup/install/) (`curl --proto '=https' --tlsv1.2 -sSf https://get-ghcup.haskell.org | sh
`):
```sh
ghcup install hls
which haskell-language-server-wrapper
```
## Configuring HLS
If you need to configure haskell-language-server (hls) you can add configuration options to your Zed settings.json:
```json [settings]
{
"lsp": {
"hls": {
"initialization_options": {
"haskell": {
"formattingProvider": "fourmolu"
}
}
}
}
}
```
See the official [configuring haskell-language-server](https://haskell-language-server.readthedocs.io/en/latest/configuration.html) docs for more options.
If you would like to use a specific hls binary, or perhaps use [static-ls](https://github.com/josephsumabat/static-ls) as a drop-in replacement instead, you can specify the binary path and arguments:
```json [settings]
{
"lsp": {
"hls": {
"binary": {
"path": "static-ls",
"arguments": ["--experimentalFeatures"]
}
}
}
}
```
docs/src/languages/helm.md
-25
View File
@@ -1,25 +0,0 @@
# Helm
Support for Helm in Zed is provided by the community-maintained [Helm extension](https://github.com/cabrinha/helm.zed).
- Tree-sitter: [tree-sitter-go-template](https://github.com/ngalaiko/tree-sitter-go-template/tree/master)
- Language Server: [mrjosh/helm-ls](https://github.com/mrjosh/helm-ls)
## Setup
Enable Helm language for Helm files by editing your `.zed/settings.json` and adding:
```json [settings]
"file_types": {
"Helm": [
"**/templates/**/*.tpl",
"**/templates/**/*.yaml",
"**/templates/**/*.yml",
"**/helmfile.d/**/*.yaml",
"**/helmfile.d/**/*.yml",
"**/values*.yaml"
]
}
```
This will also mark values.yaml files as the type helm, since helm-ls supports this.
docs/src/languages/html.md
-71
View File
@@ -1,71 +0,0 @@
# HTML
HTML support is available through the [HTML extension](https://github.com/zed-industries/zed/tree/main/extensions/html).
- Tree-sitter: [tree-sitter/tree-sitter-html](https://github.com/tree-sitter/tree-sitter-html)
- Language Server: [microsoft/vscode-html-languageservice](https://github.com/microsoft/vscode-html-languageservice)
This extension is automatically installed, but if you do not want to use it, you can add the following to your settings:
```json [settings]
{
"auto_install_extensions": {
"html": false
}
}
```
## Formatting
By default Zed uses [Prettier](https://prettier.io/) for formatting HTML.
You can disable `format_on_save` by adding the following to your Zed `settings.json`:
```json [settings]
"languages": {
"HTML": {
"format_on_save": "off",
}
}
```
You can still trigger formatting manually with {#kb editor::Format} or by opening [the Command Palette](..//getting-started.md#command-palette) ({#kb command_palette::Toggle}) and selecting "Format Document".
### LSP Formatting
To use the `vscode-html-language-server` language server auto-formatting instead of Prettier, add the following to your Zed settings:
```json [settings]
"languages": {
"HTML": {
"formatter": "language_server",
}
}
```
You can customize various [formatting options](https://code.visualstudio.com/docs/languages/html#_formatting) for `vscode-html-language-server` via your Zed `settings.json`:
```json [settings]
"lsp": {
"vscode-html-language-server": {
"settings": {
"html": {
"format": {
// Indent under <html> and <head> (default: false)
"indentInnerHtml": true,
// Disable formatting inside <svg> or <script>
"contentUnformatted": "svg,script",
// Add an extra newline before <div> and <p>
"extraLiners": "div,p"
}
}
}
}
}
```
## See also
- [CSS](./css.md)
- [JavaScript](./javascript.md)
- [TypeScript](./typescript.md)
docs/src/languages/java.md
-167
View File
@@ -1,167 +0,0 @@
# Java
Java language support in Zed is provided by:
- Zed Java: [zed-extensions/java](https://github.com/zed-extensions/java)
- Tree-sitter: [tree-sitter/tree-sitter-java](https://github.com/tree-sitter/tree-sitter-java)
- Language Server: [eclipse-jdtls/eclipse.jdt.ls](https://github.com/eclipse-jdtls/eclipse.jdt.ls)
## Install OpenJDK
You will need to install a Java runtime (OpenJDK).
- macOS: `brew install openjdk`
- Ubuntu: `sudo add-apt-repository ppa:openjdk-23 && sudo apt-get install openjdk-23`
- Windows: `choco install openjdk`
- Arch Linux: `sudo pacman -S jre-openjdk-headless`
Or manually download and install [OpenJDK 23](https://jdk.java.net/23/).
## Extension Install
You can install by opening {#action zed::Extensions}({#kb zed::Extensions}) and searching for `java`.
## Quick start and configuration
For the majority of users, Java support should work out of the box.
- It is generally recommended to open projects with the Zed-project root at the Java project root folder (where you would commonly have your `pom.xml` or `build.gradle` file).
- By default the extension will download and run the latest official version of JDTLS for you, but this requires Java version 21 to be available on your system via either the `$JAVA_HOME` environment variable or as a `java(.exe)` executable on your `$PATH`. If your project requires a lower Java version in the environment, you can specify a different JDK to use for running JDTLS via the `java_home` configuration option.
- You can provide a **custom launch script for JDTLS**, by adding an executable named `jdtls` (or `jdtls.bat` on Windows) to your `$PATH` environment variable. If this is present, the extension will skip downloading and launching a managed instance and use the one from the environment.
- To support [Lombok](https://projectlombok.org/), the lombok-jar must be downloaded and registered as a Java-Agent when launching JDTLS. By default the extension automatically takes care of that, but in case you don't want that you can set the `lombok_support` configuration-option to `false`.
Here is a common `settings.json` including the above mentioned configurations:
```jsonc
{
"lsp": {
"jdtls": {
"settings": {
"java_home": "/path/to/your/JDK21+",
"lombok_support": true,
},
},
},
}
```
## Debugging
Debug support is enabled via our [Fork of Java Debug](https://github.com/zed-industries/java-debug), which the extension will automatically download and start for you. Please refer to the [Debugger Documentation](https://zed.dev/docs/debugger#getting-started) for general information about how debugging works in Zed.
To get started with Java, click the `edit debug.json` button in the Debug menu, and replace the contents of the file with the following:
```jsonc
[
{
"adapter": "Java",
"request": "launch",
"label": "Launch Debugger",
// if your project has multiple entry points, specify the one to use:
// "mainClass": "com.myorganization.myproject.MyMainClass",
//
// this effectively sets a breakpoint at your program entry:
"stopOnEntry": true,
// the working directory for the debug process
"cwd": "$ZED_WORKTREE_ROOT",
},
]
```
You should then be able to start a new Debug Session with the "Launch Debugger" scenario from the debug menu.
## Launch Scripts (aka Tasks) in Windows
This extension provides tasks for running your application and tests from within Zed via little play buttons next to tests/entry points. However, due to current limitations of Zed's extension interface, we can not provide scripts that will work across Maven and Gradle on both Windows and Unix-compatible systems, so out of the box the launch scripts only work on Mac and Linux.
There is a fairly straightforward fix that you can apply to make it work on Windows by supplying your own task scripts. Please see [this Issue](https://github.com/zed-extensions/java/issues/94) for information on how to do that and read the [Tasks section in Zeds documentation](https://zed.dev/docs/tasks) for more information.
## Advanced Configuration/JDTLS initialization Options
JDTLS provides many configuration options that can be passed via the `initialize` LSP-request. The extension will pass the JSON-object from `lsp.jdtls.settings.initialization_options` in your settings on to JDTLS. Please refer to the [JDTLS Configuration Wiki Page](https://github.com/eclipse-jdtls/eclipse.jdt.ls/wiki/Running-the-JAVA-LS-server-from-the-command-line#initialize-request) for the available options and values. Below is an example `settings.json` that would pass on the example configuration from the above wiki page to JDTLS:
```jsonc
{
"lsp": {
"jdtls": {
"settings": {
// this will be sent to JDTLS as initializationOptions:
"initialization_options": {
"bundles": [],
// use this if your zed project root folder is not the same as the java project root:
"workspaceFolders": ["file:///home/snjeza/Project"],
"settings": {
"java": {
"home": "/usr/local/jdk-9.0.1",
"errors": {
"incompleteClasspath": {
"severity": "warning",
},
},
"configuration": {
"updateBuildConfiguration": "interactive",
"maven": {
"userSettings": null,
},
},
"import": {
"gradle": {
"enabled": true,
},
"maven": {
"enabled": true,
},
"exclusions": [
"**/node_modules/**",
"**/.metadata/**",
"**/archetype-resources/**",
"**/META-INF/maven/**",
"/**/test/**",
],
},
"referencesCodeLens": {
"enabled": false,
},
"signatureHelp": {
"enabled": false,
},
"implementationCodeLens": "all",
"format": {
"enabled": true,
},
"saveActions": {
"organizeImports": false,
},
"contentProvider": {
"preferred": null,
},
"autobuild": {
"enabled": false,
},
"completion": {
"favoriteStaticMembers": [
"org.junit.Assert.*",
"org.junit.Assume.*",
"org.junit.jupiter.api.Assertions.*",
"org.junit.jupiter.api.Assumptions.*",
"org.junit.jupiter.api.DynamicContainer.*",
"org.junit.jupiter.api.DynamicTest.*",
],
"importOrder": ["java", "javax", "com", "org"],
},
},
},
},
},
},
},
}
```
## See also
[Zed Java Repo](https://github.com/zed-extensions/java)
[Eclipse JDTLS Repo](https://github.com/eclipse-jdtls/eclipse.jdt.ls)
docs/src/languages/javascript.md
-237
View File
@@ -1,237 +0,0 @@
# JavaScript
JavaScript support is available natively in Zed.
- Tree-sitter: [tree-sitter/tree-sitter-javascript](https://github.com/tree-sitter/tree-sitter-javascript)
- Language Server: [yioneko/vtsls](https://github.com/yioneko/vtsls)
- Alternate Language Server: [typescript-language-server/typescript-language-server](https://github.com/typescript-language-server/typescript-language-server)
- Debug Adapter: [vscode-js-debug](https://github.com/microsoft/vscode-js-debug)
## Code formatting
Formatting on save is enabled by default for JavaScript, using TypeScript's built-in code formatting.
But many JavaScript projects use other command-line code-formatting tools, such as [Prettier](https://prettier.io/).
You can use one of these tools by specifying an _external_ code formatter for JavaScript in your settings.
See [the configuration docs](../configuring-zed.md) for more information.
For example, if you have Prettier installed and on your `PATH`, you can use it to format JavaScript files by adding the following to your `settings.json`:
```json [settings]
{
"languages": {
"JavaScript": {
"formatter": {
"external": {
"command": "prettier",
"arguments": ["--stdin-filepath", "{buffer_path}"]
}
}
}
}
}
```
## JSX
Zed supports JSX syntax highlighting out of the box.
In JSX strings, the [`tailwindcss-language-server`](./tailwindcss.md) is used to provide autocompletion for Tailwind CSS classes.
## JSDoc
Zed supports JSDoc syntax in JavaScript and TypeScript comments that match the JSDoc syntax.
Zed uses [tree-sitter/tree-sitter-jsdoc](https://github.com/tree-sitter/tree-sitter-jsdoc) for parsing and highlighting JSDoc.
## ESLint
You can configure Zed to format code using `eslint --fix` by running the ESLint code action when formatting:
```json [settings]
{
"languages": {
"JavaScript": {
"code_actions_on_format": {
"source.fixAll.eslint": true
}
}
}
}
```
You can also only execute a single ESLint rule when using `fixAll`:
```json [settings]
{
"languages": {
"JavaScript": {
"code_actions_on_format": {
"source.fixAll.eslint": true
}
}
},
"lsp": {
"eslint": {
"settings": {
"codeActionOnSave": {
"rules": ["import/order"]
}
}
}
}
}
```
> **Note:** the other formatter you have configured will still run, after ESLint.
> So if your language server or Prettier configuration don't format according to
> ESLint's rules, then they will overwrite what ESLint fixed and you end up with
> errors.
If you **only** want to run ESLint on save, you can configure code actions as
the formatter:
```json [settings]
{
"languages": {
"JavaScript": {
"formatter": [],
"code_actions_on_format": {
"source.fixAll.eslint": true
}
}
}
}
```
### Configure ESLint's `nodePath`:
You can configure ESLint's `nodePath` setting:
```json [settings]
{
"lsp": {
"eslint": {
"settings": {
"nodePath": ".yarn/sdks"
}
}
}
}
```
### Configure ESLint's `problems`:
You can configure ESLint's `problems` setting.
For example, here's how to set `problems.shortenToSingleLine`:
```json [settings]
{
"lsp": {
"eslint": {
"settings": {
"problems": {
"shortenToSingleLine": true
}
}
}
}
}
```
### Configure ESLint's `rulesCustomizations`:
You can configure ESLint's `rulesCustomizations` setting:
```json [settings]
{
"lsp": {
"eslint": {
"settings": {
"rulesCustomizations": [
// set all eslint errors/warnings to show as warnings
{ "rule": "*", "severity": "warn" }
]
}
}
}
}
```
### Configure ESLint's `workingDirectory`:
You can configure ESLint's `workingDirectory` setting:
```json [settings]
{
"lsp": {
"eslint": {
"settings": {
"workingDirectory": {
"mode": "auto"
}
}
}
}
}
```
## Debugging
Zed supports debugging JavaScript code out of the box with `vscode-js-debug`.
The following can be debugged without writing additional configuration:
- Tasks from `package.json`
- Tests written using several popular frameworks (Jest, Mocha, Vitest, Jasmine, Bun, Node)
Run {#action debugger::Start} ({#kb debugger::Start}) to see a contextual list of these predefined debug tasks.
> **Note:** Bun test is automatically detected when `@types/bun` is present in `package.json`.
>
> **Note:** Node test is automatically detected when `@types/node` is present in `package.json` (requires Node.js 20+).
As for all languages, configurations from `.vscode/launch.json` are also available for debugging in Zed.
If your use-case isn't covered by any of these, you can take full control by adding debug configurations to `.zed/debug.json`. See below for example configurations.
### Configuring JavaScript debug tasks
JavaScript debugging is more complicated than other languages because there are two different environments: Node.js and the browser. `vscode-js-debug` exposes a `type` field, that you can use to specify the environment, either `node` or `chrome`.
- [vscode-js-debug configuration documentation](https://github.com/microsoft/vscode-js-debug/blob/main/OPTIONS.md)
### Debug the current file with Node
```json [debug]
[
{
"adapter": "JavaScript",
"label": "Debug JS file",
"type": "node",
"request": "launch",
"program": "$ZED_FILE",
"skipFiles": ["<node_internals>/**"]
}
]
```
### Launch a web app in Chrome
```json [debug]
[
{
"adapter": "JavaScript",
"label": "Debug app in Chrome",
"type": "chrome",
"request": "launch",
"file": "$ZED_WORKTREE_ROOT/index.html",
"webRoot": "$ZED_WORKTREE_ROOT",
"console": "integratedTerminal",
"skipFiles": ["<node_internals>/**"]
}
]
```
## See also
- [Yarn documentation](./yarn.md) for a walkthrough of configuring your project to use Yarn.
- [TypeScript documentation](./typescript.md)
docs/src/languages/json.md
-77
View File
@@ -1,77 +0,0 @@
# JSON
JSON support is available natively in Zed.
- Tree-sitter: [tree-sitter/tree-sitter-json](https://github.com/tree-sitter/tree-sitter-json)
- Language Server: [zed-industries/json-language-server](https://github.com/zed-industries/json-language-server)
## JSONC
Zed also supports a super-set of JSON called JSONC, which allows single line comments (`//`) in JSON files.
While editing these files you can use `cmd-/` (macOS) or `ctrl-/` (Linux) to toggle comments on the current line or selection.
## JSONC Prettier Formatting
If you use files with the `*.jsonc` extension when using `Format Document` or have `format_on_save` enabled, Zed invokes Prettier as the formatter. Prettier has an [outstanding issue](https://github.com/prettier/prettier/issues/15956) where it will add trailing commas to files with a `jsonc` extension. JSONC files which have a `.json` extension are unaffected.
To workaround this behavior you can add the following to your `.prettierrc` configuration file:
```json [settings]
{
"overrides": [
{
"files": ["*.jsonc"],
"options": {
"parser": "json",
"trailingComma": "none"
}
}
]
}
```
## JSON Language Server
Zed automatically out of the box supports JSON Schema validation of `package.json` and `tsconfig.json` files, but `json-language-server` can use JSON Schema definitions in project files, from the [JSON Schema Store](https://www.schemastore.org) or other publicly available URLs for JSON validation.
### Inline Schema Specification
To specify a schema inline with your JSON files, add a `$schema` top level key linking to your json schema file.
For example to for a `.luarc.json` for use with [lua-language-server](https://github.com/LuaLS/lua-language-server/):
```json [settings]
{
"$schema": "https://raw.githubusercontent.com/sumneko/vscode-lua/master/setting/schema.json",
"runtime.version": "Lua 5.4"
}
```
### Schema Specification via Settings
You can alternatively associate JSON Schemas with file paths by via Zed LSP settings.
To
```json [settings]
"lsp": {
"json-language-server": {
"settings": {
"json": {
"schemas": [
{
"fileMatch": ["*/*.luarc.json"],
"url": "https://raw.githubusercontent.com/sumneko/vscode-lua/master/setting/schema.json"
}
]
}
}
}
}
```
You can also pass any of the [supported settings](https://github.com/Microsoft/vscode/blob/main/extensions/json-language-features/server/README.md#settings) to json-language-server by specifying them in your Zed settings.json:
<!--
TBD: Add formatter (prettier) settings (autoformat, tab_size, etc)
-->
docs/src/languages/jsonnet.md
-24
View File
@@ -1,24 +0,0 @@
# Jsonnet
Jsonnet language support in Zed is provided by the community-maintained [Jsonnet extension](https://github.com/narqo/zed-jsonnet).
- Tree-sitter: [sourcegraph/tree-sitter-jsonnet](https://github.com/sourcegraph/tree-sitter-jsonnet)
- Language Server: [grafana/jsonnet-language-server](https://github.com/grafana/jsonnet-language-server)
## Configuration
Workspace configuration options can be passed to the language server via the `lsp` settings of the `settings.json`.
The following example enables support for resolving [tanka](https://tanka.dev) import paths in `jsonnet-language-server`:
```json [settings]
{
"lsp": {
"jsonnet-language-server": {
"settings": {
"resolve_paths_with_tanka": true
}
}
}
}
```
docs/src/languages/julia.md
-12
View File
@@ -1,12 +0,0 @@
# Julia
Julia language support in Zed is provided by the community-maintained [Julia extension](https://github.com/JuliaEditorSupport/zed-julia).
Report issues to: [https://github.com/JuliaEditorSupport/zed-julia/issues](https://github.com/JuliaEditorSupport/zed-julia/issues)
- Tree-sitter: [tree-sitter/tree-sitter-julia](https://github.com/tree-sitter/tree-sitter-julia)
- Language Server: [julia-vscode/LanguageServer.jl](https://github.com/julia-vscode/LanguageServer.jl)
<!--
TBD: Document Julia Installation
TBD: Julia REPL Setup instructions
-->
docs/src/languages/kotlin.md
-55
View File
@@ -1,55 +0,0 @@
# Kotlin
Kotlin language support in Zed is provided by the community-maintained [Kotlin extension](https://github.com/zed-extensions/kotlin).
Report issues to: [https://github.com/zed-extensions/kotlin/issues](https://github.com/zed-extensions/kotlin/issues)
- Tree-sitter: [fwcd/tree-sitter-kotlin](https://github.com/fwcd/tree-sitter-kotlin)
- Language Server: [fwcd/kotlin-language-server](https://github.com/fwcd/kotlin-language-server)
## Configuration
Workspace configuration options can be passed to the language server via lsp
settings in `settings.json`.
The full list of lsp `settings` can be found
[here](https://github.com/fwcd/kotlin-language-server/blob/main/server/src/main/kotlin/org/javacs/kt/Configuration.kt)
under `class Configuration` and initialization_options under `class InitializationOptions`.
### JVM Target
The following example changes the JVM target from `default` (which is 1.8) to
`17`:
```json [settings]
{
"lsp": {
"kotlin-language-server": {
"settings": {
"compiler": {
"jvm": {
"target": "17"
}
}
}
}
}
}
```
### JAVA_HOME
To use a specific java installation, just specify the `JAVA_HOME` environment variable with:
```json [settings]
{
"lsp": {
"kotlin-language-server": {
"binary": {
"env": {
"JAVA_HOME": "/Users/whatever/Applications/Work/Android Studio.app/Contents/jbr/Contents/Home"
}
}
}
}
}
```
docs/src/languages/lua.md
-181
View File
@@ -1,181 +0,0 @@
# Lua
Lua support is available through the [Lua extension](https://github.com/zed-extensions/lua).
- Tree-sitter: [tree-sitter-grammars/tree-sitter-lua](https://github.com/tree-sitter-grammars/tree-sitter-lua)
- Language server: [LuaLS/lua-language-server](https://github.com/LuaLS/lua-language-server)
## luarc.json
To configure LuaLS you can create a `.luarc.json` file in the root of your workspace.
```json [settings]
{
"$schema": "https://raw.githubusercontent.com/LuaLS/vscode-lua/master/setting/schema.json",
"runtime.version": "Lua 5.4",
"format.enable": true,
"workspace.library": ["../somedir/library"]
}
```
See [LuaLS Settings Documentation](https://luals.github.io/wiki/settings/) for all available configuration options, or when editing this file in Zed available settings options will autocomplete, (e.g `runtime.version` will show `"Lua 5.1"`, `"Lua 5.2"`, `"Lua 5.3"`, `"Lua 5.4"` and `"LuaJIT"` as allowed values). Note when importing settings options from VS Code, remove the `Lua.` prefix. (e.g. `runtime.version` instead of `Lua.runtime.version`).
### LuaCATS Definitions
LuaLS can provide enhanced LSP autocompletion suggestions and type validation with the help of LuaCATS (Lua Comment and Type System) definitions. These definitions are available for many common Lua libraries, and local paths containing them can be specified via `workspace.library` in `luarc.json`. You can do this via relative paths if you checkout your definitions into the same partent directory of your project (`../playdate-luacats`, `../love2d`, etc). Alternatively you can create submodule(s) inside your project for each LuaCATS definition repo.
### LÖVE (Love2D) {#love2d}
To use [LÖVE (Love2D)](https://love2d.org/) in Zed, checkout [LuaCATS/love2d](https://github.com/LuaCATS/love2d) into a folder called `love2d-luacats` into the parent folder of your project:
```sh
cd .. && git clone https://github.com/LuaCATS/love2d love2d-luacats
```
Then in your `.luarc.json`:
```
{
"$schema": "https://raw.githubusercontent.com/LuaLS/vscode-lua/master/setting/schema.json",
"runtime.version": "Lua 5.4",
"workspace.library": ["../love2d-luacats"],
"runtime.special": {
"love.filesystem.load": "loadfile"
}
}
```
### PlaydateSDK
To use [Playdate Lua SDK](https://play.date/dev/) in Zed, checkout [playdate-luacats](https://github.com/notpeter/playdate-luacats) into the parent folder of your project:
```sh
cd .. && git clone https://github.com/notpeter/playdate-luacats
```
Then in your `.luarc.json`:
```json [settings]
{
"$schema": "https://raw.githubusercontent.com/LuaLS/vscode-lua/master/setting/schema.json",
"runtime.version": "Lua 5.4",
"runtime.nonstandardSymbol": [
"+=",
"-=",
"*=",
"/=",
"//=",
"%=",
"<<=",
">>=",
"&=",
"|=",
"^="
],
"diagnostics.severity": { "duplicate-set-field": "Hint" },
"diagnostics.globals": ["import"],
"workspace.library": ["../playdate-luacats"],
"format.defaultConfig": {
"indent_style": "space",
"indent_size": "4"
},
"format.enable": true,
"runtime.builtin": { "io": "disable", "os": "disable", "package": "disable" }
}
```
### Inlay Hints
To enable [Inlay Hints](../configuring-languages.md#inlay-hints) for LuaLS in Zed
1. Add the following to your Zed settings.json:
```json [settings]
"languages": {
"Lua": {
"inlay_hints": {
"enabled": true,
"show_type_hints": true,
"show_parameter_hints": true,
"show_other_hints": true
}
}
}
```
2. Add `"hint.enable": true` to your `.luarc.json`.
## Formatting
### LuaLS Formatting
To enable auto-formatting with your LuaLS (provided by [CppCXY/EmmyLuaCodeStyle](https://github.com/CppCXY/EmmyLuaCodeStyle)) make sure you have `"format.enable": true,` in your .luarc.json:
```json [settings]
{
"$schema": "https://raw.githubusercontent.com/sumneko/vscode-lua/master/setting/schema.json",
"format.enable": true
}
```
Then add the following to your Zed `settings.json`:
```json [settings]
{
"languages": {
"Lua": {
"format_on_save": "on",
"formatter": "language_server"
}
}
}
```
You can customize various EmmyLuaCodeStyle style options via `.editorconfig`, see [lua.template.editorconfig](https://github.com/CppCXY/EmmyLuaCodeStyle/blob/master/lua.template.editorconfig) for all available options.
### StyLua Formatting
Alternatively to use [StyLua](https://github.com/JohnnyMorganz/StyLua) for auto-formatting:
1. Install [StyLua](https://github.com/JohnnyMorganz/StyLua): `brew install stylua` or `cargo install stylua --features lua52,lua53,lua54,luau,luajit` (feel free to remove any Lua versions you don't need).
2. Add the following to your `settings.json`:
```json [settings]
{
"languages": {
"Lua": {
"format_on_save": "on",
"formatter": {
"external": {
"command": "stylua",
"arguments": [
"--syntax=Lua54",
"--respect-ignores",
"--stdin-filepath",
"{buffer_path}",
"-"
]
}
}
}
}
}
```
You can specify various options to StyLua either on the command line above (like `--syntax=Lua54`) or in a `stylua.toml` in your workspace:
```toml
syntax = "Lua54"
column_width = 100
line_endings = "Unix"
indent_type = "Spaces"
indent_width = 4
quote_style = "AutoPreferDouble"
call_parentheses = "Always"
collapse_simple_statement = "All"
[sort_requires]
enabled = true
```
For a complete list of available options, see: [StyLua Options](https://github.com/JohnnyMorganz/StyLua?tab=readme-ov-file#options).

Some files were not shown because too many files have changed in this diff Show More