Digging into ZED-7G6 ("buffer snapshot not found for excerpt boundary",
171 events) revealed some bugs in the implementation of multibuffer
anchors that landed in #52364. Specifically:
- In the presence of multibuffer excerpt changes, it was possible for
two anchors to satisfy `a1 < a2` but `a1.to_offset() > a2.to_offset()`.
This happened in particular when a `PathKey` was reused for two
different buffers at different times, and could cause crashes in code
that sorted anchors by `cmp` and expected the resulting offsets to be
sorted.
- Changes of diff base and normal buffer edits could cause two anchors
to sort `a1 < a2` against one snapshot and `a2 < a1` against a later
snapshot. This could also cause crashes in downstream code that
(reasonably) expected anchors to have a stable ordering.
This PR adds a property test asserting that multibuffer anchor ordering
is stable over time and consistent at every moment in time with the
ordering obtained from resolving the anchors, and fixes the bugs in
anchor resolution and comparison that are revealed by that test. It also
includes tests downstream for specific cases that previously crashed.
Closes ZED-7G6
Release Notes:
- Fixed a crash that could occur when inlay hints were present while a
multibuffer replaced the contents of a file, such as a diff view whose
base changed.
- Fixed crashes that could occur when a file's contents were replaced in
a multibuffer (such as a diff view refreshing) while highlights, inlay
hints, or other positions still referenced the old contents.
---------
Co-authored-by: Cole Miller <cole@zed.dev>
Co-authored-by: zed-zippy[bot] <234243425+zed-zippy[bot]@users.noreply.github.com>
[## Context
Fixes a bug where the Bookmarks tab, opened via `editor: view
bookmarks`, showed a stale snapshot and had to be reopened to display
bookmarks added or removed while it was open.
Closes#56268
`view_bookmarks` built a one-time multibuffer and never subscribed to
`BookmarkStore`. The store also calls `cx.notify()` while resolving
serialized bookmarks into anchors, even though that bookkeeping does not
represent a user-visible bookmark change. Observing all notifications
would therefore feed resolution notifications back into the refresh
mechanism and cause redundant cancellation and requeue work. The store
now emits a dedicated `BookmarkStoreEvent::BookmarksChanged` from
bookmark mutation paths, while `resolve_all` deliberately does not emit
it.
Refresh state lives on a `BookmarksView` entity that holds the tab's
multibuffer. Split editors already share that multibuffer, so they share
the view as well. Each store event drives one reconciliation regardless
of how many split editors display it. The view remains alive as long as
any split retains it, so closing the original tab does not stop the
remaining split from refreshing.
Each refresh reconciles excerpts per path instead of rebuilding the
multibuffer: `set_excerpts_for_path` updates files that still contain
bookmarks, while `remove_excerpts` removes files whose final bookmark
was deleted. This follows the per-path reconciliation pattern used by
project diff views.
`view_bookmarks` creates the tab synchronously and populates it
asynchronously, following the existing patterns in
`ProjectDiagnosticsEditor::deploy` and
`ProjectSearchView::existing_or_new_search`. Repeated invocations focus
the existing Bookmarks tab instead of opening duplicates.
Video of the manual test:
[Screencast from 2026-05-11
02-03-38.webm](https://github.com/user-attachments/assets/8ac97245-09ff-4a79-9634-20cb8dfbb7eb)
## How to Review
**`crates/project/src/bookmark_store.rs`**
Adds `BookmarkStoreEvent::BookmarksChanged`, emitted from bookmark
mutation paths such as toggle, label edit, file rename or deletion,
clear, and deserialization, but not from anchor resolution. It also adds
`BookmarkStore::is_empty`.
**`crates/editor/src/bookmarks.rs`**
Adds `BookmarksView`, which holds the multibuffer, store subscription,
and in-flight refresh task. It reconciles excerpts and emits
`BookmarksViewEvent::Populated(ranges)` for per-editor highlights and
cursor placement. It also caches the latest populated ranges and replays
them when an editor attaches, allowing a split created after population
to display bookmark highlights immediately.
**`crates/editor/src/editor.rs`**
Adds the shared `bookmark_view`, a per-editor subscription to its
population events, and `bookmark_initial_selection_pending` for initial
cursor placement. `Editor::clone` attaches the split to the shared view
instead of creating another store subscription and refresh task.
**`crates/editor/src/editor_tests.rs`**
Adds five tests covering automatic addition and removal across multiple
files, removal of a file's path after its final bookmark is deleted,
initial cursor placement, a bookmark change racing initial population,
splitting while population is pending, cached highlights in a
late-attaching split, and continued refreshing after the original tab
releases its view handle.
## Self-Review Checklist
- [x] I've reviewed my own diff for quality, security, and reliability
- [ ] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the UI/UX checklist
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- Fixed Bookmarks tab not updating when bookmarks are added or removed
while the tab is open](https://github.com/zed-industries/zed/pull/56363)
---------
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
Closes https://github.com/zed-industries/zed/issues/9318
Most of the diff is tests.
Notable behavior changes during this mode, compared to current mode:
* unsaved changes in multi buffer won't spawn any "save or not" pop-ups
during typing — submitting the query still does it, as before.
Unsaved files will stay so after being sorted out on typing: we cannot
save them by default as file-less buffers need a save modal; Zed should
already be able to persist and restore such changes on restart.
* gutter may jump during search, if new excerpts with large line numbers
appear during query input — yet it would not shrink back to avoid
excessive flickering and rewraps
Release Notes:
- Enabled project search on type by default (use `{ "search": {
"search_on_type": false } }` to restore the previous behavior)
Local benchmark shows this speeds it up by at least 30% and is
definitely more reasonable to have like this than compared to iterating
over a list for every given char.
Release Notes:
- N/A
`RawSemanticTokens` says tokens later in the list override earlier ones
on overlap, but there's no list to be later in — the tokens are stored
in a `HashMap<LanguageServerId, _>` and the sort that flattens them keys
only on `range.start`:
https://github.com/zed-industries/zed/blob/1c2a643cde2345ff7beca0178aee617b1651e561/crates/project/src/lsp_store/semantic_tokens.rs#L702-L709https://github.com/zed-industries/zed/blob/1c2a643cde2345ff7beca0178aee617b1651e561/crates/editor/src/semantic_tokens.rs#L312-L314
`sort_by` is stable, so two servers' tokens at the same position keep
whatever order the map iteration gave them, and which one wins changes
between sessions.
You hit this any time two servers tokenize the same range. In my case a
server that highlights an embedded query inside a string literal renders
fine, then loses the range to svelte-language-server once that
refreshes. Setting `languages.Svelte.language_servers` doesn't help,
since that isn't what decides it.
Breaking ties by `server_id` makes it deterministic.
`SemanticTokenHighlight` already carries the id and `LanguageServerId`
is `Ord`, so it's just the tiebreak.
Worth noting the servers do arrive as an ordered `Vec` from
`language_server_ids_for_buffer` and that order is dropped when they go
into the `HashMap`. Sorting by id gets determinism but not that original
order; if preserving it is what was intended I'm happy to submit a PR
for that functionality instead.
Release Notes:
- Fixed semantic token highlighting being applied unpredictably when
more than one language server provides tokens for the same range.
Closes ZED-AKV
Closes ZED-ANB
Follow-up to https://github.com/zed-industries/zed/pull/61153
The original PR mixed up the coordinate spaces, and the newly added
methods used buffer rows (as the existing code did before that PR), but
the new code uses `FoldMap` which expects a tab row instead of the
buffer one.
Release Notes:
- Fixed a panic when selections are added by tab-expanded column
BlockMap::sync unwrapped the transform cursor for every edit, assuming
each edit's old.start lands strictly inside the old transform tree. The
companion (split-diff) branch of sync can compose an edit anchored at
the trailing boundary of the old transforms, leaving the cursor past the
end of the tree and aborting the process on the None unwrap. Only bind
the transform when there are rows preceding the edit.
Fixes ZED-9V4.
Closes FR-113
Release Notes:
- N/A or Added/Fixed/Improved ...
Closes https://github.com/zed-industries/zed/issues/57053
Decided to be on a safest side and made only the code lens' blocks to
hide in folds: let me know if that's not desired and we should hide all
blocks (e.g. ctrl-enter for inline assist block is also not hiding and
looks odd).
Ran `ITERATIONS=100000 OPERATIONS=10 cargo test --profile release-fast
-p editor --lib display_map::tests::test_random_display_map --
--nocapture` and it passes successfully.
`SEED=770 OPERATIONS=50 cargo test --profile release-fast -p editor
--lib display_map::tests::test_random_display_map` seems to fail even on
`main`
Before:
<img width="392" height="155" alt="before"
src="https://github.com/user-attachments/assets/44d1a500-7512-49de-a9bd-2837c33353a9"
/>
After:
<img width="338" height="159" alt="after"
src="https://github.com/user-attachments/assets/671791d8-a443-4ca2-abb2-8049fe8910a7"
/>
Release Notes:
- Fixed code lens not hiding for folded regions
layout_word_diff_highlights converted each visible word diff to display
points via isomorphic_display_point_ranges_for_buffer_range, which walks
the inlay/fold/tab/wrap/block trees from the root on every call. With
many word diffs on screen this re-walks the same trees repeatedly each
frame.
Add a DisplayPointConverter that holds a forward-only cursor for each
display-map layer (mirroring the cursor reuse already done in
BlockMap::sync) so consecutive conversions amortize to near-constant
work. New forward cursors BufferOffsetToInlayPointCursor and
BlockPointCursor back the inlay and block layers; the fold/tab/wrap
layers reuse existing cursors. Each cursor gains a cheap reset() that
delegates to the underlying SumTree cursor; the converter resets its
cursors if an input range starts before the previous one ended, so it
stays correct for overlapping inputs (e.g. the base and buffer word
diffs of an inline modified hunk).
layout_word_diff_highlights now sorts the visible word diffs and feeds
them through a single converter.
isomorphic_display_point_ranges_for_buffer_range is reimplemented on top
of the converter to keep one code path.
Release Notes:
- Improved scrolling performance in diff views containing large hunks
Early draft for #32051 (multi-cursor editing is very slow, and basically
hangs at high cursor counts). Opening it early like @Anthony-Eid
suggested so we can agree on direction before I go further.
## Root cause
Typing with a cursor on every line is mostly O(N)-per-keystroke work
spread across a few places. I profiled it with `sample` and per-phase
timers around `handle_input`. At 1000 cursors (~24ms before this PR):
the post-edit display-map sync is ~11.8ms, the CRDT edit
(`apply_local_edit`) ~3.7ms, resolving all N selections plus the
per-cursor input loop ~3.5ms, the post-edit selection round-trip ~2.6ms,
and `change_selections` plus transact machinery ~2.4ms. The display sync
re-runs per-edit `SumTree` work through every layer even when nothing
transforms (the plain-text case), and selections get re-resolved through
the full display round-trip several times per keystroke.
## What this does
- Display fast paths: `InlayMap::sync` (no inlays) and
`WrapMap::interpolate` (no soft-wrap) skip the O(edits) transform-tree
rebuild and return the passthrough snapshot, gated so a pending inlay
splice or existing wraps still take the slow path.
- Selection fast path: when nothing collapses buffer content
(`!has_folds() && !has_replacement_blocks()`), resolve `Anchor` to
`Point` to `Offset` batched and skip the per-selection display
round-trip (the `todo(lw)`).
- Render and autoscroll resolve only the first/last/newest selections
instead of all N per frame.
- A parameterized `Multi-cursor input/cursors/{1000,10000,100000}`
benchmark.
## Results
- Typing (`handle_input`): ~2.1x faster (24ms to 11.7ms at 1k).
- Type plus two word-deletes (criterion): 29% faster (89.9 to 63.8ms) at
1k, 37% (959 to 606ms) at 10k.
- Post-edit display sync alone: 11.8 to 3.8ms at 1k, 133 to 45ms at 10k.
All `editor` (759), `display_map` (67), `multi_buffer` (58), and `text`
(36) tests pass, and `./script/clippy` is clean.
## Direction
This is ~2x, and I can get the current architecture to roughly 3.5-4.5x
with a few more safe changes (hoisting the per-cursor
language/editability checks, cheaper snapshot clones). Genuine VS Code
numbers (~1-2us/cursor) aren't reachable while the buffer is a CRDT rope
of fragments with anchor selections and a 5-layer transform stack. That
would need a plain-offset cursor model and/or decoupling display layout
from the edit path, which is a bigger effort I'd want to design with
you. One thing I'd need your call on: `set_active_selections` sends an
`UpdateSelections` collab op every keystroke (building N anchors); can
that be debounced to transaction end, or do presence/follow-mode
features rely on per-keystroke cursor broadcast?
Release Notes:
- editor: Improved multi cursor editing performance
---------
Co-authored-by: Anthony Eid <anthony@zed.dev>
I came across this while tackling another block map sync issue.
When a block is anchored past the point where its line soft wraps,
inserting or removing it invalidated the wrong range of rows. Inserting
such a block alone could silently not show it, and removing it could
leave the block on screen.
To reproduce:
```sh
SEED=113 ITERATIONS=1 cargo test -p editor test_random_blocks
```
Release Notes:
- Fixed inline assistant prompt sometimes not appearing, or lingering
after dismissal, when that line was soft-wrapped.
Both cloning and dropping of these has quite a bit of overhead (despite
them being snapshots), so avoid where possible, especially in display
map syncing
Release Notes:
- N/A or Added/Fixed/Improved ...
This change gets rid of the tree traversal overhead by batching the
anchor resolution
> Create highlight endpoints/text_highlights/100
> time: [298.43 µs 298.55 µs 298.69 µs]
> Create highlight endpoints/text_highlights/100
> time: [40.347 µs 40.386 µs 40.427 µs]
> change: [-86.492% -86.481% -86.471%] (p = 0.00 < 0.05)
> Performance has improved.
This is especially important given that `CustomHighlightsChunks::seek`
tends to get called a lot, which re-creates highlight endpoints a lot.
Release Notes:
- N/A or Added/Fixed/Improved ...
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Closes #ISSUE
Release Notes:
- N/A
Fixes a bug in the split diff spacer calculation when a patch group
starts mid-row, sometimes causing extra spacers to be inserted.
`spacer_blocks` already explicitly handles the case where `first_point`
isn't at the start of `edit_for_first_point.old`, but the `while let
Some(source_point) = source_points.next()` loop that follows implicitly
assumes that `source_point` is at the start of `current_range`, which in
turn seems to be based on the assumption that `current_range` starts at
the beginning of a row. As it turns out, `current_range` isn't
guaranteed to start at the beginning of a row, which can sometimes lead
to incorrect spacer blocks being inserted.
This addresses that by moving the existing `if
edit_for_first_point.old.start < first_point` logic into the loop body
as `if current_edit.old.start < current_boundary` in order to handle any
non-row-aligned patch groups, not just the first one.
Here's an example of how this bug could manifest:
https://github.com/user-attachments/assets/1d3a5b4c-e4ad-4d87-804b-c4390d25f408
After:
https://github.com/user-attachments/assets/b15acc62-33fe-4154-82e5-5cdf1806ffa7
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- Fixed incorrect spacer blocks sometimes appearing in the split diff
view when editing the file.
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- Fixed a panic when using the split diff view.
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Closes#50212
There are two unreasonable coupling account for this issue, the coupling
of `use_tree_sitter` with `languge_aware` in
https://github.com/zed-industries/zed/blob/ca8bd8681c123b995b495a79d760bc0d88220fd0/crates/editor/src/element.rs#L3820-L3822
and the coupling of `language_aware` with `diagnostics` in
https://github.com/zed-industries/zed/blob/ca8bd8681c123b995b495a79d760bc0d88220fd0/crates/language/src/buffer.rs#L3736-L3746
Because of these couplings, when the editor stops using Tree-sitter
highlighting when `"semantic_tokens"` set to `"full"`, it also
accidentally stops fetching diagnostic information. This is why error
and warning underlines disappear.
I’ve fixed this by adding a separate `use_tree_sitter` parameter to
`highlighted_chunks`. This way, we can keep `language_aware` true to get
the diagnostic data we need, but still decide whether or not to apply
Tree-sitter highlights. I chose to fix this at the `highlighted_chunks`
level because I’m worried that changing the logic in the deeper layers
of the DisplayMap or Buffer might have too many side effects that are
hard to predict. This approach feels like a safer way to solve the
problem.
Release Notes:
- Fixed a bug where diagnostic underlines disappeared when
"semantic_tokens" set to "full"
---------
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
It's possible to create a multibuffer anchor that points into a specific
excerpted buffer (so not min/max), but whose main buffer `text::Anchor`
isn't contained in any of the excerpts for that buffer. When summarizing
such an anchor, we map it to the multibuffer position of the start of
the next excerpt after where the anchor "should" appear. Or at least,
that's the intention, but it turned out we had some bugs in
`summary_for_anchor` and `summaries_for_anchors` that caused them to
return bizarre summaries for these anchors. This PR fixes that and also
updates `test_random_multibuffer` to actually test
`MultiBufferSnapshot::summary_for_anchor` against a reference
implementation, including for out-of-bounds anchors.
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- N/A
---------
Co-authored-by: Anthony <anthony@zed.dev>
Co-authored-by: Max <max@zed.dev>
Co-authored-by: Anthony Eid <hello@anthonyeid.me>
TODO:
- [x] merge main
- [x] nonshrinking `set_excerpts_for_path`
- [x] Test-drive potential problem areas in the app
- [x] prepare cloud side
- [x] test collaboration
- [ ] docstrings
- [ ] ???
## Context
### Background
Currently, a multibuffer consists of an arbitrary list of
anchor-delimited excerpts from individual buffers. Excerpt ranges for a
fixed buffer are permitted to overlap, and can appear in any order in
the multibuffer, possibly separated by excerpts from other buffers.
However, in practice all code that constructs multibuffers does so using
the APIs defined in the `path_key` submodule of the `multi_buffer` crate
(`set_excerpts_for_path` etc.) If you only use these APIs, the resulting
multibuffer will maintain the following invariants:
- All excerpts for the same buffer appear contiguously in the
multibuffer
- Excerpts for the same buffer cannot overlap
- Excerpts for the same buffer appear in order
- The placement of the excerpts for a specific buffer in the multibuffer
are determined by the `PathKey` passed to `set_excerpts_for_path`. There
is exactly one `PathKey` per buffer in the multibuffer
### Purpose of this PR
This PR changes the multibuffer so that the invariants maintained by the
`path_key` APIs *always* hold. It's no longer possible to construct a
multibuffer with overlapping excerpts, etc. The APIs that permitted
this, like `insert_excerpts_with_ids_after`, have been removed in favor
of the `path_key` suite.
The main upshot of this is that given a `text::Anchor` and a
multibuffer, it's possible to efficiently figure out the unique excerpt
that includes that anchor, if any:
```
impl MultiBufferSnapshot {
fn buffer_anchor_to_anchor(&self, anchor: text::Anchor) -> Option<multi_buffer::Anchor>;
}
```
And in the other direction, given a `multi_buffer::Anchor`, we can look
at its `text::Anchor` to locate the excerpt that contains it. That means
we don't need an `ExcerptId` to create or resolve
`multi_buffer::Anchor`, and in fact we can delete `ExcerptId` entirely,
so that excerpts no longer have any identity outside their
`Range<text::Anchor>`.
There are a large number of changes to `editor` and other downstream
crates as a result of removing `ExcerptId` and multibuffer APIs that
assumed it.
### Other changes
There are some other improvements that are not immediate consequences of
that big change, but helped make it smoother. Notably:
- The `buffer_id` field of `text::Anchor` is no longer optional.
`text::Anchor::{MIN, MAX}` have been removed in favor of
`min_for_buffer`, etc.
- `multi_buffer::Anchor` is now a three-variant enum (inlined slightly):
```
enum Anchor {
Min,
Excerpt {
text_anchor: text::Anchor,
path_key_index: PathKeyIndex,
diff_base_anchor: Option<text::Anchor>,
},
Max,
}
```
That means it's no longer possible to unconditionally access the
`text_anchor` field, which is good because most of the places that were
doing that were buggy for min/max! Instead, we have a new API that
correctly resolves min/max to the start of the first excerpt or the end
of the last excerpt:
```
impl MultiBufferSnapshot {
fn anchor_to_buffer_anchor(&self, anchor: multi_buffer::Anchor) -> Option<text::Anchor>;
}
```
- `MultiBufferExcerpt` has been removed in favor of a new
`map_excerpt_ranges` API directly on `MultiBufferSnapshot`.
## Self-Review Checklist
<!-- Check before requesting review: -->
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- N/A
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
Co-authored-by: Jakub Konka <kubkon@jakubkonka.com>
Co-authored-by: Conrad <conrad@zed.dev>
Self-Review Checklist:
- [ ] I've reviewed my own diff for quality, security, and reliability
- [ ] Unsafe blocks (if any) have justifying comments
- [ ] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [ ] Tests cover the new/changed behavior
- [ ] Performance impact has been considered and is acceptable
Closes #ISSUE
Release Notes:
- N/A
In `BlockMap::sync`, blocks within an edited region are sorted and
processed sequentially. Each block placement computes
`rows_before_block` by subtracting `new_transforms.summary().input_rows`
from the block's target position. The `Near`/`Below` cases have a guard
that skips the block if the target is already behind the current
progress, but `Above` and `Replace` were missing this guard.
When a `Replace` block (tie_break 0) is processed before an `Above`
block (tie_break 1) at the same or overlapping position, the `Replace`
block consumes multiple input rows, advancing `input_rows` past the
`Above` block's position. The subsequent `position - input_rows`
subtraction underflows on `u32`, producing a huge `RowDelta` that wraps
`wrap_row_end` past `wrap_row_start`, creating an inverted range that
propagates through the display map layers and panics as `begin <= end
(47 <= 0)` in a rope chunk slice.
Add underflow guards to `Above` and `Replace`, matching the existing
pattern in `Near`/`Below`.
Release Notes:
- Fixed a source of underflowing subtractions causing spurious panics
Release Notes:
- Fixed multiple language servers applying to the same buffer
overwriting each others inlay hints
- Fixed multiple language servers applying to the same multibuffer
discarding each others inlay hints
- Fixed a bug that caused some inlay hints to sometimes duplicate
Paving the way to remove `ExcerptId`. Done in this PR:
- Unshipped the stack trace view
- Get rid of `push_excerpts`
- Get rid of some callers of `remove_excerpts`
We still need to remove some calls to `remove_excerpts` and other APIs,
especially in `randomly_edit_excerpts` and collaboration.
Release Notes:
- The stack trace multibuffer view has been removed.
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
These tend to be very often mutated while we don't really need the
subtree sharing of TreeMaps, so replacing them here is generally
cheaper.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Co-authored by: John Tur <jtur@zed.dev>
fixes ZED-57B
Before you mark this PR as ready for review, make sure that you have:
- [ ] Added a solid test coverage and/or screenshots from doing manual
testing
- [ ] Done a self-review taking into account security and performance
aspects
- [ ] Aligned any UI changes with the [UI
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
Release Notes:
- Fixed a (rare) panic when a fold was created immediately following a
tab character
For inverted diff APIs like `hunks_intersecting_base_text_range`, we
need a snapshot of the main buffer to use as context to compare hunk
anchors, convert anchors to points, etc. Previously, we were always
using a snapshot of the main buffer at the time when the diff was
calculated. This worked well for the hunks of the primary `BufferDiff`,
but it's not valid when the diff also has a secondary set of hunks,
because those hunks are recalculated on their own schedule--so it's
possible for the hunks of the secondary diff to contain anchors that are
newer than the original buffer snapshot that was taken at the time the
primary diff hunks were last calculated. This caused a panic when using
these anchors with the original buffer snapshot.
This PR fixes the issue by using the same approach for inverted diffs as
for non-inverted diffs at the multibuffer level: we take a snapshot of
the main buffer at the time when we snapshot the diff state (including
the diff itself), guaranteeing that that snapshot will be new enough to
resolve all the anchors included in both the primary diff and the
secondary diff.
Closes ZED-54J
Release Notes:
- Fixed a panic that could occur when using the branch diff in split
view mode.
---------
Co-authored-by: Antonio Scandurra <me@as-cii.com>
Every yield will cause the background task to get rescheduled causing
additional thread/context switching, so doing so for every wrapped row
is a bit excessive
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Replaces a bunch of `impl FnMut` parameters with `&mut dyn FnMut` for
functions where this is the sole generic parameter.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Currently, the next chunk is generated by traversing all characters of
the current folded chunk until a tab is found. Since we already have
bitmasks for characters and tabs, we can also propagate the newlines
bitmap from the rope and use it to make this computation O(1) in all
cases.
I haven’t run benchmarks yet.
Release Notes:
- N/A
- Defer syncing block maps from `set_companion`, eliminating some
redundant recomputations
- Emit one large multibuffer edit from `set_show_deleted_hunks` instead
of many small edits, to avoid bad case for block map
This cuts hangs roughly in half when toggling between views in a large
diff (1000 commits from the chromium repository).
<!-- Before you mark this PR as ready for review, make sure that you
have:
- [ ] Added a solid test coverage and/or screenshots from doing manual
testing
- [ ] Done a self-review taking into account security and performance
aspects
- [ ] Aligned any UI changes with the [UI
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
-->
Release Notes:
- Improved performance with large diffs when toggling between diff
views.
---------
Co-authored-by: Jakub Konka <kubkon@jakubkonka.com>
Co-authored-by: Lukas Wirth <lukas@zed.dev>
We had a call to `BlockMap::unfold_intersecting` that ended up
recomputing the entire block map for the RHS _without_ spacers, only to
throw it away in favor of the version with spacers a few lines down. Now
we only sync each block map once in `set_companion`.
Release Notes:
- Improved performance when toggling from the unified diff to the split
diff.
Co-authored-by: Jakub <jakub@zed.dev>
Co-authored-by: Cameron McLoughlin <cameron.studdstreet@gmail.com>
- [x] Tests or screenshots needed?
- [ ] Code Reviewed
- [x] Manual QA
Release Notes:
- Fixed misalignment of lines in the split diff when using inlay hints.
Release Notes:
- Fixed inlay hints being rendered as new inserted words in word based
diff highlighting
---------
Co-authored-by: Zed Zippy <234243425+zed-zippy[bot]@users.noreply.github.com>
- Ensure that both sides are passed the appropriate companion data to
preserve spacers when syncing
- Remove companion handling in codepaths related to range folding, since
this isn't supported in the side-by-side diff
- Move handling of buffer folding into the block map
- Rework `set_companion` to handle both `DisplayMap`s at once
- DRY some code around block map syncing in the `DisplayMap`
TODO:
- [x] diagnose and fix issue that causes balancing blocks not to render
properly when they are adjacent to spacers (e.g. merge conflict buttons)
- [x] clear balancing blocks when clearing companion
- [x] additional tests: interaction between spacers and balancing
blocks, resizing
Release Notes:
- N/A
