Seems to be very similar to
https://github.com/zed-industries/zed/pull/28059
Edit: Updated the reproduction-steps as I missed something.
The method without a check currently causes my debug-builds to crash on
the regular if I:
- Run a debug build and open it fullscreen in a dedicated space on my
Mac.
- Work on any of the built-in languages (e.g. remove some content from
any `highlights.scm`)
- Reopen the workspace with the debug-build.
- Crash.
~~We might actually be able to revert the changes made in
https://github.com/zed-industries/zed/pull/21510 and just add the
null-check. Then again, I am not at all sure whether that would work.~~
See comment below.
Release Notes:
- N/A
Use the `NSOperatingSystemVersion` struct provided by the cocoa crate
instead of our own. Additionally we can directly use
`isOperatingSystemAtLeastVersion` instead of manually implementing
version comparison logic.
The `isOperatingSystemAtLeastVersion` instance method has been available
since MacOS 10.10, which released a decade ago.
Documentation for `isOperatingSystemAtLeastVersion `:
https://developer.apple.com/documentation/foundation/nsprocessinfo/1414876-isoperatingsystematleastversion
Release Notes:
- N/A
Reverts the error behavior introduced in #27558. Upper-case keys in
keybindings no longer generate errors, instead they are transformed into
`shift-{KEY}`
e.g. `ctrl-N` becomes `ctrl-shift-n`
The behavior introduced in #27558 where "special" keys such as function
keys, `control`, `shift`, etc. Are parsed case-insensitively is
preserved.
Release Notes:
- Improved how upper-case characters are handled in keybinds. "special"
keys such as the function keys, `control`, `shift`, etc. are now parsed
case-insensitively, so for example `F8`, `CTRL`, `SHIFT` are now
acceptable alternatives to `f8`, `ctrl`, and `shift` when declaring
keybindings. Additionally, upper-case (ascii) characters will now be
converted explicitly to `shift` + the lowercase version of the
character, to match the Vim behavior.
NOTE: Release notes above should replace the release notes from #27558
While building my own application using GPUI, I found that the `key_up`
event doesn't fire on Windows or macOS, with each platform failing for
different reasons. These events aren't used anywhere in Zed yet, so it
makes sense that the issue hasn't already been caught.
I don't have a Linux machine set up right now, so I don't know if these
events fire correctly on Linux or not.
---
Without this fix, a simple layout like the following:
```rust
div()
.on_key_down(cx.listener(|_, event, _, _| println!("Key down: {:?}", event)))
.on_key_up(cx.listener(|_, event, _, _| println!("Key up: {:?}", event)));
```
...would result in the following logs if the 'a' key was pressed:
```text
Key down: KeyDownEvent { keystroke: Keystroke { modifiers: Modifiers { control: false, alt: false, shift: false, platform: false, function: false }, key: "a", key_char: Some("a") }, is_held: false }
<eof>
```
With this fix, the `key_up` event fires correctly, resulting in the
following logs:
```text
Key down: KeyDownEvent { keystroke: Keystroke { modifiers: Modifiers { control: false, alt: false, shift: false, platform: false, function: false }, key: "a", key_char: Some("a") }, is_held: false }
Key up: KeyUpEvent { keystroke: Keystroke { modifiers: Modifiers { control: false, alt: false, shift: false, platform: false, function: false }, key: "a", key_char: None } }
<eof>
```
---
I've made the assumption that the `key_char` field shouldn't be set on
the `key_up` event since, unlike the `key_down` event, it's not an event
that may produce a character.
Happy to make any changes to this PR as required. If it would be
preferable to test this on Linux as well before it's merged, let me know
and I'll sort something out.
Hopefully this makes the experience of building new applications on GPUI
smoother, and potentially saves the Zed team some time if this event is
ever used in the future.
Release Notes:
- N/A
Swift bindings BEGONE
Release Notes:
- Switched from using the Swift LiveKit bindings, to the Rust bindings,
fixing https://github.com/zed-industries/zed/issues/9396, a crash when
leaving a collaboration session, and making Zed easier to build.
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
Co-authored-by: Michael Sloan <michael@zed.dev>
Workaround for users affected by #25899
Thanks to the work done by @kvark in
https://github.com/kvark/blade/pull/210, we have the ability to tell
Vulkan (through blade) a specific GPU to use.
This will hopefully allow some of the users affected by #25899 to use
Zed by allowing them to use a specific GPU, if the primary/default GPU
will not work
Release Notes:
- Added the ability to specify which GPU Zed uses on Linux by setting
the `ZED_DEVICE_ID` environment variable. You can obtain the device ID
of your GPU by running `lspci -nn | grep VGA` which will output each GPU
on one line like:
```
08:00.0 VGA compatible controller [0300]: NVIDIA Corporation GA104
[GeForce RTX 3070] [10de:2484] (rev a1)
````
where the device ID here is `2484`. This value is in hexadecimal, so to
force Zed to use this specific GPU you would set the environment
variable like so:
```
ZED_DEVICE_ID=0x2484
```
Make sure to export the variable if you choose to define it globally in
a `.bashrc` or similar
Closes#4461
Take 2 on https://github.com/zed-industries/zed/pull/25040.
Fixes panic caused due to using `setHiddenUntilMouseMoves` return type
to `set` cursor on macOS.
Release Notes:
- Now cursor hides when the user is typing in editor. It will stay
hidden until it is moved again. This behavior is `true` by default, and
can be configured with `hide_mouse_while_typing` in settings.
---------
Co-authored-by: Peter Tripp <peter@zed.dev>
Co-authored-by: Thomas Mickley-Doyle <thomas@zed.dev>
Co-authored-by: Agus <agus@zed.dev>
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
Co-authored-by: Agus Zubiaga <hi@aguz.me>
Co-authored-by: Angelk90 <angelo.k90@hotmail.it>
Related #14222
Release Notes:
- This PR updates `cosmic-text` dependency on `gpui` crate from `0.11.2`
to 0.13.2`. This decreases RAM usage zed depending on the amount of
monospace fonts installed on the system. On Arch Linux with `nerd-fonts`
package installed (which provides around 2000 monospaced fonts), it
decreases ram usage from ~800mb to around ~300mb.
- Updated `cosmic-text` to `0.13.2` on `gpui` crate
There apparently is some amdgpu/radv bug that rendering with
multisample anti-aliasing (MSAA) results in a crash when the bounds
of a triangle list exceed 1024px, which in Zed happens with the default
buffer font size when you select a line with more than 144 characters.
This crash has been reported as #26143.
This commit introduces a workaround: you can set the
ZED_PATH_SAMPLE_COUNT=0
environment variable to disable MSAA and the error message we print
when a GPU crash is encountered with radv now suggests trying this
environment
variable as a workaround and links the respective issue.
Sidenote: MSAA was introduced in
f08b1d78ec
so you didn't run into this driver bug with versions < 0.173.8.
Release Notes:
- Added a workaround for an AMD Linux driver bug that causes Zed to
crash when selecting long lines.
Closes#4640
About the support limit of Fn:
Mac F1-F35
Win F1-F24
Linux F1-F35
Terminal F1-F20
Release Notes:
- Improved support for extended keyboards on Mac (F20-F35)
Closes #ISSUE
[git: Use font size to determine pattern slash width
#26446](https://github.com/zed-industries/zed/pull/26446)
This PR only uses font size as the slant line width, and here it further
uses line height as the slant line interval control.
before

now

big line height

Release Notes:
- N/A *or* Added/Fixed/Improved ...
Take 2 on https://github.com/zed-industries/zed/pull/26600. Now, it
doesn't break remote development.
Instead of using it in `build_classes`, it's now used in the `open`
method while creating a window. I found similar usage in other places
over internet.
Release Notes:
- Fixed issue where Zed would show mac native tabs when opening new
fullscreen windows on macOS.
Closes#26534
Recently, we fixed a title bar transparency issue that only occurred on
macOS 15.3 and later. PR:
https://github.com/zed-industries/zed/pull/26403
However, this seems to have broken multi-window fullscreen behavior on
earlier macOS versions. This PR adds versioning so that the title bar
transparency fix only applies to macOS 15.3.0 and later.
No release notes, as this bug only exists on main right now.
Release Notes:
- N/A
Co-authored-by: MrSubidubi <dev@bahn.sh>
Closes#25483
Currently, macOS doesn't support showing multi-keystroke shortcuts in
menu items. We can use an attributed string to differentiate them, but
that breaks consistency with traditional shortcuts.
This PR removes the hack of concatenating the multi-keystroke shortcut
to the title, as it looked a bit janky.
Release Notes:
- N/A
Closes#23735
This PR fixes an issue where Zed shows a transparent title bar in
fullscreen mode on macOS instead of the default gray one.
When switching to fullscreen mode, we change the title bar appearance to
opaque. When exiting fullscreen mode, we check the existing
`appears_transparent` flag that we pass to gpui to decide whether to
change the title bar back to transparent or not.
Note: Regardless of the `appears_transparent` flag, gpui should always
show an opaque title bar in fullscreen mode to prevent a broken
appearance, as macOS always displays the title bar in fullscreen mode
upon mouse interaction.
https://github.com/user-attachments/assets/211fb185-239b-454e-ac7f-b93b25d33805
Release Notes:
- Fixed issue where Zed showed transparent titlebar in fullscreen mode
on macOS.
"secondary" means "cmd" on macOS and "ctrl" on not macOS.
Release Notes:
- Added a "secondary" meta key to the zed keystroke parser, which maps
to 'cmd' on macOS and 'ctrl' off of macOS
https://github.com/zed-industries/zed/pull/25752 with fixes on top
* Ensures no flickering happens for all modifiers `: false` case
* Dismisses the toggled state on focus out
* Reworks cache state so that "enabled" and "toggled by modifiers" are
different states with their own lifecycle
Release Notes:
- N/A
Closes#22821
It turns out that on Windows, the `Cancel` button should **always** have
a button ID of `2`. Even if the button label is something like "Don't
Cancel", when the user presses the `Esc` key, Windows will still report
that the button with ID `2` was pressed.
Release Notes:
- N/A
This reverts commit a8610fbd13.
I've been seeing some reports of segmentation faults that appear to
point to this change as the culprit.
Closes#25366.
Release Notes:
- Community: Reverted #25040, so remove the corresponding entry from the
release notes.
This is second part needed for #17819.
There is already binding in default bindings: `"menu":
"editor::OpenContextMenu",` (but won't work on windows without this
change)
Release Notes:
- Handle "menu" key in windows
Closes https://github.com/zed-industries/zed/issues/4461
This PR improves the coding experience by hiding the mouse while the
user is typing so it does not accidentally get in their way, making it
challenging to ready characters in the editor.
Release Notes:
- The following PR hides the cursor when the user is typing by adding a
new cursor style called `None`.
- Assuming the user does not move the mouse, it will stay hidden until
it is moved again.
https://github.com/user-attachments/assets/6ba9f2ee-b9f3-4595-81e4-e9d986da4a39
---------
Co-authored-by: Agus <agus@zed.dev>
Co-authored-by: Peter Tripp <peter@zed.dev>
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
Closes#24931
We've flipped back and forth at least once on whether the last or first
added keybinding should be shown in different contexts (See
[this](https://github.com/zed-industries/zed/issues/23621#issuecomment-2614061385)
as well as #23621 and the subsequent #23660)
This PR attempts to pick a side to stick with so that we are at least
consistent until #23660 is resolved and we have a way to determine which
keybinds to display in a manner that is both consistent and not
confusing
Release Notes:
- N/A
This reverts commit 9ef0501853 due to a
panic.
```
{
"thread": "main",
"payload": "9 is not a valid char boundary in path \"crates/…/LiveKitBridge/\"",
"location_data": {
"file": "crates/file_finder/src/file_finder.rs",
"line": 646
}
}
```
Release Notes:
- N/A
We begin a columnar selection when we drag the mouse while holding
`alt-shift`. This PR makes it possible to start the selection and then
turn it into columnar by pressing `alt-shift`.
Fixes#5372
Release Notes:
- Support switching to columnar selection by pressing `alt-shift` while
mouse is down
This PR makes progress on #7711 by identifying any common prefix of the
paths in the file finder's search results, and replacing the "interior"
of that prefix---every path segment but the first and last---with `...`,
when a heuristic indicates that the longest path would otherwise
overflow the modal.
The elision is not applied to any segment that contains a match for the
search query.
There may be more work to do on #7711 in the case of long result paths
that do not share a significant common prefix.
Release Notes:
- Improved display of long paths in the file finder modal
Co-authored-by: Max <max@zed.dev>
Closes#24744
and should also fix#17819
The change is split into two commits, first one adds F10 handling (it
needs to be handled inside `parse_syskeydown_msg_keystroke`, the second
one properly handles `Alt+Fn` combinations, this also needs to happen in
`parse_syskeydown_msg_keystroke` and is similar to a fragment inside
`parse_keydown_msg_keystroke`
Release Notes:
- Fixes F10 and Alt+Fn handling on windows
Closes#22666
This PR fixes the long wait time to open Zed (2 mins in my case) after
reloading on Linux.
This bug fix is funny:
1. We were using TCP for Zed instances to talk to each other. Reload was
broken here too due to TCP connections not being killed on time.
2. [#11488](https://github.com/zed-industries/zed/pull/11488) PR fixed
the TCP connection issue by adding a wait until it gets killed. I
suppose at that time, this wait time was small.
3. Later, we changed how Zed talks to each other in
[#11585](https://github.com/zed-industries/zed/pull/11585) by using
Datagram and removing TCP. The new approach simply uses a `.sock` file
and a file descriptor to check if some program is listening to it.
4. TCP check is now unnecessary, and it still wait for a long time (I
suppose, TIME_WAIT time, don't quote me on this), even though we don’t
use TCP anymore for this.
This PR just removes that unnecessary TCP wait.
Release Notes:
- Fixed issue where reload hangs for several minutes on Linux.
Supercedes #24561Closes#21059
Before this change we would skip saving multibuffers regardless of the
save intent. Now we correctly save them.
Along the way:
* Prompt to save when closing the last singleton copy of an item (even
if it's still open in a multibuffer).
* Update our file name prompt to pull out dirty project items from
multibuffers instead of counting multibuffers as untitled files.
* Fix our prompt test helpers to require passing the button name instead
of the index. A few tests were passing invalid responses to save
prompts.
* Refactor the code a bit to hopefully clarify it for the next bug.
Release Notes:
- Fixed edge-cases when closing multiple items including multibuffers.
Previously no prompt was generated when closing an item that was open in
a multibuffer, now you will be prompted.
- vim: Fix :wq in a multibuffer