* Add a `hard_tabs` setting that causes indentation to be performed
using a tab instead of multiple spaces.
* Change Buffer's indentation-related APIs to return an `IndentSize`
struct with a length and a kind, instead of just a single u32.
* Use hard tabs by default in Go.
Previously, buffer edits represented empty strings as None
variants of an Option. Now, the edit logic just explicitly
checks for empty strings.
Co-authored-by: Keith Simmons <keith@zed.dev>
We forgot to observe the footprint of the reconnecting replica's prior
undos into the local clock. This could cause the replica to generate
edits with a version strictly smaller than what other peers may have
observed. As such, those peers would think they had already seen those
edits and skip them.
These completions don't supply a range that should be overwritten, so
the client needs to infer it via substring matching.
Co-authored-by: Keith Simmons <keith@zed.dev>
This lets us use `next` or `prev` to decide whether to park the cursor
at the first or last filtered item.
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 edits performed in the multi-buffer, we also undo subsequent edits that may have occurred outside of the multi-buffer. This commit makes us redo those edits as well.
Co-Authored-By: Antonio Scandurra <me@as-cii.com>
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 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.
The main reason for this is that we need to include information about
a buffer's UndoMap into its protobuf representation. But it's a bit
complex to correctly incorporate this information into the current
protobuf representation.
If we want to continue reusing `Buffer::apply_remote_edit` for
incorporating the historical operations, we need to either make
that method capable of incorporating already-undone edits, or
serialize the UndoMap into undo *operations*, so that we can apply
these undo operations after the fact when deserializing. But this is
not trivial, because an UndoOperation requires information about
the full offset ranges that were undone.
Max Brunsfeld
Antonio Scandurra
Keith Simmons
