- it seems like layer.drawable_size() is 0,0 in metal_renderer.rs:189
- we set this in two places:
- in response to a CALayerDelegate setFrameSize: event
- in response to a CALayerDelegate viewDidChangeBackingProperties:
event.
- it looks like if we don't set it in either of these cases we get a
different failure mode: the view is zoomed just wrong.
- That said, I can reproduce the screenshot if .scale_factor() returns
0.
- This might happen if [nativeWindow screen] is nil, which happens when
the window is off screen.
- possible that zed started with offscreen window?
- I would expect that viewDidChangeBackingProperties would fire when
that changed.
- potential fix: default to 2.0
Release Notes:
- Fixed Zed occasionally rendering blank on laungh
([#2422](https://github.com/zed-industries/community/issues/2422)).
Add support for mapping `jk` to escape in vim mode.
This changes the behaviour of the keymatches when there are pending
matches.
Before: Even if there was a pending match, any complete matches would be
triggered and the pending state lost.
After: If there is a pending match, any complete matches are delayed by
1s, or until more keys are typed.
Release Notes:
- Added support for mapping `jk` in vim mode
([#2378](https://github.com/zed-industries/community/issues/2378)),
([#176](https://github.com/zed-industries/community/issues/176))
Part of `was_top_layer` was checking if a opaque level starts with the
current stacking order, but now that each entry in the order has an id,
those comparison checks were failing as every entry generated is now
unique
I'll admit I'm still a little fuzzy on the specific reasons for this
function to be defined as it is so I'd appreciate another set of eyes
Release Notes:
- N/A
With this pull request, we're introducing a `ZED_MEASUREMENTS` variable
which is used by the `measure` function to print to stderr how long it
took to execute a given closure. This is used right now to measure frame
time when a new frame is requested. This data can be plotted as a
histogram via `script/histogram`.
Here's a workflow I typically use:
- Run `export ZED_MEASUREMENTS=1`
- Checkout a commit that you want to measure the performance of
- Run zed in release mode and use it for 5-10 seconds
- Copy the printed measurements into a file, say `version-a`
- Checkout another commit that you want to measure the performance of
- Run zed in release mode and use it for 5-10 seconds
- Copy the printed measurements into a file, say `version-b`
- Run `script/histogram version-a version-b` (note that you can supply
however many files you want)
Release Notes:
- N/A
I'm sure @iamnbutler can do a better job here, this is just hacky, but
the size of the icon when doing `Cmd+tab` has been bugging me, so I
thought I'd resize them quickly to the dimensions the Stable/Preview
icons have.
Release Notes:
- N/A
During the doc parties, I've sometimes struggled with how and where to
describe the high level intention behind various APIs that are available
in GPUI. Fortunately, rust doc has a tool for this: Module level
documentation. However, writing this kind of documentation for the
`WindowContext` is difficult, as it bundles up the nice, high level GPUI
APIs for entity management and view rendering, with all of the low level
imperative APIs that `Element`s use to draw to the screen. Splitting
these apart into an `ElementContext`, which contains a `WindowContext`,
gives us a way to corral the element systems into their own API and
module, allowing us to document the Element system on it's own terms,
and enforce the correct usage of our APIs, and helps people who are
exploring our APIs through autocomplete to not be overloaded with
non-applicable methods.
Release Notes:
- N/A
Before this change if you had a matching binding and a pending key,
the matching binding happened unconditionally.
Now we will wait a second before triggering that binding to give you
time to complete the action.
<img width="447" alt="SCR-20240121-ofhg"
src="https://github.com/zed-industries/zed/assets/19867440/7fe13a74-45c7-43ec-a5e8-5127bc285b32">
In this screenshot, the first two messages were sent back-to-back, but
the third message was sent nearly two hours later. Coalescing the
messages doesn't feel right after a certain period of time, as it gives
misleading timestamps on messages. Discord has this feature, but I'm not
sure what the value they use is. I've set the threshold to 5 minutes for
now.
<img width="480" alt="SCR-20240121-oghs"
src="https://github.com/zed-industries/zed/assets/19867440/ee1cfe36-7c13-4072-9f66-93e2de6542f1">
Release Notes:
- Improved the grouping of chat messages from same user. Grouping now
only occurs if the user sends multiple messages, in succession, within a
specified duration of time.
A user was not seeing the "yesterday" text in their chat timestamps for
messages right before the midnight boundary
Release Notes:
- Fixed bugs in formatting of chat timestamps
This matches Neovim behaviour by setting the mode to `Normal` when using
search while in visual mode.
Release Notes:
- Fixed Vim mode not switching to normal mode from visual mode when
using search (`/`) while in visual mode.
