Previously, we wouldn't generate any `TabEdit` when the tab size
changed, causing coordinate spaces in `WrapMap` and `BlockMap` to
become outdated.
This commit generates a synthetic edit that covers the entire `TabMap`
to ensure layers above are synchronized.
This new field allows blocks to specify how they want to be laid out:
- If `Fixed` they can take up all the width they want and they will impact
the scroll width of the editor. This is useful for diagnostic messages and
allows scrolling the editor further to the right to visualize the entire message.
- If `Flex` they can extend all the way to the scroll width without impacting it
any further. This is useful for the rename editor that we insert as a block
decoration when hitting `F2`.
- If `Sticky`, they will be as wide as the editor element and won't participate
in the horizontal scrolling of the editor. This is useful for headers in general,
where we want e.g. the filename and the jump button to always be visible
independently of how much the user has scrolled to the right.
Previously, we would accept edits containing out-of-order ranges. When
generating such ranges in our randomized tests, many invariants started
breaking causing e.g. undo/redo to misbehave and operation application
to panic.
In theory, we should never pass inverted ranges, but this commit changes
the above functions to swap the start and the end when that occurs to avoid
breaking the entire system and panicking.
Previously, some of those properties such the font weight, style and color
would be mandatory: when the theme didn't specify them, Zed would use a default
value during deserialization. This meant that those default properties would
unconditionally override the base text style, causing a rendering bug when
combining syntax highlights with diagnostic styles.
This commit fixes that by making `HighlightStyle`s more additive: each property
can be set independently and only the properties that theme specifies get
overridden in the base text style.
This allows us to drop the context *after* we ran all futures to
completion and that's crucial otherwise we'll never drop entities
and/or flush effects.
We use chunks a lot to transform points and sync the various display maps,
and always querying tree-sitter or the LSP diagnostics in those cases is
unnecessarily expensive.
Change Chunks to contain highlight ids instead of actual highlight
styles. Retrieve the actual highlight style from the theme in the
editor element layer.
This is to set us up to perform syntax highlighting in other code
paths where the theme is not available.
When multiple saves occur, we can have multiple start events followed by multiple end events. We don't want to update our project diagnostics view until all pending progress is finished.
Co-Authored-By: Antonio Scandurra <me@as-cii.com>
This allows us to respect the bias on anchors we use to create excerpt headers so that they always remain above any content inserted at the start of an excerpt.
