This PR makes Clippy deny all warnings across the workspace.
We now enumerate all of the rules that have violations and temporarily
allow them, with the goal being to drive the list down over time.
On Windows we don't yet use `--deny warnings`, as the Windows build
still has some warnings.
Release Notes:
- N/A
Associates every window with its own refresh event. Removes the use of
X11 present.
Alternative to #8592.
Instead of doing the rendering on idle and then involving a hack for
polling X11 events, this PR just tries to do the rendering inside the
main loop. This guarantees that we continue to poll for events after the
draw, and not get screwed by the driver talking to X11 via the same file
descriptor.
Release Notes:
- N/A
This practice makes it difficult to locate todo!s in my code when I'm
working. Let's take out the bang if we want to keep doing this.
Release Notes:
- N/A
This reverts commit 0cebf68306.
Although this thing is very cool, it is a top source of crashes.
Example crash:
```
Segmentation fault: 11 on thread 26
objc_retain +16
invocation function for block in Overlay::onCommandBufferCommit(id<MTLCommandBuffer>) +60
MTLDispatchListApply +52
```
Release Notes:
- Removed "Toggle Graphics Profiler" as it crashes too much.
This PR unifies the event loop code for Wayland and X11. On Wayland,
blocking dispatch is now used. On X11, the invisible window is no longer
needed.
Release Notes:
- N/A
---------
Co-authored-by: Dzmitry Malyshau <kvark@fastmail.com>
Co-authored-by: Tadeo Kondrak <me@tadeo.ca>
Co-authored-by: Mikayla Maki <mikayla@zed.dev>
Co-authored-by: julia <julia@zed.dev>
This uses bounds checking alone to determine hover state to avoid
flicker. It's a short-term solution because the rendering is incorrect.
We think this is better than flickering though and buys us some time as
we work on a more robust solution overall.
Release Notes:
- Fixed flickering when hovering.
---------
Co-authored-by: Nathan <nathan@zed.dev>
If the list is large (size > overdraw + available height) the
`all_rendered` check was preventing the list from returning an inferred
size. Theoretically we can now report heights which are actually too
small (because not all items were affected during layout), this can be
manually adjusted using the overdraw parameter. In this case its fine
because the picker is inside a max_height which should never be more
then the overdraw we specify (1000 px), and the list will shrink down
either way when the request_measured_layout callback is called again.
Release Notes:
- Fixed flashing of recent projects list when there were a lot of
projects in the list
([#8364](https://github.com/zed-industries/zed/issues/8364#issuecomment-1962849393)).
This is a follow up to #7945. The current behaviour reads the locale and
infers from that which type of time format should be used (12 hour/24
hour).
However, in macOS you can override this behaviour, e.g. you can use
en_US locale but still use the 24 hour clock format (Can be customized
under Settings > General > Date & Format > 24-hour time). You can even
customize the date format.
This PR uses the macOS specific `CFDateFormatter` API, which outputs
time format strings, that respect those settings.
Partially fixes#7956 (as its not implemented for linux)
Release Notes:
- Added localization support for all macOS specific date and time
configurations in chat
With this change, interaction with Zed is actually real-time and usable
🚀🎉
The gist of it is - trying to process all of the input events before
rendering anything.
Release Notes:
- N/A
**Note**: this can be further improved in a follow-up.
Currently, once the input and runnables are processed, we'd try to draw
+ render a frame.
Presentation starts with acquiring a new frame. We currently have FIFO
presentation method, so acquiring a frame is blocking on that swapchain
image to become available. As the result, presentation takes around 16
ms, most of which is just busy wait.
Ideally, we'd be able to process more input in this time frame, instead.
**Note2**: it's a bit laggy in Debug for me, but that's just because of
the extra-long `draw` times, which is unrelated to rendering (or
platform support, for the matter). I'm curious how come on MacOS the
`draw()` times in Debug are more modest.
[Profiling](https://crates.io/crates/profiling) crate allows easy
integration with various profiler tools. The best thing is - annotations
compile to nothing unless you request a specific feature.
For example, I used this command to enable Tracy support:
```bash
cargo run --features profiling/profile-with-tracy
```
At the same time I had Tracy tool open and waiting for connection. It
gathered nice stats from the run:
Release Notes:
- N/A
Fix an issue where the `ime_key` is sometimes an empty string, and
pressing a keystroke replaces the selected text.
E.g. select some text, press `Escape`: selected text is deleted.
Release Notes:
- Added `workspace::SendKeystrokes` to enable mapping from one key to a
sequence of others
([#7033](https://github.com/zed-industries/zed/issues/7033)).
Improves #7033. Big thank you to @ConradIrwin who did most of the heavy
lifting on this one.
This PR allows the user to send multiple keystrokes via custom
keybinding. For example, the following keybinding would go down four
lines and then right four characters.
```json
[
{
"context": "Editor && VimControl && !VimWaiting && !menu",
"bindings": {
"g z": [
"workspace::SendKeystrokes",
"j j j j l l l l"
],
}
}
]
```
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
With `send_and_check_request` we'd be blocking both the main loop and
the caller. `send_request` is only going to be blocking on the main loop
when processing the request.
Release Notes:
- N/A
Based on a flamegraph from `perf`/`hotspot`, we are spending 40% of time
redrawing, another 40% of time downloading stuff (i.e. rust toolchain),
and the rest on text rendering, layout and such. This is with Vulkan
Validation (see https://github.com/zed-industries/zed/pull/8044).
I'm also wondering if it would be better with #7758, but regardless we
should have no problem rendering at 60-120 fps and processing user
input. More follow-ups are expected here.
This PR enables server side decorations on Wayland if possible. This is
stopgap solution, so that the window can be moved, resized and dragged
on Wayland sessions at all.
Since Wayland compositors can decide to force either mode (as in,
forcing server or client side decorations), this requires additional
handling in zed. Since zed doesn't provide any of that handling as of
now, as a temporary solution server side decorations are always
requested.
