Part of #31174
Because the keyboard layout parameter wasn’t set correctly, characters
don’t show up properly when using the German layout at launch.
To reproduce:
Switch to the German layout, launch Zed, and press the `7` key. it
should output `7`, but instead it outputs `è`.
Release Notes:
- N/A
Closes#28164
This PR adresses inproper keybinds being shown in MacOS application
menus. The issue arises because the keybinds shown in MacOS application
menus are unaware of keybind contexts (they are only ever updated [on a
keymap-change](6d1dd109f5/crates/zed/src/zed.rs (L1421))).
Thus, using the keybind that was added last in the keymap can result in
incorrect keybindings being shown quite frequently, as they might belong
to a different context not generally available (applies the same for the
default keymap as well as for user-keymaps).
For example, the linked issue arises because the keybind found last in
the iterator is
6d1dd109f5/assets/keymaps/vim.json (L759),
which is not even available in most contexts (and, additionally, the `e`
of `escape` is rendered here as a keybind which seems to be a seperate
issue).
Additionally, this would result in inconsistent behavior with some
Vim-keybinds. A vim-keybind would be used only when available but
otherwise the default binding would be shown (see `Undo` and `Redo` as
an example below), which seems inconsistent.
This PR fixes this by instead using the first keybind found in keymaps,
which is expected to be the keybind available in most contexts.
Additionally, this allows rendering some more keybinds for actions which
vim-keybind cannot be displayed (Find In Project for example) .This
seems to be more reasonable until [this related
comment](6d1dd109f5/crates/gpui/src/keymap.rs (L199-L204))
is resolved.
This includes a revert of #25878 as well. With this change, the change
made in #25878 becomes obsolete and would also regress the behavior back
to the state prior to that PR.
| | `main` | This PR |
| --- | --- | --- |
| Edit-menu | <img width="220" alt="main_edit"
src="https://github.com/user-attachments/assets/9f793b64-80b6-4a5b-b7e5-628f0d552166"
/> | <img width="220" alt="PR_edit"
src="https://github.com/user-attachments/assets/bccb444c-7a49-41d5-9377-d90b1639a3ed"
/> |
| View-menu | <img width="214" alt="main_view"
src="https://github.com/user-attachments/assets/0e6a6632-df02-4883-9f5a-facb4d0263b5"
/> | <img width="214" alt="PR_view"
src="https://github.com/user-attachments/assets/14600ece-fcaa-447a-94ef-4fa350eca49c"
/> |
Release Notes:
- Improved keybinds displayed for actions in MacOS application menus.
https://github.com/zed-industries/zed/issues/30972 brought up another
case where our context is not enough to track the actual source of the
issue: we get a general top-level error without inner error.
The reason for this was `.ok_or_else(|| anyhow!("failed to read HEAD
SHA"))?; ` on the top level.
The PR finally reworks the way we use anyhow to reduce such issues (or
at least make it simpler to bubble them up later in a fix).
On top of that, uses a few more anyhow methods for better readability.
* `.ok_or_else(|| anyhow!("..."))`, `map_err` and other similar error
conversion/option reporting cases are replaced with `context` and
`with_context` calls
* in addition to that, various `anyhow!("failed to do ...")` are
stripped with `.context("Doing ...")` messages instead to remove the
parasitic `failed to` text
* `anyhow::ensure!` is used instead of `if ... { return Err(...); }`
calls
* `anyhow::bail!` is used instead of `return Err(anyhow!(...));`
Release Notes:
- N/A
Reverts zed-industries/zed#31022
Sorry @mikayla-maki, I found that things are more complicated than I
thought.
The lines returned by shape_text must maintain the same length as all
the original characters, otherwise the subsequent offset needs to always
consider the difference of `\r\n` or `\n` to do the offset.
Before, we only needed to add +1 after each offset after the line, but
now we need to consider +1 or +2, which is much more complicated.
Release Notes:
- N/A
---
Today I check the shape_text result on Windows, I get:
<img width="409" alt="屏幕截图 2025-05-20 222908"
src="https://github.com/user-attachments/assets/3ee93911-3de1-4e01-9433-00c626fc2369"
/>
Here the `shape_text` split logic I think it should use `lines` method,
not `split('\n')`, the newline on Windows is `\r\n`.
Release Notes:
- N/A
---
When we use `window_handle` to draw WebView on Windows, this will crash
by:
This error caused by when used WebView2.
```
thread 'main' panicked at crates\gpui\src\app\async_context.rs:91:28:
already borrowed: BorrowMutError
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread 'main' panicked at library\core\src\panicking.rs:221:5:
panic in a function that cannot unwind
```
Try this https://github.com/tauri-apps/wry/pull/1383 on Windows can
replay the crash.
In fact, we had done [a similar fix around August last
year](https://github.com/huacnlee/zed/pull/6), but we used the unsafe
method to avoid crashes in that version, we felt that it was not a good
change, so we do not make PR.
Today @sunli829 thought about it again and changed the method. Now using
`try_borrow_mut` is similar to the previous `borrow_mut`.
691de6b4b3/crates/gpui/src/app.rs (L70-L78)
I have tested to start Zed by those changes, it is looks no problem.
Co-authored-by: Sunli <scott_s829@163.com>
This is a dumb first pass at a standard text example. We'll use this to
start digging in to some text/scale rendering issues.
There will be a ton of follow-up features to this, but starting simple.
Release Notes:
- N/A
Closes #ISSUE
Work around https://github.com/rust-lang/rust/issues/69343 in askpass
Release Notes:
- linux: Fixed an issue with askpass where the Zed binary path would be incorrect after an auto-update is installed
but not yet applied
Closes#22656
Part of #29144, this PR completely rewrites the key handling logic on
Windows, making it much more consistent with how things work on macOS.
However, one remaining issue is that on Windows, we should be using
`Ctrl+Shift+4` instead of `Ctrl+$`. That part is expected to be
addressed in #29144.
Release Notes:
- N/A
This glyphs field is usually larger than 8 elements, and SmallVec is not
efficient when it cannot store the value inline.
This change also adds precise glyphs run preallocation in some places
`ShapedRun` is constructed.
Release Notes:
- N/A
* Use cosmic_text `metadata` attr to write down the `FontId` from the
input run to avoid searching the list of fonts when laying out every
glyph.
* Instead of checking on every glyph if `postscript_name` is an emoji
font, just store `is_known_emoji_font`.
* Clarify why `font_id_for_cosmic_id` is used, and when its use is
valid.
Release Notes:
- N/A
See #27808. `font_id_for_cosmic_id` was another path updated
`loaded_fonts_store` but did not push to `features_store`. Solution is
just to have one `Vec` with fields rather than relying on the indices
matching up
Release Notes:
- N/A
Closes#30526.
This PR makes the CacheKey used by raster_bounds and rasterize_glyph the
same, as they had not used the same sub pixel shift previously. Fixing
this resolves both the alignment and text-rendering issues introduced in
`ddf8d07`.
Release Notes:
- Fixed text rendering issues on Linux.
Closes https://github.com/zed-industries/zed/issues/23386
This PR updates the scrollbar-component to account for padding present
in the parent container.
Since the linked issue was opened,
https://github.com/zed-industries/zed/pull/25288 improved the behaviour
so that the scrollbar does allow scrolling the entire container, however
the scrollbar thumb still does not go the entire way to the bottom. This
can be seen here:
https://github.com/user-attachments/assets/89204355-e6b8-428b-9fa9-bb614051b6fa
This happens because during layouting of the scrollbar, padding of the
parent container is not taken into account. The scrollbar thumb size is
calculated as if no padding was present.
With this change, padding is now included in the calculation, which
resolves the issue:
https://github.com/user-attachments/assets/1d4c62e0-4555-4332-a9ab-4e114684b4b3
The change here is to store the calculated content size during prepaint
_including_ padding and use this for layouting the scrollbar. This
ensures that the actual scroll max and the content size are always in
sync. Furthermore, the existing `TODO`-comment is also resolved, as we
now no longer look at the size of the last child but the actual parent
size instead.
This also removes an existing panic of the scrollbar-component in cases
where the content size was 0, which was previously not accounted for
(this never happened in practice so far, for example because of the
padding added here:
43712285bf/crates/editor/src/hover_popover.rs (L802-L809)
which prevented the container size from ever being 0).
---
Lastly, as I was wiring through the changes of the `content_size` I
noticed that some code was duplicated during the initial layouting as
well as in the click handlers. I refactored this in the second commit to
use `along` where possible as well as computing the new click offset in
one closure which can be passed to both event listeners. As always,
should any of these changes not be wanted, feel free to let me know and
I will revert these.
Looking forward to your feedback 😄
Release Notes:
- Fixed scrollbars sometimes not scrolling all the way to the bottom.
Fixes#15752.
- Updated `cosmic_text` to 0.14.0
- Made a basic implementation for setting font features.
#12176 is not fixed by this PR.
Release Notes:
- Added initial support for `font_features` on Linux
This is similar to the `block_mouse_down` method added in #20649 (which
has a very similar motivation), but is more comprehensive in stopping
mouse events. Since I want to cherry-pick this to the releases, keeping
this change just to the agent panel. In a follow-up will replace
existing use of `block_mouse_down` to instead use this.
Release Notes:
- N/A
- Adds a new smoke test for the use of the read_file tool by the agent
in an SSH project
- Fixes the SSH shutdown sequence to use a timer from the app's executor
instead of always using a real timer
- Changes the main executor loop for tests to advance the clock
automatically instead of panicking with `parked with nothing left to
run` when there is a delayed task
Release Notes:
- N/A
This pull request introduces a new tool for streaming edits. The
short-term goal is for this tool to replace the existing `EditFileTool`,
but we want to get this out the door as soon as possible so that we can
start testing it.
`StreamingEditFileTool` is mutually exclusive with `EditFileTool`. It
will be enabled by default for anyone who has the `agent-stream-edits`
feature flag, as well as people that set `assistant.stream_edits` to
`true` in their settings.
### Implementation
Streaming is achieved by requesting a completion while the `edit_file`
tool gets called. We invoke the model by taking the existing
conversation with the agent and appending a prompt specifically tailored
for editing. In that prompt, we ask the model to produce a stream of
`<old_text>`/`<new_text>` tags. As the model streams text in, we
incrementally parse it and start editing as soon as we can.
### Evals
Note that, as part of this pull request, I also defined some new evals
that I used to drive the behavior of the recursive LLM call. To run
them, use this command:
```bash
cargo test --package=assistant_tools --features eval -- eval_extract_handle_command_output
```
Or comment out the `#[cfg_attr(not(feature = "eval"), ignore)]` macro.
I recommend running them one at a time, because right now we don't
really have a way of orchestrating of all these evals. I think we should
invest into that effort once the new agent panel goes live.
Release Notes:
- N/A
---------
Co-authored-by: Nathan Sobo <nathan@zed.dev>
Co-authored-by: Bennet Bo Fenner <bennetbo@gmx.de>
Co-authored-by: Oleksiy Syvokon <oleksiy.syvokon@gmail.com>
