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
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
- 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
This PR adds **internal** ability to run arbitrary language servers via
WebAssembly extensions. The functionality isn't exposed yet - we're just
landing this in this early state because there have been a lot of
changes to the `LspAdapter` trait, and other language server logic.
## Next steps
* Currently, wasm extensions can only define how to *install* and run a
language server, they can't yet implement the other LSP adapter methods,
such as formatting completion labels and workspace symbols.
* We don't have an automatic way to install or develop these types of
extensions
* We don't have a way to package these types of extensions in our
extensions repo, to make them available via our extensions API.
* The Rust extension API crate, `zed-extension-api` has not yet been
published to crates.io, because we still consider the API a work in
progress.
Release Notes:
- N/A
---------
Co-authored-by: Marshall <marshall@zed.dev>
Co-authored-by: Nathan <nathan@zed.dev>
Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>
