In the old world, panel loading happened strictly before workspace
deserialization. Now it's inverted.
Fix this by storing on the dock the serialized state so they can restore
state as panels are loaded.
[[PR Description]]
Release Notes:
- Fixed Zed forgetting which panels were open on boot.
([#2406](https://github.com/zed-industries/community/issues/2406)).
In the old world, panel loading happened strictly before workspace
deserialization. Now it's inverted.
Fix this by storing on the dock the serialized state so they can restore
state as panels are loaded.
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
This uploads apples crash reports to our servers when telemetry is
enabled.
Rather than jumping via the website, it uploads to collab directly. (I'd
like
to update the panic handler to do this too to make it possible to work
on that end-to-end without zed.dev running).
Release Notes:
- Added reporting of crashes when telemetry is enabled
A sequence of events: Launch Zed -> Quit Zed -> Launch Zed would leave
you with a project panel in a a different state on each open (e.g. if it
is open on 1st one, 2nd run will have it closed). We were essentially
not tracking whether the deserialization took place.
Release Notes:
- Fixed project panel being toggled on/off on startup due to incorrect
tracking of serialization state (solves
https://github.com/zed-industries/community/issues/2406)
This essentially shaves off about 10% off of an incremental build after
project change and potentially more if you're changing stuff like
`welcome` that's very close to the `zed` crate in the dep graph. That's
because macro expansion takes place even in incremental builds it seems?
And zed (lib) + zed (bin) could take up to 4 seconds out of an
incremental build, which is a *lot* in a 10s build. In reality though it
shaves 1 second off of 5 seconds incremental 'welcome'/ 1s off of 10s
'project' builds.
Note that we had `assets` crate in the past (removed in #2575 /cc
@maxbrunsfeld), but this is a bit different, because `assets` is a
dependency of *just* zed and nothing else. We essentially cache macro
expansion results ourselves.
Release Notes:
- N/A
Currently when one runs `cargo build` twice without changing anything,
zed lib and binary are gonna get rebuilt every time. I checked out cargo
logs and it turns out we were querying wrong path to `.git/logs/HEAD` in
our build.rs, causing it to rerun on every build and thus marking zed
lib as dirty.
See logs (`CARGO_LOG=cargo::core::compiler::fingerprint=trace cargo
build`):
```
0.501173792s INFO cargo::core::compiler::fingerprint: fingerprint dirty for zed v0.120.0 (/Users/hiro/Projects/zed/crates/zed)/RunCustomBuild/TargetInner { ..: custom_build_target("build-script-build", "/Users/hiro/Projects/zed/crates/zed/build.rs", Edition2021) }
0.501180417s INFO cargo::core::compiler::fingerprint: dirty: FsStatusOutdated(StaleItem(MissingFile("/Users/hiro/Projects/zed/crates/zed/.git/logs/HEAD")))
```
The path to .git directory is relative to crates/zed and not to the
workspace's root.
/cc @maxbrunsfeld
Release Notes:
- N/A
The client sends events to our end point, and the endpoint is what determines what analytics database is used to store the data. The client should be generic and not mention the name of the service being proxied to through our server.
- `base_keymap` setting was not respected, now it is
- without a `~/.config/zed/keymap.json` file, we would fail to load the
*default* keymap
Co-authored-by: Marshall <marshall@zed.dev>
