This allows us to drop the context *after* we ran all futures to
completion and that's crucial otherwise we'll never drop entities
and/or flush effects.
This replaces the `cmd-alt-shift-F` binding to open a new search. Instead, you can preserve the existing search results by entering a query and then hitting `cmd-enter` instead of `enter`. This opens a new project find view and restores the previous view to whatever query it was previously displaying. It's a bit strange, but I don't want to rely on splitting as the only way of creating multiple sets of search results.
* Distinguish between checking for updates and downloading
* Show dismissable error message when downloading failed and there
is no cached server.
Co-Authored-By: Nathan Sobo <nathan@zed.dev>
If this works, I think we should set the permissions asynchronously,
maybe as part of starting the language server, so that we avoid doing
synchronous I/O.
Also, add completion requests to the randomized collaboration integration test,
to demonstrate that this is valid.
Co-Authored-By: Nathan Sobo <nathan@zed.dev>
When handling this messages on the host, wait until the desired
version has been observed before performing the save.
Co-Authored-By: Nathan Sobo <nathan@zed.dev>
When undoing in the multi-buffer, don't preserve edits that occurred outside the multi-buffer after the edit being undone.
Co-Authored-By: Antonio Scandurra <me@as-cii.com>
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.
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>
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>
