This PR reverts the addition of extension capabilities from #16953.
While these may end up being useful at some point, after some discussion
they don't seem like the exact fit for what we're looking to do right
now.
This reverts commit 8ec36f1e2b.
Release Notes:
- N/A
This PR adds an initial notion of extension capabilities.
Capabilities are used to express the operations an extension is capable
of doing. This will provide further insights into what an extension can
do, as well as provide the ability to grant or deny the set of
capabilities.
Capabilities are defined in the `capabilities` field in the extension
manifest. This field contains an array of capabilities.
Each capability has a `kind` to denote the known capability it
corresponds to. Individual capabilities may have additional fields,
based on the `kind`.
Here's an example of some capabilities:
```toml
capabilities = [
{ kind = "download-file", host = "github.com", path_prefix = "owner/repo" },
{ kind = "npm:install", package = "@vue/language-server" },
]
```
In order to avoid a breaking change, the `capabilities` field is
currently optional and defaults to an empty array. This will allow us to
add support for extensions to define capabilities before we start
enforcing them.
Release Notes:
- N/A
This PR removes the `tooltip_text` from the extension manifests.
We stopped reading this value in #16306, as it wasn't being used, so we
don't need to include it in the manifest anymore.
Release Notes:
- N/A
This PR cleans up the slash command functionality in preparation for an
upcoming release:
- Removed arguments to `/gleam-project` that were just used as an
example
- Removed `/gleam-docs` in favor of `/docs` with the `gleam-hexdocs`
provider
- Pulled a list of all Gleam packages to use as suggestions
Release Notes:
- N/A
* renames `/tabs` to `/tab`
* allows to insert multiple tabs when fuzzy matching by the names
* improve slash command completion API, introduce a notion of multiple
arguments
* properly fire off commands on arguments' completions with
`run_command: true`
Release Notes:
- N/A
---------
Co-authored-by: Marshall Bowers <marshall@zed.dev>
This PR adds an `HttpRequestBuilder` to the extension API to allow for a
more ergonomic way for constructing HTTP requests within extensions.
The HTTP client functionality is now also exposed via the
`zed_extension_api::http_client` module instead of top-level.
Release Notes:
- N/A
# HTTP Client Improvements for Extension API
This PR enhances the HTTP client functionality in the Zed extension API,
providing more control over requests and allowing for streaming
responses.
## Key Changes
1. Extended `HttpRequest` struct:
- Added `method` field to specify HTTP method
- Added `headers` field for custom headers
- Added optional `body` field for request payload
2. Introduced `HttpMethod` enum for supported HTTP methods
3. Updated `HttpResponse` struct:
- Added `headers` field to access response headers
- Changed `body` type from `String` to `Vec<u8>` for binary data support
4. Added streaming support:
- New `fetch_stream` function to get a response stream
- Introduced `HttpResponseStream` resource for chunked reading
5. Updated internal implementations to support these new features
6. Modified the Gleam extension to use the new API structure
## Motivation
These changes provide extension developers with more flexibility and
control over HTTP requests. The streaming support is particularly useful
for handling large responses efficiently or ideally streaming into the
UI.
## Testing
- [x] Updated existing tests
- [ ] Added new tests for streaming functionality
## Next Steps
- Consider adding more comprehensive examples in the documentation
- Evaluate performance impact of streaming for large responses
Please review and let me know if any adjustments are needed.
Release Notes:
- N/A
---------
Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>
This PR updates the extension API to make the `worktree` argument to
`run_slash_command` optional.
We may not always have a worktree, and not all slash commands need them,
so by making it optional we can allow individual slash commands to
decide what to do when there is no worktree.
Release Notes:
- N/A
This PR updates the extension API to use structured slash command
completions instead of plain strings.
This allows slash commands defined in extensions to take advantage of
the improvements made in #13876.
Release Notes:
- N/A
This PR updates the Gleam docs provider to include the package name as a
suffix for docs entries:
<img width="639" alt="Screenshot 2024-07-03 at 5 48 28 PM"
src="https://github.com/zed-industries/zed/assets/1486634/0d98ffba-fbab-4511-ae16-e1e742d56f93">
This will help disambiguate modules with the same names from different
packages, as well as help out with providing better completions when the
package name and top-level module name do not match.
Release Notes:
- N/A
This PR improves the indexing of HexDocs content for Gleam packages.
We now index each of the modules in the package instead of just the
root.
Release Notes:
- N/A
This PR updates the `extension` crate's tests to use a dedicated test
extension for its tests instead of the real Gleam extension.
As the Gleam extension continues to evolve, it makes it less suitable to
use as a test fixture:
1. For a while now, the test has failed locally due to me having `gleam`
on my $PATH, which causes the extension's `get_language_server_command`
to go down a separate codepath.
2. With the addition of the `indexed_docs_providers` the test was
hanging indefinitely.
While these problems are likely solvable, it seems reasonable to have a
dedicated extension to use as a test fixture. That way we can do
whatever we need to exercise our test criteria.
The `test-extension` is a fork of the Gleam extension with some
additional functionality removed.
Release Notes:
- N/A
This PR extends the interface for slash commands defined in extensions
to have them return `SlashCommandOutput`.
This allows for slash commands to return multiple output sections for a
single piece of generated text.
Note that we don't allow specifying the icon to display in the
placeholder, as we don't want to commit to that in our API at the
moment.
Release Notes:
- N/A
- Confirming a completion now runs the command immediately
- Hitting `enter` on a line with a command now runs it
- The output of commands gets folded away and replaced with a custom
placeholder
- Eliminated ambient context
<img width="1588" alt="image"
src="https://github.com/zed-industries/zed/assets/482957/b1927a45-52d6-4634-acc9-2ee539c1d89a">
Release Notes:
- N/A
---------
Co-authored-by: Nathan Sobo <nathan@zed.dev>
This PR adds initial support for defining slash commands for the
Assistant from extensions.
Slash commands are defined in an extension's `extension.toml`:
```toml
[slash_commands.gleam-project]
description = "Returns information about the current Gleam project."
requires_argument = false
```
and then executed via the `run_slash_command` method on the `Extension`
trait:
```rs
impl Extension for GleamExtension {
// ...
fn run_slash_command(
&self,
command: SlashCommand,
_argument: Option<String>,
worktree: &zed::Worktree,
) -> Result<Option<String>, String> {
match command.name.as_str() {
"gleam-project" => Ok(Some("Yayyy".to_string())),
command => Err(format!("unknown slash command: \"{command}\"")),
}
}
}
```
Release Notes:
- N/A
In #12003 we found ourselves in need for precise region tracking in
which a given runnable has an effect in order to grab variables from it.
This PR makes it so that in task modal all task variables from queries
overlapping current cursor position.
However, in the process of working on that I've found that we cannot
always use a top-level capture to represent the full match range of
runnable (which has been my assumption up to this point). Tree-sitter
captures cannot capture sibling groups; we did just that in Rust
queries.
Thankfully, none of the extensions are affected as in them, a capture is
always attached to single node. This PR adds annotations to them
nonetheless; we'll be able to get rid of top-level captures in extension
runnables.scm once this PR is in stable version of Zed.
Release Notes:
- N/A
This PR updates the Gleam runnables to detect tests using the `describe`
API in Startest.
This isn't entirely functional yet, as it is still just uses the test
function name to run the tests (which Startest doesn't yet support).
Release Notes:
- N/A
This PR updates the extensions dependent on v0.0.6 of the
`zed_extension_api` crate to use the now-published version on crates.io
instead of a path dependency.
The impacted extensions are:
- `dart`
- `gleam`
- `haskell`
- `svelte`
Release Notes:
- N/A
This PR updates the Gleam extension to strip out newlines in the
completion details returned from the language server.
These newlines were causing the completion menu to compute a large
height for each item, resulting in lots of empty space in the completion
menu:
<img width="878" alt="Screenshot 2024-04-08 at 8 53 29 PM"
src="https://github.com/zed-industries/zed/assets/1486634/383c52ec-e5cb-4496-ae4c-28744b4ecaf5">
The approach to stripping newlines allocates a bit more than I would
like.
It would be good to see if it is possible for the Gleam language server
to not send us these newlines in the first place.
Release Notes:
- N/A
This PR adds the ability for extensions to provide certain language
settings via the language `config.toml`.
These settings are then merged in with the rest of the settings when the
language is loaded from the extension.
The language settings that are available are:
- `tab_size`
- `hard_tabs`
- `soft_wrap`
Additionally, for bundled languages we moved these settings out of the
`settings/default.json` and into their respective `config.toml`s .
For languages currently provided by extensions, we are leaving the
values in the `settings/default.json` temporarily until all released
versions of Zed are able to load these settings from the extension.
---
Along the way we ended up refactoring the `Settings::load` method
slightly, introducing a new `SettingsSources` struct to better convey
where the settings are being loaded from.
This makes it easier to load settings from specific locations/sets of
locations in an explicit way.
Release Notes:
- N/A
---------
Co-authored-by: Max <max@zed.dev>
Co-authored-by: Max Brunsfeld <maxbrunsfeld@gmail.com>
This PR adds the ability for extensions to implement
`label_for_completion` to customize completions coming back from the
language server.
We've used the Gleam extension as a motivating example, adding
`label_for_completion` support to it.
Release Notes:
- N/A
---------
Co-authored-by: Max <max@zed.dev>
Co-authored-by: Max Brunsfeld <maxbrunsfeld@gmail.com>
This PR updates the Gleam extension to give priority to the `gleam`
binary that is already on the PATH before downloading/installing a
separate Gleam version.
Release Notes:
- N/A
We're doing it. Svelte support is moving into an extension. This PR
fixes some issues that came up along the way.
Notes
* extensions need to be able to retrieve the path the `node` binary
installed by Zed
* previously we were silently swallowing any errors that occurred while
loading a grammar
* npm commands ran by extensions weren't run in the right directory
* Tree-sitter's WASM stdlib didn't support a C function (`strncmp`)
needed by the Svelte parser's external scanner
* the way that LSP installation status was reported was unnecessarily
complex
Release Notes:
- Removed built-in support for the Svelte and Gleam languages, because
full support for those languages is now available via extensions. These
extensions will be suggested for download when you open a `.svelte` or
`.gleam` file.
---------
Co-authored-by: Marshall <marshall@zed.dev>
In this PR, we've added two new methods that LSP extensions can call:
* `shell_env()`, for retrieving the environment variables set in the
user's default shell in the worktree
* `which(command)`, for looking up paths to an executable (accounting
for the user's shell env in the worktree)
To test this out, we moved the `uiua` language support into an
extension. We went ahead and removed the built-in support, since this
language is extremely obscure. Sorry @mikayla-maki. To continue coding
in Uiua in Zed, for now you can `Add Dev Extension` from the extensions
pane, and select the `extensions/uiua` directory in the Zed repo. Very
soon, we'll support publishing these extensions so that you'll be able
to just install it normally.
Release Notes:
- N/A
---------
Co-authored-by: Marshall <marshall@zed.dev>
This PR provides WASM extensions with write access to their own specific
working directory under the Zed `extensions` dir. This directory is set
as the extensions `current_dir` when they run. Extensions can return
relative paths from the `Extension::language_server_command` method, and
those relative paths will be interpreted relative to this working dir.
With this functionality, most language servers that we currently build
into zed can be installed using extensions.
Release Notes:
- N/A
This PR adds an `zed: Install Local Extension` action, which lets you
select a path to a folder containing a Zed extension, and install that .
When you select a directory, the extension will be compiled (both the
Tree-sitter grammars and the Rust code for the extension itself) and
installed as a Zed extension, using a symlink.
### Details
A few dependencies are needed to build an extension:
* The Rust `wasm32-wasi` target. This is automatically installed if
needed via `rustup`.
* A wasi-preview1 adapter WASM module, for building WASM components with
Rust. This is automatically downloaded if needed from a `wasmtime`
GitHub release
* For building Tree-sitter parsers, a distribution of `wasi-sdk`. This
is automatically downloaded if needed from a `wasi-sdk` GitHub release.
The downloaded artifacts are cached in a support directory called
`Zed/extensions/build`.
### Tasks
UX
* [x] Show local extensions in the Extensions view
* [x] Provide a button for recompiling a linked extension
* [x] Make this action discoverable by adding a button for it on the
Extensions view
* [ ] Surface errors (don't just write them to the Zed log)
Packaging
* [ ] Create a separate executable that performs the extension
compilation. We'll switch the packaging system in our
[extensions](https://github.com/zed-industries/extensions) repo to use
this binary, so that there is one canonical definition of how to
build/package an extensions.
### Release Notes:
- N/A
---------
Co-authored-by: Marshall <marshall@zed.dev>
Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>
This PR moves the Clippy configuration up to the workspace level.
We're using the [`lints`
table](https://doc.rust-lang.org/cargo/reference/workspaces.html#the-lints-table)
to configure the Clippy ruleset in the workspace's `Cargo.toml`.
Each crate in the workspace now has the following in their own
`Cargo.toml` to inherit the lints from the workspace:
```toml
[lints]
workspace = true
```
This allows for configuring rust-analyzer to show Clippy lints in the
editor by using the following configuration in your Zed `settings.json`:
```json
{
"lsp": {
"rust-analyzer": {
"initialization_options": {
"check": {
"command": "clippy"
}
}
}
}
```
Release Notes:
- N/A
