This way, completions are dealt with more consistently with code actions,
and the logic is not spread across so many places. The `language::File`
trait and the multibuffer no longer need to deal with completions. Completions
are no longer generic over an anchor type.
Using a bounded channel may have blocked the collaboration server
from making progress handling RPC traffic.
There's no need to apply backpressure to calling code within the
same process - suspending a task that is attempting to call `send` has
an even greater memory cost than just buffering a protobuf message.
We do still want a bounded channel for incoming messages, so that
we provide backpressure to noisy peers - blocking their writes as opposed
to allowing them to buffer arbitrarily many messages in our server.
Co-Authored-By: Antonio Scandurra <me@as-cii.com>
Co-Authored-By: Nathan Sobo <nathan@zed.dev>
This isn't perfect but we'll retain up to 10 old versions just in case there
are race conditions in the language server. We haven't seen this in the wild
but we're concerned about diagnostic reporting racing with code action
resolution.
Co-Authored-By: Nathan Sobo <nathan@zed.dev>
This avoids a problem where the operating system would drop events
on the floor and tell us to rescan the entire directory, which in turn
would cause a flicker in the project browser.
Co-Authored-By: Nathan Sobo <nathan@zed.dev>
This used to be needed, but we think with our improvements to message ordering that we'll never miss operations that were applied after opening a remote buffer.
Co-Authored-By: Max Brunsfeld <maxbrunsfeld@gmail.com>
If you want to call `abs_path` or `load`, the file needs to be local. You call `as_local` which returns `Option<dyn LocalFile>` with those local-only methods. I think this makes it more explicit what works only locally vs everywhere.
I'd like to only have methods related to absolute paths on local worktrees, because it's not really possible to implement them on remote worktrees since we don't know the full path being shared and wouldn't have anything to do with it anyway if we did.
The former always adds a worktree, even if we have one already in the
project and that could be misused. The public API should always search
for a local worktree containing the requested path first so that the
project can uphold invariants about which worktrees it has.
