I'm just going to the end of the soft-wrapped line, mirroring the behavior with hard wraps. It's maybe not perfectly technically correct but that behavior would require us to consider word boundaries outside of the current line, which doesn't seem worth the complexity.
If the range *touches* the fold, we unfold. This was needed to fix the behavior for unfolding at the current selection position. Previously, there was some kind of translation issue that was allowing us to accidentally work the way we wanted without this.
Co-Authored-By: Antonio Scandurra <me@as-cii.com>
Also, change the way we assert on buffer rows to reflect the fact
that we will still show the line as soft-wrapped when there is a
fold that spans multiple buffer rows.
Previously, we were mistakenly adding `tab_size` to the extent
produced by the fold edits but that could cause the edit to land on
a multi-byte character (like a fold or an emoji).
In practice, we only need to expand the edit's extent by 1 because
we are operating in the fold coordinate space and all we need to
convey is that we want to encapsulate the first tab next to whatever
edit has just occurred in the `FoldMap`.
As part of our work on the deterministic executor, in bf172f2 we fixed a
bug that occurred when there were more CPUs than paths to fuzzy-match
on.
However, that introduced another bug that caused Zed to panic when
trying to calculate how many paths should be fuzzy-matched by each
available worker thread for worktrees that didn't contain any file.
This commit bails out early in `fuzzy::match_paths` if the vector of
paths to search is empty.
This removes the need for a lock around in `WrapMap` and also removes
`WrapMap::notifications` because gpui already has a standard way of
notifying when a model updates.
Instead, just use FoldPoint, FoldOffset, etc. We don't need the naming to be general because we know exactly which layer we're building on at each layer of the DisplayMap.
We need to mutate the app in these cases to relay layout state, so this just makes things easier. We won't be able to perform layout in parallel but it's questionable whether we'll ever actually do that. If we do, we can revisit.
Co-Authored-By: Antonio Scandurra <me@as-cii.com>
Co-Authored-By: Max Brunsfeld <maxbrunsfeld@gmail.com>
Nathan Sobo