Release Notes:
- Extracted GLSL language support into an extension.
---------
Co-authored-by: Marshall <marshall@zed.dev>
Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>
Release Notes:
- Fixed a bug where extension installation would appear to succeed even
if the download did not complete due to network interruptions
([#10330](https://github.com/zed-industries/zed/issues/10330)).
Co-authored-by: Marshall <marshall@zed.dev>
As of #10393 some icons in the chat were invisible, looking at the icons
I noticed that the viewport was actually 800x800, I scaled that down to
16x16 and now they work fine again.
Also remove the `reply_arrow_left` icon because it is not used at all.
Thanks to @RemcoSmitsDev for noticing.
I don't have any expertise in svg's, so if something is off about the
svg markup reach out to me.
Release Notes:
- N/A
Fixes#7694
The new setting accepts "last_workspace" (default) and "none" as
options.
In a follow-up PR I'll add a new option that re-launches all of the Zed
windows and not just the last one.
Release Notes:
- Added `restore_on_startup` option, accepting `last_workspace`
(default) and `none` options. With `none`, new Zed instances will not
restore workspaces that were open last.
Release Notes:
- Added support for toggling a checkbox in markdown preview by clicking
on it (cmd+click)
([#5226](https://github.com/zed-industries/zed/issues/5226)).
---------
Co-authored-by: Remco Smits <62463826+RemcoSmitsDev@users.noreply.github.com>
Release Notes:
- Added support for scrolling to the message you are replying to when
clicking on the reply preview
([#10028](https://github.com/zed-industries/zed/issues/10028)).
Co-authored-by: Bennet Bo Fenner <53836821+bennetbo@users.noreply.github.com>
In addition to `ctrl-tab` and `ctrl-shift-tab`, VS Code allows changing
the selection in the tab switcher via the up and down arrow keys.
Release Notes:
- Added bindings to allow `up` and `down` arrow keys to be used while
the tab switcher is open.
This PR updates Danger to proxy its requests to GitHub through a proxy
service.
## Motivation
Currently Danger is not able to run on PRs opened from forks of Zed.
This is due to GitHub Actions' security policies. Forks are not able to
see any of the repository secrets, and the built-in
`secrets.GITHUB_TOKEN` has its permissions
[restricted](https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token)
to only reads when running on forks.
I asked around on the Danger repo, and some big projects
(DefinitelyTyped) are working around this by using a publicly-listed
(although slightly obfuscated) token:
https://github.com/danger/danger-js/issues/918#issuecomment-2048629487.
While this approach is _probably_ okay given the limited scope and
permissions of the GitHub token, I would still prefer a solution that
avoids disclosing the token at all.
## Explanation
I ended up writing a small proxy service, [Danger
Proxy](https://github.com/maxdeviant/danger-proxy), that can be used to
provide Danger with the ability to make authenticated GitHub requests,
but without disclosing the token.
From the README:
> Danger Proxy will:
>
> - Proxy all requests to `/github/*` to the GitHub API. The provided
GitHub API token will be used for authentication.
> - Restrict requests to the list of repositories specified in the
`ALLOWED_REPOS` environment variable.
> - Restrict requests to the subset of the GitHub API that Danger
requires.
I have an instance of this service deployed to
[danger-proxy.fly.dev](https://danger-proxy.fly.dev/).
Release Notes:
- N/A
New list (used tasks are above the separator line, sorted by the usage
recency), then all language tasks, then project-local and global tasks
are listed.
Note that there are two test tasks (for `test_name_1` and `test_name_2`
functions) that are created from the same task template:
<img width="563" alt="Screenshot 2024-04-10 at 01 00 46"
src="https://github.com/zed-industries/zed/assets/2690773/7455a82f-2af2-47bf-99bd-d9c5a36e64ab">
Tasks are deduplicated by labels, with the used tasks left in case of
the conflict with the new tasks from the template:
<img width="555" alt="Screenshot 2024-04-10 at 01 01 06"
src="https://github.com/zed-industries/zed/assets/2690773/8f5a249e-abec-46ef-a991-08c6d0348648">
Regular recent tasks can be now removed too:
<img width="565" alt="Screenshot 2024-04-10 at 01 00 55"
src="https://github.com/zed-industries/zed/assets/2690773/0976b8fe-b5d7-4d2a-953d-1d8b1f216192">
When the caret is in the place where no function symbol could be
retrieved, no cargo tests for function are listed in tasks:
<img width="556" alt="image"
src="https://github.com/zed-industries/zed/assets/2690773/df30feba-fe27-4645-8be9-02afc70f02da">
Part of https://github.com/zed-industries/zed/issues/10132
Reworks the task code to simplify it and enable proper task labels.
* removes `trait Task`, renames `Definition` into `TaskTemplate` and use
that instead of `Arc<dyn Task>` everywhere
* implement more generic `TaskId` generation that depends on the
`TaskContext` and `TaskTemplate`
* remove `TaskId` out of the template and only create it after
"resolving" the template into the `ResolvedTask`: this way, task
templates, task state (`TaskContext`) and task "result" (resolved state)
are clearly separated and are not mixed
* implement the logic for filtering out non-related language tasks and
tasks that have non-resolved Zed task variables
* rework Zed template-vs-resolved-task display in modal: now all reruns
and recently used tasks are resolved tasks with "fixed" context (unless
configured otherwise in the task json) that are always shown, and Zed
can add on top tasks with different context that are derived from the
same template as the used, resolved tasks
* sort the tasks list better, showing more specific and least recently
used tasks higher
* shows a separator between used and unused tasks, allow removing the
used tasks same as the oneshot ones
* remote the Oneshot task source as redundant: all oneshot tasks are now
stored in the inventory's history
* when reusing the tasks as query in the modal, paste the expanded task
label now, show trimmed resolved label in the modal
* adjusts Rust and Elixir task labels to be more descriptive and closer
to bash scripts
Release Notes:
- Improved task modal ordering, run and deletion capabilities
This PR reworks the way workspace notifications are identified to use a
new `NotificationId` type.
A `NotificationId` is bound to a given type that is used as a unique
identifier. Generally this will be a unit struct that can be used to
uniquely identify this notification.
A `NotificationId` can also accept an optional `ElementId` in order to
distinguish between different notifications of the same type.
This system avoids the issue we had previously of selecting `usize` IDs
somewhat arbitrarily and running the risk of having two independent
notifications collide (and thus interfere with each other).
This also fixes a bug where multiple suggestion notifications for the
same extension could be live at once
Fixes https://github.com/zed-industries/zed/issues/10320.
Release Notes:
- Fixed a bug where multiple extension suggestions for the same
extension could be shown at once
([#10320](https://github.com/zed-industries/zed/issues/10320)).
---------
Co-authored-by: Max <max@zed.dev>
Currently in Zed, certain characters require pressing the key twice to
move the caret through that character. For example: "❤️" and "y̆".
The reason for this is as follows:
Currently, Zed uses `chars` to distinguish different characters, and
calling `chars` on `y̆` will yield two `char` values: `y` and `\u{306}`,
and calling `chars` on `❤️` will yield two `char` values: `❤` and
`\u{fe0f}`.
Therefore, consider the following scenario (where ^ represents the
caret):
- what we see: ❤️ ^
- the actual buffer: ❤ \u{fe0f} ^
After pressing the left arrow key once:
- what we see: ❤️ ^
- the actual buffer: ❤ ^ \u{fe0f}
After pressing the left arrow key again:
- what we see: ^ ❤️
- the actual buffer: ^ ❤ \u{fe0f}
Thus, two left arrow key presses are needed to move the caret, and this
PR fixes this bug (or this is actually a feature?).
I have tried to keep the scope of code modifications as minimal as
possible. In this PR, Zed handles such characters as follows:
- what we see: ❤️ ^
- the actual buffer: ❤ \u{fe0f} ^
After pressing the left arrow key once:
- what we see: ^ ❤️
- the actual buffer: ^ ❤ \u{fe0f}
Or after pressing the delete key:
- what we see: ^
- the actual buffer: ^
Please note that currently, different platforms and software handle
these special characters differently, and even the same software may
handle these characters differently in different situations. For
example, in my testing on Chrome on macOS, GitHub treats `y̆` as a
single character, just like in this PR; however, in Rust Playground,
`y̆` is treated as two characters, and pressing the delete key does not
delete the entire `y̆` character, but instead deletes `\u{306}` to yield
the character `y`. And they both treat `❤️` as a single character,
pressing the delete key will delete the entire `❤️` character.
This PR is based on the principle of making changes with the smallest
impact on the code, and I think that deleting the entire character with
the delete key is more intuitive.
Release Notes:
- Fix caret movement issue for some special characters
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
Co-authored-by: Thorsten <thorsten@zed.dev>
Co-authored-by: Bennet <bennetbo@gmx.de>
This PR fixes a potential panic that could occur when loading malformed
Wasm files.
We now use the `parse_wasm_extension_version` function that was
previously used just to extract the Zed extension API version from the
Wasm bytes as a pre-validation step. By parsing the entirety of the Wasm
file here instead of returning as soon as we find the version, the
invalid Wasm bytes are now surfaced as an `Err` instead of a panic.
We were able to replicate the panic using the following test:
```rs
#[gpui::test]
async fn test_bad_wasm(cx: &mut TestAppContext) {
init_test(cx);
let wasm_host = cx.update(|cx| {
WasmHost::new(
FakeFs::new(cx.background_executor().clone()),
FakeHttpClient::with_200_response(),
FakeNodeRuntime::new(),
Arc::new(LanguageRegistry::test(cx.background_executor().clone())),
PathBuf::from("/the/work/dir".to_string()),
cx,
)
});
let mut wasm_bytes = std::fs::read("/Users/maxdeviant/Library/Application Support/Zed/extensions/installed/dart/extension.wasm").unwrap();
// This is the error message we were seeing in the stack trace:
// range end index 267037 out of range for slice of length 253952
dbg!(&wasm_bytes.len());
// Truncate the bytes to the same point:
wasm_bytes.truncate(253952);
std::fs::write("/tmp/bad-extension.wasm", wasm_bytes.clone()).unwrap();
let manifest = Arc::new(ExtensionManifest {
id: "the-extension".into(),
name: "The Extension".into(),
version: "0.0.1".into(),
schema_version: SchemaVersion(1),
description: Default::default(),
repository: Default::default(),
authors: Default::default(),
lib: LibManifestEntry {
kind: None,
version: None,
},
themes: Default::default(),
languages: Default::default(),
grammars: Default::default(),
language_servers: Default::default(),
});
// 💥
let result = wasm_host
.load_extension(wasm_bytes, manifest, cx.executor())
.await;
dbg!(result.map(|_| ()));
```
Release Notes:
- Fixed a crash that could occur when loading malformed Wasm extensions
([#10352](https://github.com/zed-industries/zed/issues/10352)).
---------
Co-authored-by: Max <max@zed.dev>
There hasn't been a componentized way to create inputs or text fields
thus far due to the innate circular dependency between the `ui` and
`editor` crates. To bypass this issue we are introducing a new
`ui_text_field` crate to specifically handle this component.
`TextField` provides the ability to add stacked or inline labels, as
well as applies a standard visual style to inputs.
Example:
We'll continue to evolve this component in the near future and start
using it in the app once we've built out the needed functionality.
Release Notes:
- N/A
---------
Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>
This panic has occured a handful of times, I think it must be the case
that:
1. Item is dropped outside of an update loop
2. The next update is this one
In that case no flush effects will have called the release observers
yet, but we cannot upgrade the WeakModel because the ref count is 0
Release Notes:
- Fixed a (rare) panic while collaborating
This PR renames `language::Buffer::new` to `language::Buffer::local` and
simplifies its interface. Instead of taking a replica id (which should
always be 0 for the local case) and a `BufferId`, which was awkward and
verbose to construct, it simply takes text and a `cx`.
It uses the `cx` to derive a `BufferId` from the `EntityId` associated
with the `cx`, which should always be positive based on the following
analysis...
We convert the entity id to a u64 using this method on `EntityId`, which
is defined by macros in the `slotmap` crate:
```rust
pub fn as_ffi(self) -> u64 {
(u64::from(self.version.get()) << 32) | u64::from(self.idx)
}
```
If you look at the type of `version` in `KeyData`, it is non-zero:
```rust
#[derive(Clone, Copy, PartialEq, Eq, PartialOrd, Ord, Hash)]
pub struct KeyData {
idx: u32,
version: NonZeroU32,
}
```
This commit also adds `Context::reserve_model` and
`Context::insert_model` to determine a model's entity ID before it is
created, which we need in order to assign a `BufferId` in the background
when loading a buffer asynchronously.
Release Notes:
- N/A
---------
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
- Fixed#8603
For the label title of the project panel, I find that there is no place
to use to get the title of the label to do some operations, it should be
safe to modify it, but I'm not sure how we need to modify the problem, I
can think of two scenarios:
1. Modify every place where you don't want multiple lines to appear
2. Make the label only display a single line (e.g. provide a new
parameter, or a new label type?)
Followup to #10327
It can be enabled with the following setting:
"line_indicator_format": "short"
No release note, as the original change didn't go out to Preview yet.
/cc @bartekpacia @0x2CA
Release Notes:
- N/A
This fixes certain shortcuts/motions on X11 like in vim mode "v i )",
where previously zed would interpret it as "v i SHIFT )" due to the x11
backend emitting key press events for modifier keys even though other
platforms like Wayland don't. This also adds support for
ModifiersChanged events to X11
Release Notes:
- Fixed vim motions like "v i )" not working on X11
([#10199](https://github.com/zed-industries/zed/issues/10199)).
Release Notes:
- N/A
Picks up https://github.com/kvark/blade/pull/105,
https://github.com/kvark/blade/pull/97, and more
Switches the presentation to be non-blocking, which will improve the
latency slightly.
Allows to start playing with GLES backend, e.g.
```bash
cd crates/gpui
RUSTFLAGS="--cfg gles" CARGO_TARGET_DIR=./target-gl cargo run --example hello_world
```
It doesn't currently render properly due to an issue that needs
investigation, see
https://github.com/kvark/blade/pull/105#issuecomment-2041006542
But at least it's a start
Co-authored-by: Mikayla Maki <mikayla@zed.dev>
This fixes a bug in https://github.com/zed-industries/zed/pull/9818,
where the status was not removed if the request failed. It also adds
replication of these new status messages to guests when collaborating.
Release Notes:
- Fixed an issue where the status of failed LSP actions was left in the
status bar
---------
Co-authored-by: Marshall <marshall@zed.dev>
Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>
This fixed an issue introduced in
https://github.com/zed-industries/zed/pull/10126, where, when toggling
comments in a language with multiple line comment prefixes (e.g. Gleam,
Erlang) Zed would insert the *last* prefix instead of the first.
Release Notes:
- Fixed an issue where the `toggle comments` command inserted the wrong
line comment prefix in some languages (preview only).
Co-authored-by: Marshall <marshall@zed.dev>
Part of https://github.com/zed-industries/zed/issues/10132 extracted out
of a bigger PR that refactors tasks and shows labels that look more like
commands (ergo needs better readable package names)
Release Notes:
- N/A
This should help with some of the memory problems reported in
https://github.com/zed-industries/zed/issues/8436, especially the ones
related to large files (see:
https://github.com/zed-industries/zed/issues/8436#issuecomment2037442695),
by **reducing the memory required to represent a buffer in Zed by
~50%.**
### How?
Zed's memory consumption is dominated by the in-memory representation of
buffer contents.
On the lowest level, the buffer is represented as a
[Rope](https://en.wikipedia.org/wiki/Rope_(data_structure)) and that's
where the most memory is used. The layers above — buffer, syntax map,
fold map, display map, ... — basically use "no memory" compared to the
Rope.
Zed's `Rope` data structure is itself implemented as [a `SumTree` of
`Chunks`](8205c52d2b/crates/rope/src/rope.rs (L35-L38)).
An important constant at play here is `CHUNK_BASE`:
`CHUNK_BASE` is the maximum length of a single text `Chunk` in the
`SumTree` underlying the `Rope`. In other words: It determines into how
many pieces a given buffer is split up.
By changing `CHUNK_BASE` we can adjust the level of granularity
withwhich we index a given piece of text. Theoretical maximum is the
length of the text, theoretical minimum is 1. Sweet spot is somewhere
inbetween, where memory use and performance of write & read access are
optimal.
We started with `16` as the `CHUNK_BASE`, but that wasn't the result of
extensive benchmarks, more the first reasonable number that came to
mind.
### What
This changes `CHUNK_BASE` from `16` to `64`. That reduces the memory
usage, trading it in for slight reduction in performance in certain
benchmarks.
### Benchmarks
I added a benchmark suite for `Rope` to determine whether we'd regress
in performance as `CHUNK_BASE` goes up. I went from `16` to `32` and
then to `64`. While `32` increased performance and reduced memory usage,
`64` had one slight drop in performance, increases in other benchmarks
and substantial memory savings.
| `CHUNK_BASE` from `16` to `32` | `CHUNK_BASE` from `16` to `64` |
|-------------------|--------------------|
|
|
|
### Real World Results
We tested this by loading a 138 MB `*.tex` file (parsed as plain text)
into Zed and measuring in `Instruments.app` the allocation.
#### standard allocator
Before, with `CHUNK_BASE: 16`, the memory usage was ~827MB after loading
the buffer.
| `CHUNK_BASE: 16` |
|---------------------|
|
|
After, with `CHUNK_BASE: 64`, the memory usage was ~396MB after loading
the buffer.
| `CHUNK_BASE: 64` |
|---------------------|
|
|
#### `mimalloc`
`MiMalloc` by default and that seems to be pretty aggressive when it
comes to growing memory. Whereas the std allocator would go up to
~800mb, MiMalloc would jump straight to 1024MB.
I also can't get `MiMalloc` to work properly with `Instruments.app` (it
always shows 15MB of memory usage) so I had to use these `Activity
Monitor` screenshots:
| `CHUNK_BASE: 16` |
|---------------------|
|
|
| `CHUNK_BASE: 64` |
|---------------------|
|
|
### Release Notes
Release Notes:
- Reduced memory usage for files by up to 50%.
---------
Co-authored-by: Antonio <antonio@zed.dev>
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
