Also, increase the receive timeout to 30 seconds. We'll still respond immediately
to explicit disconnection, but when there are temporary network blips that
delay pings, we think we should err on the side of keeping the connection
alive. This is in response to a false positive 'host disconnected' state
that we observed when pairing today, while the host (Keith) still clearly
had a working internet connection, because we were screen sharing.
Co-Authored-By: Keith Simmons <keith@zed.dev>
We added this because we thought it would save some allocations when
sending operations given that we could move them to the delegate upon
notifying it, but the reality is that we serialize operations and that
only requires a reference.
* Make advance_clock more realistic by waking timers in order,
instead of all at once.
* Don't advance the clock when simulating random delays.
Co-Authored-By: Keith Simmons <keith@zed.dev>
Co-Authored-By: Nathan Sobo <nathan@zed.dev>
This fixes a bug introduced in #538, where closing the current tab would hide
all the other tabs, if the current tab was the last one.
Also, this commit manually sets the active item index instead of calling
`Pane::activate_item`: even though this introduces a little bit of duplication,
it prevents us from mistakenly calling `deactivate` on the wrong item. This would
happen because `activate_item` looks at `self.active_item_index` to determine
which item to deactivate before setting the new one. However, that index is
potentially invalid because `::close_items` manipulates the `item_views` vector,
so `activate_item` could end up calling `deactivate` on an item view that was
not active in the first place.
When a network connection is lost without being explicitly closed by the
other end, writes to that connection will error, but reads will just wait
indefinitely.
This allows the tests to exercise our heartbeat logic.
This allows the registration of such buffers in the project, which is necessary
to correctly support `::save_buffer_as` and opens the door to sharing untitled
buffers with guests in the future.
Note that, for now, this disallows guests to create untitled buffers in the
current window and will create a new window instead. This is because we don't
yet have a global way of allocating a buffer's remote id (nor a way of saving
such buffers in the host's worktree) and we instead rely on the local model ID,
which could clash with the host's buffer IDs.
I think we should revisit this once guests can share their untitled buffers
with the host and other remote peers, as well as once we start keying
operations by entry id.
