Instead of a menagerie of macros for implementing `Action`, now there
are just two:
* `actions!(editor, [MoveLeft, MoveRight])`
* `#[derive(..., Action)]` with `#[action(namespace = editor)]`
In both contexts, `///` doc comments can be provided and will be used in
`JsonSchema`.
In both contexts, parameters can provided in `#[action(...)]`:
- `namespace = some_namespace` sets the namespace. In Zed this is
required.
- `name = "ActionName"` overrides the action's name. This must not
contain "::".
- `no_json` causes the `build` method to always error and
`action_json_schema` to return `None`
and allows actions not implement `serde::Serialize` and
`schemars::JsonSchema`.
- `no_register` skips registering the action. This is useful for
implementing the `Action` trait
while not supporting invocation by name or JSON deserialization.
- `deprecated_aliases = ["editor::SomeAction"]` specifies deprecated old
names for the action.
These action names should *not* correspond to any actions that are
registered. These old names
can then still be used to refer to invoke this action. In Zed, the
keymap JSON schema will
accept these old names and provide warnings.
- `deprecated = "Message about why this action is deprecation"`
specifies a deprecation message.
In Zed, the keymap JSON schema will cause this to be displayed as a
warning. This is a new feature.
Also makes the following changes since this seems like a good time to
make breaking changes:
* In `zed.rs` tests adds a test with an explicit list of namespaces. The
rationale for this is that there is otherwise no checking of `namespace
= ...` attributes.
* `Action::debug_name` renamed to `name_for_type`, since its only
difference with `name` was that it
* `Action::name` now returns `&'static str` instead of `&str` to match
the return of `name_for_type`. This makes the action trait more limited,
but the code was already assuming that `name_for_type` is the same as
`name`, and it requires `&'static`. So really this just makes the trait
harder to misuse.
* Various action reflection methods now use `&'static str` instead of
`SharedString`.
Release Notes:
- N/A
Implements a workaround which removes the `WS_EX_LAYERED` style from the
window right before closing it which seems to fix the window close
animation not playing.
Release Notes:
- N/A
Closes#29956
Unlike GNOME Keyring, KeePassXC locks individual secrets in addition to
the entire database when configured to ask for confirmation for access
requests by DBus clients. As such, before the secret is read it should
be unlocked by the client.
Tested against both KeePassXC and GNOME Keyring, and with this patch Zed
successfully logs in and fetches the API keys from the Secret Service.
Release Notes:
- Fixed KeePassXC integration via org.freedesktop.Secrets
This PR contains a set of changes for improving FreeBSD support (#15309,
#29550) and is a kind of follow up to the PR #20480 which added an
initial support for FreeBSD.
A summary of changes is as follows:
- Add some more freebsd conditionals which seem missing in the previous
PR.
- Implement `anonymous_fd()` and `current_path()` functions for FreeBSD.
- Improve detection of FreeBSD in telemetry and GPU detection.
- Temporarily disable LiveKit/WebRTC support to make build succeed.
- Remove support for flatpak since it is Linux-only packaging format.
Adding `RUSTFLAGS="-C link-dead-code"` does not seem necessary anymore.
It builds fine without the flag.
Known issues:
- Integrated terminal is painfully laggy and virtually unusable in my
environment. This might be specific to my setup.
- I cannot input Japanese using IME. When I type characters, they appear
on the screen. But when I hit return key, they disappears. Seems the
same issue as #15409.
My environment is MATE desktop on X11 on FreeBSD 14.2 on Intel Core
i5-7260U integrated graphics.
P.S. For those who might be interested, a work-in-progress FreeBSD port
and binary packages are available at
https://github.com/tagattie/FreeBSD-Zed
Release Notes:
- N/A
---------
Co-authored-by: Peter Tripp <peter@zed.dev>
Closes#25195
In Wayland, To create buffer size (`renderer.update_drawable_size`), we
convert logical pixels to device pixels by taking the scale factor into
account. Later, we also let the compositor know the logical pixels we
want to use for our app (`viewport.set_destination`). Then, the
compositor takes our buffer and tries to scale it to fit the viewport
size we provided. If this is accurate, we see perfect rendering. If our
buffer size is not accurate (off by 1px in this case), the compositor
scales our buffer to fit the viewport size. This causes blur.
To make sure we set correct buffer size for renderer as same as what
compositor is going to use, we needs to use rounding instead of truncate
when converting logical pixels to device pixels. It's not super clear
from docs, what exact algorithm it uses but it says it uses rounding and
seems to fix issue for me if we follow that for our buffer.
From https://wayland.app/protocols/fractional-scale-v1:
> If a surface has a surface-local size of 100 px by 50 px and wishes to
submit buffers with a scale of 1.5, then a buffer of 150px by 75 px
should be used and the wp_viewport destination rectangle should be 100
px by 50 px.
>
> For toplevel surfaces, the size is **rounded halfway away from zero**.
The rounding algorithm for subsurface position and size is not defined.
Tested on:
- [x] Gnome
- [x] KDE
- [ ] ~Sway~ (Need to investigate this more for Sway)
Release Notes:
- Fixed blurry rendering on Wayland when using fractional scaling for
Gnome and KDE.
Co-authored-by: Julia Ryan p1n3appl3@users.noreply.github.com
Co-authored-by: Antonio Scandurra me@as-cii.com
For me this is a panic that started occurring today in my use of Zed.
The repro is to type `ctrl-x` to start a pending key sequence and then
close the collab side panel with the mouse. The issue is that
dispatching the action based on pending keystrokes uses the same
`DispatchNodeId` as when the 1 second timer was started.
`DispatchNodeId` is not stable across frames. This also means that the
wrong `DispatchNodeId` can be used in the non-panicing case, potentially
causing the action to not occur.
The mystery here is why did this only start happening now in my use of
Zed, and why isn't it showing up in the panics dashboard / issue
reports.
Panic looks like
```
{
"thread": "main",
"payload": "index out of bounds: the len is 467 but the index is 1861",
"location_data": {
"file": "crates/gpui/src/key_dispatch.rs",
"line": 519
},
"backtrace": [
"zed::reliability::init_panic_hook::{{closure}}::he1d8257b19b16eec+155265758",
"std::panicking::rust_panic_with_hook::h33b18b24045abff4+128544307",
"std::panicking::begin_panic_handler::{{closure}}::hf8313cc2fd0126bc+128543530",
"std::sys::backtrace::__rust_end_short_backtrace::h57fe07c8aea5c98a+128537145",
"__rustc[95feac21a9532783]::rust_begin_unwind+128542669",
"core::panicking::panic_fmt::hd54fb667be51beea+9456688",
"core::panicking::panic_bounds_check::h1a9bf3d94de0fc80+9457170",
"gpui::key_dispatch::DispatchTree::dispatch_path::hce77d277881569bf+73992023",
"gpui::app::App::spawn::{{closure}}::hb1e79bbbdead3012+73687056",
"async_task::raw::RawTask<F,T,S,M>::run::hd13f66f99bb24bbd+70694231",
"<gpui::platform::linux::x11::client::X11Client as gpui::platform::linux::platform::LinuxClient>::run::h5a92ddaaf9a06dd1+74465138",
"gpui::platform::linux::platform::<impl gpui::platform::Platform for P>::run::hd19ac52b2d94268e+74064525",
"gpui::app::Application::run::hee83110c717a5af0+151862692",
"zed::main::hca7e2265584c4139+153307630",
"std::sys::backtrace::__rust_begin_short_backtrace::h2e04f4034c2d82c5+153146899",
"std::rt::lang_start::{{closure}}::h91cf1ca0eeae23ae+154454121",
"std::rt::lang_start_internal::h418648f91f5be3a1+128467809",
"main+153326748",
"__libc_start_call_main+25056432783818",
"__libc_start_main_impl+25056432784011",
"_start+12389486"
],
"app_version": "0.190.6",
"app_commit_sha": "9a2dcbbe24",
"release_channel": "stable",
"target": "x86_64-unknown-linux-gnu",
"os_name": "Linux X11",
"os_version": "ubuntu 24.04",
"architecture": "x86_64",
"panicked_on": 1750185799233,
"system_id": "abae7201-61fb-442b-922b-202071ae81c0",
"installation_id": "69a0fb9a-11a2-4065-ad8c-b281e68525ad",
"session_id": "bc5b5f2f-e4c3-44a8-948e-c0550a2e2ef2"
}
```
Release Notes:
- Fixed a rare panic / potential incorrect action dispatch when a
pending keysequence is applied after the 1 second timer elapsing.
Continuing this work from a while back in #21079, now greatly aided by
agent + sonnet 4. With this change, there are now only a few spots that
explicitly panic, though errors during initialization will panic.
Motivation was this recent user panic in `handle_event`, figured fixing
all this use of unwrap was a great use of the agent.
> called `Result::unwrap()` on an `Err` value: X11 GetProperty for
_NET_WM_STATE failed.
Release Notes:
- N/A
Closes#21700
Release Notes:
- Added caps lock support and show a warning if the user is entering an
SSH password with Caps Lock enabled
---------
Co-authored-by: Mikayla Maki <mikayla@zed.dev>
Co-authored-by: Mikayla Maki <mikayla.c.maki@gmail.com>
Co-authored-by: 张小白 <364772080@qq.com>
Most of the default icon sets on Ubuntu do not use the names that were
there. To fix, using the icon synonyms from the chromium source. This
will probably fix some of the linux mouse cursor issues tracked in
#26141
Also adds a note in the load failure logs mentioning that misconfigured
`XCURSOR_PATH` may be the issue. I ran into this because [the alacritty
snap incorrectly sets
XCURSOR_PATH](https://github.com/snapcrafters/alacritty/issues/21).
On X11 also adds:
* Caching of load errors to log once for missing cursor icons.
* Fallback on default cursor icon. This way if there was a transition
from a non-default icon to a missing icon it doesn't get stuck showing
the non-default icon.
Leaving release notes blank as I have other mouse cursor fixes and would
prefer to just have one entry in the release notes.
Release Notes:
- N/A
Closes#27384
I wrote #32771 before seeing #27384, and hoped that change would fix it.
It didn't because `XkbSelectNotify` wants a mask of which types of
`XkbMapNotify` to deliver, and otherwise won't send them.
I noticed quite a few events are sent just for remapping a single
keycode, so I updated the event loop to deduplicate these events (since
the handler does not attempt to apply them and instead just re-queries
keyboard info).
Also adds a missing call of `keyboard_layout_change` on `XkbMapNotify`
and `XkbNewKeyboardNotify`.
Release Notes:
- x11: Fixed handling of key remapping occurring while Zed is running
(e.g. xmodmap)
This adds handling of UnmapNotify / MapNotify / VisibilityNotify to
track whether windows are visible. When hidden, the refresh loop is
halted until visible again. Often these refreshes were just checking if
the window is dirty, but I believe it sometimes did a full re-render for
things that change without user interaction (cursor blink, animations).
This also changes handling of Expose events to set a flag indicating the
next refresh should have `require_presentation: true`.
Release Notes:
- x11: No longer refreshes windows that aren't visible.
Keyboard hot reloading was added in #15059, but also reloaded this on
MapNotify instead of XkbMapNotify, so it wasn't handling keymap change
events and was instead reloading when windows are mapped (typically when
they go from a minimized / other workspace state to being visible).
Release Notes:
- N/A
Release Notes:
- N/A
Just make a simple change to avoid crash.
```
thread 'main' panicked at library\std\src\time.rs:436:33:
overflow when subtracting duration from instant
stack backtrace:
0: std::panicking::begin_panic_handler
at /rustc/17067e9ac6d7ecb70e50f92c1944e545188d2359/library\std\src\panicking.rs:697
1: core::panicking::panic_fmt
at /rustc/17067e9ac6d7ecb70e50f92c1944e545188d2359/library\core\src\panicking.rs:75
2: core::panicking::panic_display
at /rustc/17067e9ac6d7ecb70e50f92c1944e545188d2359/library\core\src\panicking.rs:261
3: core::option::expect_failed
at /rustc/17067e9ac6d7ecb70e50f92c1944e545188d2359/library\core\src\option.rs:2024
4: core::option::Option::expect
at /rustc/17067e9ac6d7ecb70e50f92c1944e545188d2359/library\core\src\option.rs:933
5: std::time::impl$3::sub
at /rustc/17067e9ac6d7ecb70e50f92c1944e545188d2359/library\std\src\time.rs:436
6: data_table::Quote::random
at .\crates\gpui\examples\data_table.rs:54
```
Closes#32592
Follow-up to #31965
This PR fixes the cursor style flickering on Linux systems. The issue
arose since the window cursor style was not reused anymore for
subsequent frames after the changes in #31965. This works on MacOS for
hiding cursors, since they are hidden until the next mouse movement
occurs, which is not the case for other systems.
This PR re-adds this whilst keeping the fixes applied in #31965. We now
determine the first cursor style that is hovered and continue searching
for a cursor style that should be applied globally. If one to apply for
the whole window is found, we return that cursor style early instead.
Alternatively, we could store window cursor style request in a vector
similar to normal cursor styles. That would require more memory in
exchange for fewer checks which cursor style to apply. I preferred the
approach here, though, but can change this should the other method be
preferred.
CC @smitbarmase since you assigned yourself that issue.
Release Notes:
- Fixed an issue where the cursor would flicker whilst typing.
Closes#21860
Release Notes:
- Added `ch_width` and `ch_advance` function alongside their `em_*`
counterparts
- Use `ch_*` version to calculate gutter layouts
- Update a stale comment from changes in #31959
The ch units refer to the width of the number `0` whereas em is the
width of `m` and the actual font size (e.g. 16px means 16 px width of
`m`).
This change has no effect for monospaced fonts but can be drastic for
proportional ones as seen below for "Zed Plex Sans" with a
`"min_line_number_width" = 4`.
<img width="726" alt="Screenshot 2025-06-11 at 15 47 35"
src="https://github.com/user-attachments/assets/aa73f4d4-32bc-42cf-a9f6-7e25fee68c9a"
/>
These `if` condition checks were removed in #30828, and this PR adds
them back. This is especially important in the handling of
`WM_NCHITTEST`, where all the calculations are based on the assumption
that `hide_title_bar = true`.
Release Notes:
- N/A
This PR also introduces `Context::processor`, a sibling of
`Context::listener` that takes a strong pointer to entity and allows for
a return result.
Release Notes:
- N/A
Co-authored-by: Mikayla <mikayla@zed.dev>
Follow-up to #24797
This PR ensures some cursor styles do not change for draggable elements
during dragging. The linked PR covered this on the higher level for
draggable divs. However, e.g. the pane divider inbetween two editors is
not a draggable div and thus still has the issue that the cursor style
changes during dragging. This PR fixes this issue by setting the hitbox
to `None` in cases where the element is currently being dragged, which
ensures the cursor style is applied to the cursor no matter what during
dragging.
Namely, this change fixes this for
- non-div pane dividers
- minimap slider and the
- editor scrollbars
and implements it for the UI scrollbars (Notably, UI scrollbars do
already have `cursor_default` on their parent container but would not
keep this during dragging. I opted out on removing this from the parent
containers until #30194 or a similar PR is merged).
https://github.com/user-attachments/assets/f97859dd-5f1d-4449-ab92-c27f2d933c4a
Release Notes:
- N/A
Fixes: #29812Fixes: #22538
Co-Authored-By: <corentinhenry@gmail.com>
Release Notes:
- vim: Multi-key bindings in insert mode will now show the pending
keystroke in the buffer. For example if you have `jk` mapped to escape,
pressing `j` will immediately show a `j`.
Allows setting element as window control elements which consist of
`Drag`, `Close`, `Max`, or `Min`. This allows you to implement
dynamically sized elements that control the platform window, this is
used for areas such as the title bar. Currently only implemented for
Windows.
Release Notes:
- N/A
Release Notes:
- N/A
---
This change is used to solve the problem of not being able to respond
correctly in two-layer scrolling (in different directions). This is a
common practical requirement.
As in the example, in actual use, there may be a scene with a horizontal
scroll in a vertical scroll. Before the modification, if we scroll up
and down in the area that can scroll horizontally, it will not respond
(because it is blocked by the horizontal scroll layer).
## Before
https://github.com/user-attachments/assets/e8ea0118-52a5-44d8-b419-639d4b6c0793
## After
https://github.com/user-attachments/assets/aa14ddd7-5596-4dc5-9c6e-278aabdfef8e
----
This change may cause many side effects, causing some scrolling details
to be different from before, and more testing and analysis are needed.
I have tested some existing scenarios of Zed (such as opening the Branch
panel on the Editor and scrolling) and it seems to be correct (but it is
possible that I don’t know some interaction details). Here, the person
who added this line of code before needs to evaluate the original
purpose.
Fixes two things:
* ~3 months ago [in PR
#26420](https://github.com/zed-industries/zed/pull/26420/files#diff-33b58aa2da03d791c2c4761af6012851b7400e348922d64babe5fd48ac2a8e60)
`bindings_for_action` was changed to return bindings even when they are
shadowed (when the keystrokes would actually do something else).
* For edit prediction keybindings there was some odd behavior where
bindings for `edit_prediction_conflict` were taking precedence over
bindings for `edit_prediction` even when the `edit_prediction_conflict`
predicate didn't match. The workaround for this was #24812. The way it
worked was:
- List all bindings for the action
- For each binding, get the highest precedence binding with the same
input sequence
- If the highest precedence binding has the same action, include this
binding. This was the bug - this meant that if a binding in the keymap
has the same keystrokes and action it can incorrectly take display
precedence even if its context predicate does not pass.
- Fix is to check that the highest precedence binding is a full match.
To do this efficiently, it's based on an index within the keymap
bindings.
Also adds `highest_precedence_binding_*` variants which avoid the
inefficiency of building lists of bindings just to use the last.
Release Notes:
- Fixed display of keybindings to skip bindings that are shadowed by a
binding that uses the same keystrokes.
- Fixed display of `editor::AcceptEditPrediction` bindings to use the
normal precedence that prioritizes user bindings.
This PR improves key handling on Windows by moving the
`TranslateMessage` call from the message loop to after we handled
`WM_KEYDOWN`. This brings Windows behavior more in line with macOS and
gives us finer control over key events. As a result, Vim keybindings now
work properly even when an IME is active. The trade-off is that it might
introduce a slight delay in text input.
Release Notes:
- N/A
This brings back [linux(x11): Add support for pasting images from
clipboard · Pull Request
#29387](https://github.com/zed-industries/zed/pull/29387) while fixing
#30523 (which caused it to be reverted).
Commit message from that PR:
> Closes:
https://github.com/zed-industries/zed/pull/29177#issuecomment-2823359242
>
> Removes dependency on
[quininer/x11-clipboard](https://github.com/quininer/x11-clipboard) as
it is in [maintenance
mode](https://github.com/quininer/x11-clipboard/issues/19).
>
> X11 clipboard functionality is now built-in to GPUI which was
accomplished by stripping the non-x11-related code/abstractions from
[1Password/arboard](https://github.com/1Password/arboard) and extending
it to support all image formats already supported by GPUI on wayland and
macos.
>
> A benefit of switching over to the `arboard` implementation, is that
we now make an attempt to have an X11 "clipboard manager" (if available
- something the user has to setup themselves) save the contents of
clipboard (if the last copy operation was within Zed) so that the copied
contents can still be pasted once Zed has completely stopped.
Before the fix for reapply, it was iterating through the formats and
requesting conversion to each. Some clipboard providers just respond
with a different format rather than saying the format is unsupported.
The fix is to use this response if it matches a supported format. It
also now typically avoids this iteration by requesting the `TARGETS` and
taking the highest precedence supported target.
Closes#30523
Release Notes:
- Linux (X11): Restored the ability to paste images.
---------
Co-authored-by: Ben <ben@zed.dev>
Fix a segfault in CVDisplayLink
We see 1-2 crashes a day on macOS on the `CVDisplayLink` thread.
```
Segmentation fault: 11 on thread 9325960 (CVDisplayLink)
CoreVideo CVHWTime::reset()
CoreVideo CVXTime::reset()
CoreVideo CVDisplayLink::runIOThread()
libsystem_pthread.dylib _pthread_start
libsystem_pthread.dylib thread_start
```
With the help of the Zed AI, I dove into the crash report, which looks
like this:
```
Crashed Thread: 49 CVDisplayLink
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x00000000000001f6
Exception Codes: 0x0000000000000001, 0x00000000000001f6
Thread 49 Crashed:: CVDisplayLink
0 CoreVideo 0x18c1ed994 CVHWTime::reset() + 64
1 CoreVideo 0x18c1ee474 CVXTime::reset() + 52
2 CoreVideo 0x18c1ee198 CVDisplayLink::runIOThread() + 176
3 libsystem_pthread.dylib 0x18285ac0c _pthread_start + 136
4 libsystem_pthread.dylib 0x182855b80 thread_start + 8
Thread 49 crashed with ARM Thread State (64-bit):
x0: 0x0000000000000000 x1: 0x000000018c206e08 x2: 0x0000002c00001513 x3: 0x0001d4630002a433
x4: 0x00000e2100000000 x5: 0x0001d46300000000 x6: 0x000000000000002c x7: 0x0000000000000000
x8: 0x000000000000002e x9: 0x000000004d555458 x10: 0x0000000000000000 x11: 0x0000000000000000
x12: 0x0000000000000000 x13: 0x0000000000000000 x14: 0x0000000000000000 x15: 0x0000000000000000
x16: 0x0000000182856a9c x17: 0x00000001f19bc540 x18: 0x0000000000000000 x19: 0x0000600003c56ed8
x20: 0x000000000002a433 x21: 0x0000000000000000 x22: 0x0000000000000000 x23: 0x0000000000000000
x24: 0x0000000000000000 x25: 0x0000000000000000 x26: 0x0000000000000000 x27: 0x0000000000000000
x28: 0x0000000000000000 fp: 0x000000016b02ade0 lr: 0x000000018c1ed984
sp: 0x000000016b02adc0 pc: 0x000000018c1ed994 cpsr: 0x80001000
far: 0x00000000000001f6 esr: 0x92000006 (Data Abort) byte read Translation fault
Binary Images:
0x1828c9000 - 0x182e07fff com.apple.CoreFoundation (6.9) <df489a59-b4f6-32b8-9bb4-9b832960aa52> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
```
Using lldb to disassemble `CVHWTime::reset()` (and the AI to interpret
it), the crash is caused by dereferencing the pointer at the start of
the CVHWTime struct + 0x1c8. In this case the pointer has (the clearly
nonsense) value 0x2e (and 0x2e + 0x1c8 = 0x1f6, the failing address).
As to how this could happen...
Looking at the implementation of `CVDisplayLinkRelease`, it calls
straight into `CFRelease` on the main thread; and so it is not safe to
call `CVDisplayLinkRelease` concurrently with other threads that access
the CVDisplayLink. While we already stopped the display link, it turns
out that `CVDisplayLinkStop` just sets a flag on the struct to instruct
the io-thread to exit "soon", and returns immediately. That means we
don't know when the other thread will actually exit, and so we can't
safely call `CVDisplayLinkRelease`.
So, for now, we just leak these objects. They should be created
relatively infrequently (when the app is foregrounded/backgrounded), so
I don't think this is a huge problem.
Release Notes:
- Fix a rare crash on macOS when putting the app in the background.
Adds a validation step to docs preprocessing so that actions referenced
in docs are checked against the list of all registered actions in GPUI.
In order for this to work properly, all of the crates that register
actions had to be importable by the `docs_preprocessor` crate and
actually used (see [this
comment](ec16e70336 (diff-2674caf14ae6d70752ea60c7061232393d84e7f61a52915ace089c30a797a1c3))
for why this is challenging).
In order to accomplish this I have moved the entry point of zed into a
separate stub file named `zed_main.rs` so that `main.rs` is importable
by the `docs_preprocessor` crate, this is kind of gross, but ensures
that all actions that are registered in the application are registered
when checking them in `docs_preprocessor`. An alternative solution
suggested by @mikayla-maki was to separate out all our `::init()`
functions into a lib entry point in the `zed` crate that can be imported
instead, however, this turned out to be a far bigger refactor and is in
my opinion better to do in a follow up PR with significant testing to
ensure no regressions in behavior occur.
Release Notes:
- N/A
Modify the `replace_and_mark_text_in_range` method in the `Editor` to
keep the cursor at the start of the preedit range during IME
composition. Previously, the cursor would move to the end of the preedit
text with each update, causing the IME candidate box to shift (e.g.,
when typing pinyin with Fcitx5 on Wayland). This change ensures the
cursor and candidate box remain fixed until the composition is
committed, improving the IME experience.
Closes#21004
Release Notes:
- N/A
---------
Co-authored-by: Mikayla Maki <mikayla.c.maki@gmail.com>
Co-authored-by: 张小白 <364772080@qq.com>
Prep for https://github.com/zed-industries/zed/pull/32040
Currently, there’s no way to modify the cursor style of the active drag
state after dragging begins. However, there are scenarios where we might
want to change the cursor style, such as pressing a modifier key while
dragging. This PR introduces an API to update and read the current
active drag state cursor.
Release Notes:
- N/A
