Refactor the find_tab_group method to use the question mark operator for
cleaner error handling, replacing the explicit if-else pattern with a
more concise chained approach.
Release Notes:
- N/A
Signed-off-by: Xiaobo Liu <cppcoffee@gmail.com>
### Problem
On Windows, the right Alt key was not working in keybindings (e.g.,
`Ctrl+Right Alt+B`), while the left Alt key worked correctly. This was
due to overly aggressive AltGr detection that treated any `right Alt +
left Ctrl` combination as AltGr, even on US keyboards where AltGr
doesn't exist.
### Root Cause
Windows internally represents AltGr (Alt Graph) as `right Alt + left
Ctrl` pressed simultaneously. The previous implementation always
excluded this combination from being treated as regular modifier keys to
support international keyboards. However, this broke keybindings using
right Alt on US/UK keyboards where users expect right Alt to behave
identically to left Alt.
### Solution
Implemented keyboard layout-aware AltGr detection:
1. Added `uses_altgr()` method to `WindowsKeyboardLayout` that checks if
the current keyboard layout is known to use AltGr (German, French,
Spanish, Polish, etc.)
2. Modified `current_modifiers()` to only apply AltGr special handling
when the keyboard layout actually uses it
3. Added explicit checking for both `VK_LMENU` and `VK_RMENU` instead of
relying solely on the generic `VK_MENU`
### Behavior
- **US/UK keyboards**: Right Alt now works identically to left Alt in
keybindings. `Ctrl+Right Alt+B` triggers the same action as `Ctrl+Left
Alt+B`
- **International keyboards** (German, French, Spanish, etc.): AltGr
continues to work correctly for typing special characters and doesn't
trigger keybindings
- **All keyboards**: Both Alt keys are detected symmetrically, matching
the behavior of left/right Windows keys
### Testing
Manually tested on Windows with US keyboard layout:
- `Ctrl+Left Alt+B` triggers keybinding
- `Ctrl+Right Alt+B` triggers keybinding
- Both Alt keys work independently in keybindings
Release Notes:
- Fixed Right Alt key not working in keybindings on Windows
Close#35715
Release Notes:
- Fixed to wrap long URLs in editor.
<img width="836" height="740" alt="image"
src="https://github.com/user-attachments/assets/635ce792-5f19-4c76-b131-0d270d09b103"
/>
I remember when I was working on CJK line wrapping support in the early
days, I considered making `\` a line wrapping character, but for some
reason it was on the list of characters that were not allowed to wrap.
In reference to VS Code, it looks like `&`, `/`, `?` should wrap, so I
removed all of them.
---------
Co-authored-by: Mikayla Maki <mikayla@zed.dev>
This is a follow-up PR to
https://github.com/zed-industries/zed/pull/39609, and attempts to
address hidden status bar items still contributing to the layout and
creating extra spacing.

- 203cbd634bfb1489b8afa4952d9594615a956b77 Adds a `.none()` method to
the `gpui::Styled` helper trait, so that status items can set their
display type to none inside their `render` method.
- 249f06e3de63b0ab32814f20e7105d8e2b642f02 Applies `.none()` to all the
status items.
- ~~499f564906c88336608c81615b11ebc9ab43d832~~ At first I was adding an
`is_visible` method to the `StatusBarView` trait, which would be used to
skip status bar items which would just render an empty div anyway, but I
felt duplicating the conditions for hiding the buttons between the
status items `is_visible` and `render` methods could be an attraction
for bugs, so I tried to find another approach. This commit contains
those changes, reverted immediately (if the `is_visible` approach is
preferred I can bring it back!)
- f37cb75f0519ceea1f3e1cc4f97087a5cb34b0fd (bonus!) Adds a condition to
the vim mode indicator to avoid a leading space when there are no
pending keys.
Release Notes:
- N/A
This caused issues with #40172, as it made Zed execute and block on tad
few more background tasks. Parker is ~cheap to create, hence we should
be ok to just create it at the time it is needed.
Release Notes:
- N/A
---------
Co-authored-by: Cole Miller <cole@zed.dev>
Closes#40359
We were segfaulting when opening a UTF-8 file starting with a byte order
mark due to a mismatch in our UTF-16 indexing calculations caused by
Core Foundations `replace_str` stripping the BOM internally. This PR
fixes the crash by replacing one of our manual calculations by calling
the Core Foundations API to get the length of a string.
Release Notes:
- Fixed a crash on macOS when opening a file that starts with a UTF-8
byte order mark (BOM).
Co-authored-by: HactarCE <6060305+HactarCE@users.noreply.github.com>
`TaskDialogIndirect` may return `IDCANCEL` when the user quits the
dialog via escape or alt+f4, so we need to account for that.
Fixes ZED-25H
Release Notes:
- Fixed panic when hitting escape in dialogs on windows
Release Notes:
- N/A
---
- Set `.SystemUIFont` as the GPUI default font.
- Add `Arial` to font fallback list.
- Add `Adwaita Sans` to default fallback list for Gnome.
- Move `Ubuntu` font to front of Gnome to make sure Ubuntu System takes
priority over `Ubuntu` font.
Our application get some crash report:
```
panicked at /Users/admin/.cargo/git/checkouts/zed-a70e2ad075855582/f1db3b4/crates/gpui/src/text_system.rs:150:9:
failed to resolve font 'Helvetica' or any of the fallbacks: Zed Plex Mono, Helvetica, Segoe UI, Cantarell, Ubuntu, Noto Sans, DejaVu Sans
```
This change to add `Arial` to fallback list, this font was included in
macOS and Windows.
Ref link (search "Arial"):
> Mac OS X (now known as [macOS](https://en.wikipedia.org/wiki/MacOS))
was the first Mac OS version to include Arial;
> https://en.wikipedia.org/wiki/Arial
- macOS Sequoia: https://support.apple.com/en-us/120414
- Windows 10:
https://learn.microsoft.com/en-us/typography/fonts/windows_10_font_list
- Gnome: https://developer.gnome.org/hig/guidelines/typography.html
This PR improves the rendering performance of the Settings UI window by
using `gpui::list` to render only the visible contents of a settings
page, instead of rendering the full content of a page. This fixes a lag
that the editor page has in debug builds.
I also added a new field `measuring_behavior` to `ListState` that has
`Visible` and `Measured` variances. `Visible` only measures and caches
the bounds of visible items plus the overdraw pixel offset. `Measure`
will cache all items’ bounds on the first layout phase, which fixes
problems with the scrollbar size/position being miscalculated.
Release Notes:
- N/A
---------
Co-authored-by: Mikayla Maki <mikayla@zed.dev>
Co-authored-by: Ben Kunkle <ben@zed.dev>
This reverts commit f1db1f3a3c.
This seems to have affected the vertical positioning of text that
doesn't contain emojis in a way that was unintended.
Release Notes:
- N/A
Closes#36934
I'm still experiencing bugs with the
`DCompositionWaitForCompositorClock` API. Let's back out the support for
now until the fixes are identified and widely available.
`DwmFlush` does various things that aren't just waiting for VSync, so
it's not ideal, but it's not bad enough that it's worth a bigger
refactor right now.
Release Notes:
- N/A
This applies the same fix as #39886 for Windows.
Previously we were using `GetLineMetrics` to determine the ascent and
descent values for each line. It seems like this has the same behavior
as `GetTypographicBounds` on macOS, which is to return the minimum
ascent and descent for the current state of the `TextLayout` object.
This causes the ascent/descent to be unstable when adding or removing an
emoji because a font fallback is triggered when an emoji is present on
the line.
The issue is fixed by switching to `font.GetMetrics` to get the ascent
and descent, which should always return stable values for the main font,
instead of changing when there's a fallback. This also should support
situations where we have multiple explicit fonts on the same line,
although that probably can't be triggered in Zed right now.
Release Notes:
- windows: Fixed a vertical shift in text layout when inserting or
removing an emoji.
Co-authored-by: Bennet Bo Fenner <bennetbo@gmx.de>
This relands https://github.com/zed-industries/zed/pull/37175 as
https://github.com/zed-industries/zed/pull/39886 fixed the jiggling
issue.
Currently when we render text with differing styles adjacently we might
form a ligature between the text, causing the ligature forming
characters to take on one of the two styles. This can especially become
confusing when a ligature is formed between actual text and inlay hints.
Annoyingly, the only ways to prevent this with core text is to either
render each run separately, or to insert a zero-width non-joiner to
force core text to break the ligatures apart, as it otherwise will merge
subsequent font runs of the same fonts.
We currently do layouting on a per line basis and it is unlikely we want
to change that as it would incur a lot of complexity and annoyances to
merge things back into a line, so this goes with the other approach of
inserting ZWNJ characters instead.
Note that neither linux nor windows seem to currently render ligatures,
so this only concerns macOS rendering at the moment.
Closes https://github.com/zed-industries/zed/issues/23194
Release Notes:
- Fixed ligatures forming between real text and inlay hints on macOS
Rendering breaks when both an element and its parent have opacity set.
The following code reproduces the issue:
```rust
struct Repro;
impl Render for Repro {
fn render(&mut self, _window: &mut Window, _cx: &mut Context<Self>) -> impl IntoElement {
fn make_box(bg: impl Into<Fill>) -> impl IntoElement {
div().size_8().bg(bg).hover(|style| style.opacity(0.5))
}
div()
.flex()
.items_center()
.justify_center()
.size(px(500.0))
.hover(|style| style.opacity(0.5))
.child(make_box(gpui::red()))
.child(make_box(gpui::green()))
.child(make_box(gpui::blue()))
}
}
```
Before (broken behavior):
https://github.com/user-attachments/assets/2c5c1e31-88b2-4f39-81f8-40060e3fe958
The child element resets its parent and siblings' opacity, which is an
unexpected behavior.
After (fixed behavior):
https://github.com/user-attachments/assets/48527033-b06f-4737-b6c3-0ee3d133f138
Release Notes:
- Fixed an issue where nested opacity is rendered incorrectly.
Closes#39263
Release Notes:
- N/A
from
https://github.com/zed-industries/zed/issues/39263#issuecomment-3358220988
>
> > If you replace that code with
> >
> > let adapter: IDXGIAdapter1 = unsafe {
> > dxgi_factory.EnumAdapters(adapter_index)
> > }?.cast()?;
> >
> > does it not select the right GPU?
>
> @reflectronic That does seem to select the active gpu for me, meaning
whichever GPU is currently connected. This is a much simpler solution
than the one I have here
(https://github.com/zed-industries/zed/pull/39264 - updated) and while
I'm sure I could imagine someone wanting to choose their GPU to render
Zed on, that may not be something that the application really needs to
support.
>
> I have a branch with just this as the only change that I can push to
that PR if the simpler solution is preferred.
>
> ```rust
> let adapter: IDXGIAdapter1 = unsafe {
> dxgi_factory.EnumAdapters(adapter_index)?.cast()?
> };
> ```
Closes #ISSUE
This allows new windows like the Rules library or the Settings UI window
to appear floating on window managers like hyprland:
https://github.com/user-attachments/assets/628db7f9-4459-4601-85f1-789923831182
Left is with `WindowKind::Floating` and right is with
`WindowKind::Normal`
Release Notes:
- Added support for floating windows on x11 and wayland
This PR makes selecting a sub-entry in the settings UI nav bar scroll to
that section in the settings page. It also updates the selected
sub-entry when scrolling through a settings page to match what a user is
viewing on the page.
I also added a new helper method to `ScrollHandle` type called
`scroll_to_top_of_item` that scrolls until an item is the top element
visible.
Release Notes:
- N/A
The previous modifier detection treated `AltGr` presses as `Ctrl+Alt`,
which broke entering characters produced by AltGr. For example, on a
Hungarian layout `{` is typed with `AltGr+B`; our code saw that as
`Ctrl+Alt+B` and the keybind took precedence, so the character couldn’t
be entered.
On Windows, AltGr isn’t a first-class modifier. It’s emulated as a
combination of `Right Alt (VK_RMENU)` plus a synthetic `Left Ctrl
(VK_LCONTROL)` press. When users press AltGr, `GetKeyState` reports both
Ctrl and Alt as down, which makes AltGr indistinguishable from a real
`Ctrl+Alt` chord if we only look at aggregate modifier state.
Fix: detect the AltGr pattern by checking `VK_RMENU && VK_LCONTROL`.
When that pattern is present, treat it as text-entry intent and suppress
`control` and `alt` in `current_modifiers()`. This prevents
AltGr-produced characters from colliding with `Ctrl+Alt` keybinds while
keeping other modifiers intact.
Limitation: there is no Windows API to tell whether the active layout
actually has AltGr. As a result, on non-AltGr layouts (e.g. US),
pressing `Right Alt + Left Ctrl` will be interpreted as AltGr and will
not trigger `Ctrl+Alt` keybinds. This is an acceptable trade-off to
ensure AltGr layouts can reliably enter characters; users can still
invoke `Ctrl+Alt` keybinds using `Left Alt` or by choosing bindings that
avoid common AltGr pairs.
I based this on https://github.com/zed-industries/zed/pull/36115 after
trying other different approaches, but this one is a bit more specific.
Does this approach make sense, or is slightly breaking US input in favor
of fixing international input a no-go? I think the benefit - being able
to type certain characters _at all_ - outweighs the shortcomings.
Otherwise, there's a way to detect if the keyboard layout uses AltGr or
not, but it's quite hacky, and involves reading the registry to find the
current layout dll's name, opening that dll, manually declaring struct
layouts that it uses, then parsing out the AltGr flag from a function
call result. I don't think that's worth it, but if needed, I can give
that a shot, let me know.
Release Notes:
- windows: Fixed handling of AltGr to avoid keybinds preventing
character input
Reverts zed-industries/zed#39581
This has done its job uncovering incorrect constructions of the
highlight ranges pretty fast. Reverting this to prevent this from
spilling into preview until I can fix the call sites next week
Prior we only logged the crate in `log_err`, which is not too helpful.
We now assemble the module path from the file system path.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
This PR adds the numeric stepper component to the settings ui and
implements some settings that rely on this component as well.
I also switched {buffer/ui}_font_weight to the `gpui::FontWeight` type
and added a manual implementation of the Schemars trait. This allows Zed
to send min, max, and default information to the JSON LSP when a user is
manually editing the settings file.
The numeric stepper elements added to the settings ui are below:
- ui font size
- ui font weight
- Buffer font size
- Buffer font weight
- Scroll sensitivity
- Fast scroll sensitivity
- Vertical scroll margin
- Horizontal scroll margin
- Inline blame padding
- Inline blame delay
- Inline blame min column
- Unnecessary code fade
- Tab Size
- Hover popover delay
Release Notes:
- N/A
This is the first step to allowing users to type into a numeric stepper
to set its value. This PR makes the numeric stepper take in a generic
type `T` where T: `NumericStepperType`
```rust
pub trait NumericStepperType:
Display
+ Add<Output = Self>
+ Sub<Output = Self>
+ Copy
+ Clone
+ Sized
+ PartialOrd
+ FromStr
+ 'static
{
fn default_format(value: &Self) -> String {
format!("{}", value)
}
fn default_step() -> Self;
fn large_step() -> Self;
fn small_step() -> Self;
fn min_value() -> Self;
fn max_value() -> Self;
}
```
This allows setting of step sizes and min/max values as well as making
the component easier to use.
cc @danilo-leal
Release Notes:
- N/A
---------
Co-authored-by: Mikayla Maki <mikayla.c.maki@gmail.com>
Co-authored-by: Gaauwe Rombouts <mail@grombouts.nl>
Closes#5355
Release Notes:
- Fixed rendering glitches with files with more than 16 million lines
(that occured due to floating number rounding errors).
---------
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
Fixes titlebar double-click behavior to properly handle the macOS system
setting when "Do Nothing" is selected in System Settings > Desktop &
Dock > "Double-click a window's title bar to".
Closes https://github.com/zed-industries/zed/issues/39102
Release Notes:
- Fixed macOS Do Nothing window double click setting not being
respected.