Previously, we would use `Project::serialize_buffer_for_peer` and
`Project::deserialize_buffer` respectively in the host and in the
guest to create a new buffer or just send its ID if the host thought
the buffer had already been sent.
These methods would be called as part of other methods, such as
`Project::open_buffer_by_id` or `Project::open_buffer_for_symbol`.
However, if any of the tasks driving the futures that eventually
called `Project::deserialize_buffer` were dropped after the host
responded with the buffer state but (crucially) before the guest
deserialized it and registered it, there could be a situation where
the host thought the guest had the buffer (thus sending them just the
buffer id) and the guest would wait indefinitely.
Given how crucial this interaction is, this commit switches to creating
remote buffers for peers out of band. The host will push buffers to guests,
who will always refer to buffers via IDs and wait for the host to send them,
as opposed to including the buffer's payload as part of some other operation.
Previously, a change on a given line would cause that whole line to be
replaced. In turn, this caused anchors on that line to go to the start
of that line because they would lie inside of a deleted region after applying
the diff.
By switching to a character-wise diff, we perform smaller edits to the buffer
which stabilizes anchor positions.
This commit introduces a new, optional `Item::tab_description` method
that lets implementers define a description for the tab with a certain
`detail`. When two or more tabs match the same description, we will
increase the `detail` until tabs don't match anymore or increasing the
`detail` doesn't disambiguate tabs any further.
As soon as we find a valid `detail` that disambiguates tabs enough, we
will pass it to `Item::tab_content`. In `Editor`, this is implemented by
showing more and more of the path's suffix as `detail` is increased.
* Moving the logic from Rope to text::Buffer makes it easier
to keep the Rope in sync with the fragment tree.
* Removing carriage return characters is lossier, but is much
simpler than incrementally maintaining the invariant that
there are no carriage returns followed by newlines. We may
want to do something smarter in the future.
Co-authored-by: Keith Simmons <keith@zed.dev>
