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>
This PR refactors the `CommandPaletteFilter` and
`CommandPaletteInterceptor` to better encapsulate their internals.
Previously these globals and their fields were publicly accessible,
which meant that there was a lot of reaching in and making
modifications.
These changes should make it easier to add additional consumers of these
hooks (right now they're primarily used by Vim mode).
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>
This PR introduces a new `command_palette_hooks` crate that contains the
types used to hook into the behavior of the command palette.
The `CommandPaletteFilter` was previously extracted to the `copilot`
crate in #7095, solely because that was the earliest ancestor of the
crates that depended on it.
The `CommandPaletteInterceptor` was still defined in `command_palette`
itself.
Both of these types were consumed by other crates wanting to influence
the behavior of the command palette, but required taking a dependency on
the entire `command_palette` crate in order to gain access to these
hooks.
By moving them out into their own crate, we can improve the compile
order and make crates like `vim` able to begin building sooner without
having to wait for `command_palette` to finish compiling.
Here's a comparison of the compilation graph before and after (ignore
the timings):
#### Before
<img width="332" alt="Screenshot 2024-02-25 at 12 42 29 PM"
src="https://github.com/zed-industries/zed/assets/1486634/a57c662e-fbc2-41ab-9e30-cca17afa6c73">
#### After
<img width="362" alt="Screenshot 2024-02-25 at 12 51 15 PM"
src="https://github.com/zed-industries/zed/assets/1486634/c1a6d29c-b607-4604-8f1b-e5d318bf8849">
Release Notes:
- N/A
After a lot of back-and-forth, this is a small attempt to implement
solutions (1) and (3) in
https://github.com/zed-industries/zed/issues/7902. The goal is to have a
minimal change that helps users get started with Zed, until we have
extensions ready.
Release Notes:
- Added detection of user-installed `gopls` to Go language server
adapter. If a user has `gopls` in `$PATH` when opening a worktree, it
will be used.
- Added detection of user-installed `zls` to Zig language server
adapter. If a user has `zls` in `$PATH` when opening a worktree, it will
be used.
Example:
I don't have `go` installed globally, but I do have `gopls`:
```
~ $ which go
go not found
~ $ which gopls
/Users/thorstenball/code/go/bin/gopls
```
But I do have `go` in a project's directory:
```
~/tmp/go-testing φ which go
/Users/thorstenball/.local/share/mise/installs/go/1.21.5/go/bin/go
~/tmp/go-testing φ which gopls
/Users/thorstenball/code/go/bin/gopls
```
With current Zed when I run `zed ~/tmp/go-testing`, I'd get the dreaded
error:
But with the changes in this PR, it works:
```
[2024-02-23T11:14:42+01:00 INFO language::language_registry] starting language server "gopls", path: "/Users/thorstenball/tmp/go-testing", id: 1
[2024-02-23T11:14:42+01:00 INFO language::language_registry] found user-installed language server for Go. path: "/Users/thorstenball/code/go/bin/gopls", arguments: ["-mode=stdio"]
[2024-02-23T11:14:42+01:00 INFO lsp] starting language server. binary path: "/Users/thorstenball/code/go/bin/gopls", working directory: "/Users/thorstenball/tmp/go-testing", args: ["-mode=stdio"]
```
---------
Co-authored-by: Antonio <antonio@zed.dev>
In #6954 a user has trouble using copilot. We haven't gotten to the
bottom of the problem, but one problem is that apparently sometimes (I'm
going to find out when) copilot sends an `"OK"` status message without a
username. This is from the user's logs:
2024-02-20T15:28:41-03:00 [ERROR] failed to deserialize response from
language server: missing field `user`. Response from language server:
"{\"status\":\"OK\"}"
The official `copilot.vim` plugin handles this as if the user is not
authenticated (!= authorized):
https://github.com/github/copilot.vim/blob/1a284014d2e0baf367706a94b2a9ee5fd56fd457/autoload/copilot.vim#L574-L579
So that's what I'm doing here too.
Release Notes:
- Fixed wrong handling of Copilot sign-in status in rare cases.
Current limitations:
* Not able to navigate into JAR files
Release Notes:
- Added Clojure language support
---------
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
Fixes https://github.com/zed-industries/zed/issues/7534 by not requiring
assets for gopls and vscode-eslint langservers — those two are the only
ones in Zed that do not use assets directly when determining langserver
version and retrieving those.
All other servers deal with assets, hence require those to be present.
The problem with https://github.com/tamasfe/taplo/releases is that they
host multiple binary releases in the same release list, so for now the
code works because only the langserver has assets — but as soon as
another release there gets assets, it will break again.
We could filter out those by names also, but they also tend to change
(and can be edited manually), so keeping it as is for now.
Release Notes:
- Fixed gopls language server downloads
([7534](https://github.com/zed-industries/zed/issues/7534))
Based on the great work in
https://github.com/zed-industries/zed/pull/7130 , now sends this data
```
[crates/lsp/src/lsp.rs:588] ClientInfo { name: name.to_string(), version: Some(version.to_string()) } = ClientInfo {
name: "Zed Dev",
version: Some(
"0.122.0",
),
}
```
with every LSP server initialization.
Release Notes:
- Added Zed name and version to LSP InitializeParams requests
Release Notes:
- Added bash syntax highlighting to `.env` files.
- Added a `private_files` setting for configuring which files should be
considered to contain environment variables or other sensitive
information.
- Added a `redact_private_values` setting to add or remove censor bars
over variable values in files matching the `private_files` patterns.
-(internal) added a new `redactions.scm` query to our language support,
allowing different config file formats to indicate where environment
variable values can be identified in the syntax tree, added this query
to `bash`, `json`, `toml`, and `yaml` files.
---------
Co-authored-by: Nathan <nathan@zed.dev>
This should prevent a class of bugs where one queries the wrong type of
global, which results in oddities at runtime.
Release Notes:
- N/A
---------
Co-authored-by: Marshall <marshall@zed.dev>
Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>
Add hidden_action_types to CommandPaletteFilter.
WindowContext.available_actions now returns global actions as well.
Co-authored-by: Antonio <antonio@zed.dev>
See Linear description for the full explanation of the issue. This PR is
mostly a mechanical change, except for the one case where we do pass in
an explicit `next_id` instead of `model_id` in project.rs.
Release Notes:
- Fixed a bug where some results were not reported in project search in
presence of unnamed buffers.
