Z-2357
I've found a crate that handles both comments and trailing commas in
JSON. It is a fork of `serde_json`, but it is maintained & up-to-date.
Sadly RawValue seems to not play nicely with it; I've ran into
deserialisation issues around use of RawValue. For this PR I've migrated
to `Value` API.
Obviously this is just a point of discussion, not something I'd merge
straight away. There may be better solutions to this particular problem.
I've also noticed that `serde_json_lenient` does not handle trailing
commas after bindings array. I'm not sure how big of an issue that is.
Release Notes:
- Improved handling of trailing commas in settings files.
[#1322](https://github.com/zed-industries/community/issues/1322)
Previously, this was used because we didn't have access to the current
view and `EventContext` was an element-only abstraction. Now that the
`EventContext` wraps the current view's `ViewContext` we can simply check
for the view's focus and avoid querying ancestors.
During `layout`, we now pass a mutable reference to the element's
parent view. This is a recursive process that causes the view to
be removed from `AppContext` and then re-inserted back into it once
the layout is complete.
As such, querying parent views during `layout` does not work as such
views will have been removed from `AppContext` and not yet re-inserted
into it. This caused a bug in `KeystrokeLabel`, which used the `keystrokes_for_action`
method to query its ancestors to determine their type id and keymap context.
Now, any time a view notifies, we will cache its keymap context so that
we don't need to query the parent view during `layout`.
This is achieved by moving `available_actions` into `AsyncAppContext` (where
we know no view/window is on the stack) and `keystrokes_for_action` into `LayoutContext`
where we'll fetch the previous frame's ancestors and notify the current view if those
change after we perform a layout.
Previously, `debug_elements` was available on `WindowContext`. If that
method was called while having a borrow out to a view, it would panic because
the view would already have been borrowed.
By moving it to an `AsyncAppContext` we ensure the method can't be called while
a view is being used.
This avoids an invitation to hold strong view handles across async await
points, which is a common source of leaks.
Co-Authored-By: Nathan Sobo <nathan@zed.dev>
