Commit Graph

8 Commits

Author SHA1 Message Date
Marshall Bowers
80bd40cfa3
zed_extension_api: Fork new version (#12160)
This PR forks a new version of the `zed_extension_api` in preparation
for some upcoming changes that require breaking changes to the WIT.

Release Notes:

- N/A

---------

Co-authored-by: Max <max@zed.dev>
2024-05-22 19:07:52 -04:00
Marshall Bowers
c851e6edba
Add language_server_workspace_configuration to extension API (#10212)
This PR adds the ability for extensions to implement
`language_server_workspace_configuration` to provide workspace
configuration to the language server.

We've used the Dart extension as a motivating example for this, pulling
it out into an extension in the process.

Release Notes:

- Removed built-in support for Dart, in favor of making it available as
an extension. The Dart extension will be suggested for download when you
open a `.dart` file.

---------

Co-authored-by: Max <max@zed.dev>
Co-authored-by: Max Brunsfeld <maxbrunsfeld@gmail.com>
2024-04-05 17:04:07 -04:00
Marshall Bowers
d306b531c7
Add label_for_completion to extension API (#10175)
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>
2024-04-04 13:56:04 -04:00
Marshall Bowers
8b586ef8e7
Add new make-file-executable API for extensions (#10047)
This PR adds a new function, `make-file-executable`, to the Zed
extension API that can be used to mark a given file as executable
(typically the language server binary).

This is available in v0.0.5 of the `zed_extension_api` crate.

We also reworked how we represent the various WIT versions on disk to
make it a bit clearer what the version number entails.

Release Notes:

- N/A

---------

Co-authored-by: Max <max@zed.dev>
2024-04-01 15:28:24 -04:00
Max Brunsfeld
6ebe599c98
Fix issues with extension API that come up when moving Svelte into an extension (#9611)
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>
2024-03-22 17:29:06 -07:00
Max Brunsfeld
585e8671e3
Add a schema to extensions, to prevent installing extensions on too old of a Zed version (#9599)
Release Notes:

- N/A

---------

Co-authored-by: Marshall <marshall@zed.dev>
2024-03-20 17:33:26 -04:00
Marshall Bowers
22fe03913c
Move Clippy configuration to the workspace level (#8891)
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
2024-03-05 12:01:17 -05:00
Max Brunsfeld
268fa1cbaf
Add initial support for defining language server adapters in WebAssembly-based extensions (#8645)
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>
2024-03-01 16:00:55 -08:00