# Fix panic calling blocks_intersecting_buffer_range with an empty range \(\#28049\) · gitcafe/zed

[View on GitCafe](https://git.cafe/gitcafe/zed/commit/8b5ea0516393a6b6c46318e6ea3f162a3392627c)

Repository: [gitcafe/zed](https://git.cafe/gitcafe/zed)

Visibility: public

Requested revision: 8b5ea0516393a6b6c46318e6ea3f162a3392627c

Requested commit: 8b5ea0516393a6b6c46318e6ea3f162a3392627c

Commit: 8b5ea0516393a6b6c46318e6ea3f162a3392627c

Tree: 40a61a11144835e4ddb8f8fd4fba56bfe03fe483

Author: Nathan Sobo

Committer: GitHub

## Message

```
Fix panic calling blocks_intersecting_buffer_range with an empty range (#28049)

Previously, when comparing a block with an empty range to an empty query
range in non-inclusive mode, our binary search logic could end up
computing an inverted range, causing a panic.

This commit adds special casing when comparing empty blocks with empty
ranges.

cc @as-cii: I'm realizing that the approach to searching for the
intersecting replacement blocks makes some invalid assumptions about the
ordering of replace decorations. They aren't ordered at all by their end
range. @maxbrunsfeld and I are wondering if long term, we should remove
replace decorations and find another solution for folding buffers in
multi buffers.

Release Notes:

- Fixed an occasional panic that would occur when navigating to the next
change hunk with a pending inline transformation present.

Co-authored-by: Peter Tripp <petertripp@gmail.com>
```

## Parents

- [ec40e2d85c085677138a69ee63d82067f4dda67e](https://git.cafe/gitcafe/zed/commit/ec40e2d85c085677138a69ee63d82067f4dda67e?format=markdown)

[Source at this commit](https://git.cafe/gitcafe/zed/tree/8b5ea0516393a6b6c46318e6ea3f162a3392627c?format=markdown)