This is required because, after joining, we want to be able to refer
to operations that have happened prior to joining, which are not
captured by the state. There is probably a way of reconstructing operations
from the state, but that seems unnecessary and we've already talked about
wanting to have the server store operations rather than state once we start
persisting worktrees.
Also, use env_logger consistently in the tests for each crate.
Only initiallize the logger at all if some RUST_LOG env var is set.
Co-Authored-By: Nathan Sobo <nathan@zed.dev>
Specifically, with this commit:
- We will now refresh the anchor if it escapes the boundaries of the excerpt by
using the `Excerpt::contains` method. This was not the case before, as we were
just checking if the excerpt id and buffer id of the anchors matched the ones
stored on the excerpt.
- We fixed a bug that was causing the anchor to be outside of the excerpt when
resetting it to one of the excerpt's endpoints after we couldn't keep its
position. This would happen because we were using `anchor_at`, which resolved
the anchor to an offset first and then converted it back into an anchor with
the given bias, which is a lossy operation. We now use `Anchor::bias` to
achieve the same goal: note that this could still lead to the anchor escaping
the excerpt's boundary when the bias doesn't match the endpoint's bias, so we
take extra care to avoid that and `min`/`max` the newly-produced anchor with
the other endpoint.
The main reason for this is that we need to include information about
a buffer's UndoMap into its protobuf representation. But it's a bit
complex to correctly incorporate this information into the current
protobuf representation.
If we want to continue reusing `Buffer::apply_remote_edit` for
incorporating the historical operations, we need to either make
that method capable of incorporating already-undone edits, or
serialize the UndoMap into undo *operations*, so that we can apply
these undo operations after the fact when deserializing. But this is
not trivial, because an UndoOperation requires information about
the full offset ranges that were undone.
If the transaction was nested, we return None. Otherwise we return the transaction id in preparation for editors to maintain their own selection state.
