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
`futures_lite::AsyncReadExt::read_to_string` (that we use in
`RealFs::load`) explicitly does not allocate memory for String contents
up front, which leads to excessive reallocations. That reallocation time
is a significant contributor to the time we spend loading files (esp
large ones). For example, out of ~1s that it takes to open up a 650Mb
ASCII buffer on my machine (after changes related to fingerprinting from
#9007), 350ms is spent in `RealFs::load`.
This change slashes that figure to ~110ms, which is still *a lot*. About
60ms out of 110ms remaining is spent zeroing memory. Sadly,
`AsyncReadExt` API forces us to zero a buffer we're reading into
(whether it's via read_to_string or read_exact), but at the very least
this commit alleviates unnecessary reallocations.
We could probably use something like
[simdutf8](https://docs.rs/simdutf8/latest/simdutf8/) to speed up UTF8
validation in this method as well, though that takes only about ~18ms
out of 110ms, so while it is significant, I've left that out for now.
Memory zeroing is a bigger problem at this point.
Before:
After:
/cc @as-cii
Release Notes:
- Improved performance when loading large files.
Changes Zed CI to build and upload Linux nightly bundles.
* `todo!(linux)` are replaced with `TODO linux` to make `todo!`-based
workflows more convenient
* renames `run-build-dmg` label into `run-bundling`, also renames a few
GH Actions entries to be more generic
* make another upload path for Linux, which keeps a separate file with SHA to version the nightly artifact.
* adds a `*.deb` package building with a couple of caveats, marked with
new `TODO linux` entries:
1. `cargo-bundle` is not very flexible, so it generates artifacts with
the structure and names that we're unable to alter before/during the
generation.
For that, a set of extra steps is made by repacking the *.deb package —
this is not very portable between different Linux distros, so later one
needs to find a way to combine multiple package types in this script.
2. `cargo-bundle` is not able to properly generate the *.msi bundle
despite declaring it in the features:
https://github.com/burtonageo/cargo-bundle/issues/116
Windows needs to invent its own way of bundling or fix the tool.
3. Both `cli` and `zed` binaries are added into the archive under
`/usr/local/bin/` path with their `-$channel` suffix
(-nightly/-preview/-dev/-stable) and a `/usr/local/bin/zed ->
/usr/local/bin/cli-nightly` symlink is made to make CLI work as Zed
launcher:
```
~/work/zed kb/linux-nightly:origin/kb/linux-nightly* ❯ dpkg -c target/zed_amd64.deb
drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./
drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/
drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/local/
drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/local/bin/
-rwxr-xr-x allaptop/allaptop 8746832 2024-03-06 00:53 ./usr/local/bin/cli-nightly
-rwxr-xr-x allaptop/allaptop 689078560 2024-03-06 00:53 ./usr/local/bin/zed-nightly
drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/share/
drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/share/applications/
-rw-r--r-- allaptop/allaptop 153 2024-03-06 00:53 ./usr/share/applications/zed.desktop
drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/share/icons/
drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/share/icons/hicolor/
drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/share/icons/hicolor/1024x1024@2x/
drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/share/icons/hicolor/1024x1024@2x/apps/
-rw-r--r-- allaptop/allaptop 716288 2024-03-06 00:53 ./usr/share/icons/hicolor/1024x1024@2x/apps/zed.png
drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/share/icons/hicolor/512x512/
drwxr-xr-x allaptop/allaptop 0 2024-03-06 00:53 ./usr/share/icons/hicolor/512x512/apps/
-rw-r--r-- allaptop/allaptop 239870 2024-03-06 00:53 ./usr/share/icons/hicolor/512x512/apps/zed.png
lrwxrwxrwx allaptop/allaptop 0 2024-03-06 00:53 ./usr/local/bin/zed -> /usr/local/bin/cli-nightly
```
But the CLI does not work under Linux yet and there's no way to install
that CLI from Zed now; Zed binary itself is not able to open
`file/location:12:34`-like things and set up the env properly, but is
able to start or open a directory.
So, this structure can be considered temporary and changed, if needed.
4. Zed Nightly on Linux does not know how to update itself, so all
nightly publishing is not picked up automatically.
5. Rust cache from `main` builds does not get shared between CI jobs,
due to being run in a different CI job that forms a different CI key, so
```
- name: Cache dependencies
uses: swatinem/rust-cache@v2
with:
save-if: ${{ false }}
```
would not work.
This makes Linux bundling jobs long.
Release Notes:
- N/A
Modifier keys are dispatched as events on wayland, unlike macos. This
prevents pending bindings from matching, because something like e.g. `g
shift-e` is received by the key matcher as `g shift shift-e`.
This should significantly reduce database load on redeploy.
Co-Authored-By: Max <max@zed.dev>
Co-Authored-By: Nathan <nathan@zed.dev>
Release Notes:
- Reduced likelihood of being disconnected during deploys
Co-authored-by: Max <max@zed.dev>
Co-authored-by: Nathan <nathan@zed.dev>
Tasks are able to access a users selected text using the environment
variable "ZED_SELECTED_TEXT".
Release notes:
- Added ZED_SELECTED_TEXT task variable which contains contents of
selection
This reduces the server time to compute the hash from 40ms to 5µs,
which should remove this as a noticable chunk of CPU time in production.
(An attacker who has access to our database will now need only 10^54
years of CPU time instead of 10^58 to brute force a token).
Release Notes:
- Improved sign in latency by 40ms.
This adds a GPUI fallback for window prompts. Linux does not support
this feature by default, so we have to implement it ourselves.
This implementation also makes it possible for GPUI clients to override
the platform prompts with their own implementations.
This is just a first pass. These alerts are not keyboard accessible yet,
does not reflect the prompt level, they're implemented in-window, rather
than as popups, and the whole feature need a pass from a designer.
Regardless, this gets us one step closer to Linux support :)
<img width="650" alt="Screenshot 2024-03-06 at 5 58 08 PM"
src="https://github.com/zed-industries/zed/assets/2280405/972ebb55-fd1f-4066-969c-a87f63b22a6f">
Release Notes:
- N/A
Release Notes:
- N/A
`DoubleBuffered` is not currently very necessary because we only care
about a single field `OutputState::scale` but I think it can be useful
for other objects as it's a fairly common pattern in wayland.
For the moment the windows port has a single display with hard-coded
values.
This first PR is just to at least fetch the **actual size of the current
display**. The idea
is using this code as a first template to start getting familar with the
code base
and prepare the work for enumerating all displays.
We were seeing panics due to callers assuming they had valid
excerpt_ids, but that cannot easily be guaranteed across await points as
anyone may remove an excerpt.
Release Notes:
- Fixed a panic when hovering in a multibuffer
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>
We'll send at least one every 100ms, but may send more if other messages
are sent on the connection.
Release Notes:
- Fixed some slowness when collaborating with verbose language servers.
