The feature doesn't work yet because the JSON language server
only supports *range* formatting, not document formatting.
We need to adjust our code to inspect the server's capabilities
and send range formatting requests instead when needed.
We're going to hold off on doing this right now, because it
will create merge conflicts with the `preserve-worktrees`
branch (#525)
Co-Authored-By: Nathan Sobo <nathan@zed.dev>
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.
