Closes#21822
## Context
Exposes `preferred_line_length` from `AllLanguageSettings` to the
Extension
API's `LanguageSettings` struct. Currently only `tab_size` is available
to
extensions, which prevents language extensions (e.g. Dart) from reading
the
user's preferred line length and forwarding it to their language server
(e.g. as `dart.lineLength`).
Related: https://github.com/zed-extensions/dart/issues/2
## How to Review
Small change — follow how `tab_size` is plumbed through:
1. WIT definition (`language-settings` record)
2. `extension_api` Rust struct
3. Host-side bridge conversion
The new field follows the exact same pattern.
## Self-Review Checklist
<!-- Check before requesting review: -->
- [x] I've reviewed my own diff for quality, security, and reliability
- [ ] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- Compile-time verified via WIT bindings; no runtime behavior change
- [x] Performance impact has been considered and is acceptable
Release Notes:
- N/A
(This should be merged after #48332)
This PR exposes the LSP settings schema functionality to extensions,
allowing them to provide JSON schema for `initialization_options` and
`settings` fields to enable autocomplete in settings files.
New extension API methods (v0.8.0+):
- `language_server_initialization_options_schema`
- `language_server_settings_schema`
Both methods return an optional JSON string conforming to JSON schema.
Older extension versions gracefully return `None`.
Release Notes:
- Added support for settings schemas for the next version of the
extension API so that settings autocompletion can be provided for
language server settings.
---------
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
Co-authored-by: MrSubidubi <finn@zed.dev>
Round 2 of #46269 with conflicts properly resolved.
This came up a few times across various extensions. With us about to
ship a new API version soon, it might be worth to add.
Release Notes:
- N/A
---------
Co-authored-by: Zed Zippy <234243425+zed-zippy[bot]@users.noreply.github.com>
Some language servers include local symbols (e.g., local variables,
parameters) in workspace symbol results. Without the `containerName`
information, these symbols lack context information, making it difficult
to distinguish them from top-level definitions and hindering efficient
symbol lookup.
This change exposes the `container_name` field from LSP
[`SymbolInformation`](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#symbolInformation)
to the extension API, allowing language server extensions to access
`symbol.container_name` in `label_for_symbol` and provide meaningful
context when rendering symbol labels.
Note: The `container_name `field is added to all extension API versions
because they seem to share the same underlying Rust types via wasmtime
bindgen. The field is optional, so existing extensions would remain
compatible as far as I understand.
Closes #ISSUE
Release Notes:
- Added `container_name` field to `lsp::Symbol`, accessible via the
extension API's `label_for_symbol` function
---------
Co-authored-by: MrSubidubi <finn@zed.dev>
Extension authors frequently guard this method in their extensions
although this is not necessary.
Thus, this PR updates the documentation of `make_file_executable` with a
brief mention to indicate that this is not needed.
Release Notes:
- N/A
Currently, extensions cannot have tests that call methods like
`label_for_symbol` and `label_for_completion`, because those methods
take a `LanguageServerId`, and that type is opaque, and cannot be
constructed outside of the `zed_extension_api` crate.
This PR makes it possible to construct those types from strings, so that
it's more straightforward to write unit tests for these LSP adapter
methods.
Release Notes:
- N/A
This PR forks a new version of the `zed_extension_api` in preparation
for new changes.
We're jumping from v0.6.0 to v0.8.0 for the WIT because we released
v0.7.0 of the `zed_extension_api` without any WIT changes (it probably
should have been v0.6.1, instead).
Release Notes:
- N/A
### Background
Zed extensions use WASI to access the file-system. They only have
read-write access to one specific folder called their work dir. But
extensions do need to be able to *refer* to other arbitrary files on the
user's machine. For instance, extensions need to be able to look up
existing binaries on the user's `PATH`, and request that Zed invoke them
as language servers. Similarly, extensions can create paths to files in
the user's project, and use them as arguments in commands that Zed
should run. For these reasons, we pass *real* paths back and forth
between the host and extensions; we don't try to abstract over the
file-system with some virtualization scheme.
On Windows, this results in a bit of mismatch, because `wasi-libc` uses
*unix-like* path conventions (and thus, so does the Rust standard
library when compiling to WASI).
### Change 1 - Fixing `current_dir`
In order to keep the extension API minimal, extensions use the standard
library function`env::current_dir()` to query the location of their
"work" directory. Previously, when initializing extensions, we used the
`env::set_current_dir` function to set their work directory, but on
Windows, where absolute paths typically begin with a drive letter, like
`C:`, the [`wasi-libc` implementation of
`chdir`](d1793637d8/libc-bottom-half/sources/chdir.c (L21))
was prepending an extra forward slash to the path, which caused
`current_dir()` to return an invalid path.
See https://github.com/bytecodealliance/wasmtime/issues/10415
In this PR, I've switched our extension initialization function to
*bypass* wasi-libc's `chdir` function, and instead write directly to
wasi-libc's private, internal state. This is a bit of a hack, but it
causes the `current_dir()` function to do what we want on Windows
without any changes to extensions' source code.
### Change 2 - Working around WASI's relative path handling
Once `current_dir` was fixed (giving us correct absolute paths on
Windows), @kubkon and I discovered that without the spurious leading `/`
character, windows absolute paths were no longer accepted by Rust's
`std::fs` APIs, because they were now recognized as relative paths, and
were being appended to the working directory.
We first tried to override the `__wasilibc_find_abspath` function in
`wasi-libc` to make it recognize windows absolute paths as being
absolute, but that functionality is difficult to override. Eventually
@kubkon realized that we could prevent WASI-libc's CWD handling from
being linked into the WASM file by overriding the `chdir` function.
wasi-libc is designed so that if you don't use their `chdir` function,
then all paths will be interpreted as relative to `/`. This makes
absolute paths behave correctly. Then, in order to make *relative* paths
work again, we simply add a preopen for `.`. Relative paths will match
that.
### Next Steps
This is a change to `zed-extension-api`, so we do need to update every
Zed extension to use the new version, in order for them to work on
windows.
Release Notes:
- N/A
---------
Co-authored-by: Jakub Konka <kubkon@jakubkonka.com>
We'll now clean up DAP locators for unloaded extensions and load schemas
proper
I can now load a custom Ruby extensions with all bells and whistles and
use it as my debugger.
Release Notes:
- N/A
- DAP schemas will be stored in `debug_adapters_schemas` subdirectory in
extension work dir.
- Added Debug Config integration and such.
Release Notes:
- N/A
This allows us to support debugging with a debug adapter not managed by
Zed. Note that this is not a user facing change, as DebugAdapterBinary
is used to determine how to spawn a debugger. Thus, this should not
break any configs or anything like that.
Closes #ISSUE
Release Notes:
- N/A
Cleans things up now that wasm32-wasip2 is a supported target.
Before we merge, I will need to test against the current extensions to
make sure this is fine.
However, since our wit world isn't using any wasi package imports, this
shouldn't be a breaking change.
Release Notes:
- N/A
This PR allows DAPs to define their own schema so users can see
completion items when editing their debug.json files.
Users facing this aren’t the biggest chance, but behind the scenes, this
affected a lot of code because we manually translated common fields from
Zed's config format to be adapter-specific. Now we store the raw JSON
from a user's configuration file and just send that.
I'm ignoring the Protobuf CICD error because the DebugTaskDefinition
message is not yet user facing and we need to deprecate some fields in
it.
Release Notes:
- debugger beta: Show completion items when editing debug.json
- debugger beta: Breaking change, debug.json schema now relays on what
DAP you have selected instead of always having the same based values.
---------
Co-authored-by: Remco Smits <djsmits12@gmail.com>
Co-authored-by: Cole Miller <m@cole-miller.net>
Co-authored-by: Cole Miller <cole@zed.dev>
Extensions cannot look up available port themselves, hence the new API.
With this I'm able to port our Ruby implementation into an extension.
Release Notes:
- N/A
This reverts commit 9ef0501853 due to a
panic.
```
{
"thread": "main",
"payload": "9 is not a valid char boundary in path \"crates/…/LiveKitBridge/\"",
"location_data": {
"file": "crates/file_finder/src/file_finder.rs",
"line": 646
}
}
```
Release Notes:
- N/A
This PR makes progress on #7711 by identifying any common prefix of the
paths in the file finder's search results, and replacing the "interior"
of that prefix---every path segment but the first and last---with `...`,
when a heuristic indicates that the longest path would otherwise
overflow the modal.
The elision is not applied to any segment that contains a match for the
search query.
There may be more work to do on #7711 in the case of long result paths
that do not share a significant common prefix.
Release Notes:
- Improved display of long paths in the file finder modal
Co-authored-by: Max <max@zed.dev>
This PR exposes context server settings to extensions.
Extensions can use `ContextServerSettings::for_project` to get the
context server settings for the current project.
The `experimental.context_servers` setting has been removed and replaced
with the `context_servers` setting (which is now an object instead of an
array).
Release Notes:
- N/A
---------
Co-authored-by: Max Brunsfeld <maxbrunsfeld@gmail.com>
This PR adds support for context servers provided by extensions.
To provide a context server from an extension, you need to list the
context servers in your `extension.toml`:
```toml
[context_servers.my-context-server]
```
And then implement the `context_server_command` method to return the
command that will be used to start the context server:
```rs
use zed_extension_api::{self as zed, Command, ContextServerId, Result};
struct ExampleContextServerExtension;
impl zed::Extension for ExampleContextServerExtension {
fn new() -> Self {
ExampleContextServerExtension
}
fn context_server_command(&mut self, _context_server_id: &ContextServerId) -> Result<Command> {
Ok(Command {
command: "node".to_string(),
args: vec!["/path/to/example-context-server/index.js".to_string()],
env: Vec::new(),
})
}
}
zed::register_extension!(ExampleContextServerExtension);
```
Release Notes:
- N/A
This PR makes `zed_extension_api` use the WIT types from v0.2.0 of
extension API.
A follow-up from #17795, since I had forgotten to do it there.
Release Notes:
- N/A
This PR forks a new version of the `zed_extension_api` in preparation
for new changes.
Release Notes:
- N/A
---------
Co-authored-by: Max <max@zed.dev>
