Fix possessive "its" in docs and comments (#3998)

This PR fixes a number of places where we were incorrectly using "it's"
where we needed to use the possessive "its".

Release Notes:

- N/A

crates/editor/src/editor.rs

@@ -7050,7 +7050,7 @@ impl Editor {
         let buffer = self.buffer.read(cx).snapshot(cx);
         let selection = self.selections.newest::<usize>(cx);
 
-        // If there is an active Diagnostic Popover. Jump to it's diagnostic instead.
+        // If there is an active Diagnostic Popover jump to its diagnostic instead.
         if direction == Direction::Next {
             if let Some(popover) = self.hover_state.diagnostic_popover.as_ref() {
                 let (group_id, jump_to) = popover.activation_info();

crates/gpui/src/action.rs

@@ -104,7 +104,7 @@ pub struct ActionData {
 }
 
 /// This constant must be public to be accessible from other crates.
-/// But it's existence is an implementation detail and should not be used directly.
+/// But its existence is an implementation detail and should not be used directly.
 #[doc(hidden)]
 #[linkme::distributed_slice]
 pub static __GPUI_ACTIONS: [MacroActionBuilder];

crates/gpui/src/color.rs

@@ -321,7 +321,7 @@ impl Hsla {
     ///
     /// Assumptions:
     /// - Alpha values are contained in the range [0, 1], with 1 as fully opaque and 0 as fully transparent.
-    /// - The relative contributions of `self` and `other` is based on `self`'s alpha value (`self.a`) and `other`'s  alpha value (`other.a`), `self` contributing `self.a * (1.0 - other.a)` and `other` contributing it's own alpha value.
+    /// - The relative contributions of `self` and `other` is based on `self`'s alpha value (`self.a`) and `other`'s  alpha value (`other.a`), `self` contributing `self.a * (1.0 - other.a)` and `other` contributing its own alpha value.
     /// - RGB color components are contained in the range [0, 1].
     /// - If `self` and `other` colors are out of the valid range, the blend operation's output and behavior is undefined.
     pub fn blend(self, other: Hsla) -> Hsla {

crates/gpui/src/elements/overlay.rs

@@ -45,7 +45,7 @@ impl Overlay {
     }
 
     /// Sets the position mode for this overlay. Local will have this
-    /// interpret it's [Overlay::position] as relative to the parent element.
+    /// interpret its [`Overlay::position`] as relative to the parent element.
     /// While Window will have it interpret the position as relative to the window.
     pub fn position_mode(mut self, mode: OverlayPositionMode) -> Self {
         self.position_mode = mode;

crates/plugin_runtime/OPAQUE.md

@@ -34,7 +34,7 @@ Rhai actually exposes a pretty nice interface for working with native Rust types
 
 > **Note**: Rhai uses strings, but I wonder if you could get away with something more compact using `TypeIds`. Maybe not, given that `TypeId`s are not deterministic across builds, and we'd need matching IDs both host-side and guest side.
 
-In Rhai, we can alternatively use the method `Engine::register_type_with_name::<T: Variant + Clone>(name: &str)` if we have a different type name host-side (in Rust) and guest-side (in Rhai). 
+In Rhai, we can alternatively use the method `Engine::register_type_with_name::<T: Variant + Clone>(name: &str)` if we have a different type name host-side (in Rust) and guest-side (in Rhai).
 
 With respect to Wasm plugins, I think an interface like this is fairly important, because we don't know whether the original plugin was written in Rust. (This may not be true now, because we write all the plugins Zed uses, but once we allow packaging and shipping plugins, it's important to maintain a consistent interface, because even Rust changes over time.)
 
@@ -72,15 +72,15 @@ Union::Variant(v, ..) => (*v).as_boxed_any().downcast().ok().map(|x| *x),
 Now Rhai can do this because it's implemented in Rust. In other words, unlike Wasm, Rhai scripts can, indirectly, hold references to places in host memory. For us to implement something like this for Wasm plugins, we'd have to keep track of a "`ResourcePool`"—alive for the duration of each function call—that we can check rust types into and out of.
 
  I think I've got a handle on how Rhai works now, so let's stop talking about Rhai and discuss what this opaque object system would look like if we implemented it in Rust.
- 
+
  # Design Sketch
- 
+
 First things first, we'd have to generalize the arguments we can pass to and return from functions host-side. Currently, we support anything that's `serde`able. We'd have to create a new trait, say `Value`, that has blanket implementations for both `serde` and `Clone` (or something like this; if a type is both `serde` and `clone`, we'd have to figure out a way to disambiguate).
- 
- We'd also create a `ResourcePool` struct that essentially is a `Vec` of `Box<dyn Any>`. When calling a function, all `Value` arguments that are resources (e.g. `Clone` instead of `serde`) would be typecasted to `dyn Any` and stored in the `ResourcePool`. 
- 
+
+ We'd also create a `ResourcePool` struct that essentially is a `Vec` of `Box<dyn Any>`. When calling a function, all `Value` arguments that are resources (e.g. `Clone` instead of `serde`) would be typecasted to `dyn Any` and stored in the `ResourcePool`.
+
  We'd probably also need a `Resource` trait that defines an associated handle for a resource. Something like this:
- 
+
  ```rust
  pub trait Resource {
     type Handle: Serialize + DeserializeOwned;
@@ -88,24 +88,24 @@ First things first, we'd have to generalize the arguments we can pass to and ret
     fn index(handle: Self) -> u32;
  }
  ```
- 
+
  Where a handle is just a dead-simple wrapper around a `u32`:
- 
- ```rust 
+
+ ```rust
  #[derive(Serialize, Deserialize)]
  pub struct CoolHandle(u32);
  ```
- 
+
  It's important that this handle be accessible *both* host-side and plugin side. I don't know if this means that we have another crate, like `plugin_handles`, that contains a bunch of u32 wrappers, or something else. Because a `Resource::Handle` is just a u32, it's trivially `serde`, and can cross the ABI boundary.
- 
- So when we add each `T: Resource` to the `ResourcePool`, the resource pool typecasts it to `Any`, appends it to the `Vec`, and returns the associated `Resource::Handle`. This handle is what we pass through to Wasm. 
- 
+
+ So when we add each `T: Resource` to the `ResourcePool`, the resource pool typecasts it to `Any`, appends it to the `Vec`, and returns the associated `Resource::Handle`. This handle is what we pass through to Wasm.
+
  ```rust
  // Implementations and attributes omitted
  pub struct Rope { ... };
  pub struct RopeHandle(u32);
  impl Resource for Arc<RwLock<Rope>> { ... }
- 
+
  let builder: PluginBuilder = ...;
  let builder = builder
     .host_fn_async(
@@ -127,7 +127,7 @@ use plugin_handles::RopeHandle;
 pub fn append(rope: RopeHandle, string: &str);
 ```
 
-This allows us to perform an operation on a `Rope`, but how do we get a `RopeHandle` into a plugin? Well, as plugins, we can only acquire resources to handles we're given, so we'd need to expose a function that takes a handle. 
+This allows us to perform an operation on a `Rope`, but how do we get a `RopeHandle` into a plugin? Well, as plugins, we can only acquire resources to handles we're given, so we'd need to expose a function that takes a handle.
 
 To illustrate that point, here's an example. First, we'd define a plugin-side function as follows:
 
@@ -185,4 +185,4 @@ Using this approach, it should be possible to add fairly good support for resour
 
 This next week, I'll try to get a production-ready version of this working, using the `Language` resource required by some Language Server Adapters.
 
-Hope this guide made sense!
+Hope this guide made sense!

crates/plugin_runtime/README.md

@@ -164,7 +164,7 @@ To call the functions that a plugin exports host-side, you need to have 'handles
 
 For example, let's suppose we're creating a plugin that:
 
-1. formats a message 
+1. formats a message
 2. processes a list of numbers somehow
 
 We could create a struct for this plugin as follows:
@@ -179,7 +179,7 @@ pub struct CoolPlugin {
 }
 ```
 
-Note that this plugin also holds an owned reference to the runtime, which is stored in the `Plugin` type. In asynchronous or multithreaded contexts, it may be required to put `Plugin` behind an `Arc<Mutex<Plugin>>`. Although plugins expose an asynchronous interface, the underlying Wasm engine can only execute a single function at a time. 
+Note that this plugin also holds an owned reference to the runtime, which is stored in the `Plugin` type. In asynchronous or multithreaded contexts, it may be required to put `Plugin` behind an `Arc<Mutex<Plugin>>`. Although plugins expose an asynchronous interface, the underlying Wasm engine can only execute a single function at a time.
 
 > **Note**: This is a limitation of the WebAssembly standard itself. In the future, to work around this, we've been considering starting a pool of plugins, or instantiating a new plugin per call (this isn't as bad as it sounds, as instantiating a new plugin only takes about 30µs).
 
@@ -203,7 +203,7 @@ To add a sync native function to a plugin, use the `.host_function` method:
 
 ```rust
 let builder = builder.host_function(
-    "add_f64", 
+    "add_f64",
     |(a, b): (f64, f64)| a + b,
 ).unwrap();
 ```
@@ -224,7 +224,7 @@ To add an async native function to a plugin, use the `.host_function_async` meth
 
 ```rust
 let builder = builder.host_function_async(
-    "half", 
+    "half",
     |n: f64| async move { n / 2.0 },
 ).unwrap();
 ```
@@ -252,9 +252,9 @@ let plugin = builder
     .unwrap();
 ```
 
-The `.init` method takes a single argument containing the plugin binary. 
+The `.init` method takes a single argument containing the plugin binary.
 
-1. If not precompiled, use `PluginBinary::Wasm(bytes)`. This supports both the WebAssembly Textual format (`.wat`) and the WebAssembly Binary format (`.wasm`). 
+1. If not precompiled, use `PluginBinary::Wasm(bytes)`. This supports both the WebAssembly Textual format (`.wat`) and the WebAssembly Binary format (`.wasm`).
 
 2. If precompiled, use `PluginBinary::Precompiled(bytes)`. This supports precompiled plugins ending in `.wasm.pre`. You need to be extra-careful when using precompiled plugins to ensure that the plugin target matches the target of the binary you are compiling.
 
@@ -317,4 +317,4 @@ The `.call` method takes two arguments:
 This method is async, and must be `.await`ed. If something goes wrong (e.g. the plugin panics, or there is a type mismatch between the plugin and `WasiFn`), then this method will return an error.
 
 ## Last Notes
-This has been a brief overview of how the plugin system currently works in Zed. We hope to implement higher-level affordances as time goes on, to make writing plugins easier, and providing tooling so that users of Zed may also write plugins to extend their own editors. 
+This has been a brief overview of how the plugin system currently works in Zed. We hope to implement higher-level affordances as time goes on, to make writing plugins easier, and providing tooling so that users of Zed may also write plugins to extend their own editors.

crates/rope/src/rope.rs

@@ -78,7 +78,7 @@ impl Rope {
     }
 
     pub fn slice_rows(&self, range: Range<u32>) -> Rope {
-        //This would be more efficient with a forward advance after the first, but it's fine
+        // This would be more efficient with a forward advance after the first, but it's fine.
         let start = self.point_to_offset(Point::new(range.start, 0));
         let end = self.point_to_offset(Point::new(range.end, 0));
         self.slice(start..end)

crates/search/src/buffer_search.rs

@@ -423,7 +423,7 @@ impl ToolbarItemView for BufferSearchBar {
     }
 }
 
-/// Registrar inverts the dependency between search and it's downstream user, allowing said downstream user to register search action without knowing exactly what those actions are.
+/// Registrar inverts the dependency between search and its downstream user, allowing said downstream user to register search action without knowing exactly what those actions are.
 pub trait SearchActionsRegistrar {
     fn register_handler<A: Action>(
         &mut self,

crates/semantic_index/src/semantic_index.rs

@@ -1248,7 +1248,7 @@ impl SemanticIndex {
 impl Drop for JobHandle {
     fn drop(&mut self) {
         if let Some(inner) = Arc::get_mut(&mut self.tx) {
-            // This is the last instance of the JobHandle (regardless of it's origin - whether it was cloned or not)
+            // This is the last instance of the JobHandle (regardless of its origin - whether it was cloned or not)
             if let Some(tx) = inner.upgrade() {
                 let mut tx = tx.lock();
                 *tx.borrow_mut() -= 1;

crates/terminal/src/terminal.rs

@@ -983,7 +983,7 @@ impl Terminal {
         let mut terminal = if let Some(term) = term.try_lock_unfair() {
             term
         } else if self.last_synced.elapsed().as_secs_f32() > 0.25 {
-            term.lock_unfair() //It's been too long, force block
+            term.lock_unfair() // It's been too long, force block
         } else if let None = self.sync_task {
             //Skip this frame
             let delay = cx.background_executor().timer(Duration::from_millis(16));
@@ -1402,9 +1402,9 @@ fn content_index_for_mouse(pos: Point<Pixels>, size: &TerminalSize) -> usize {
     clamped_row * size.columns() + clamped_col
 }
 
-///Converts an 8 bit ANSI color to it's GPUI equivalent.
-///Accepts usize for compatibility with the alacritty::Colors interface,
-///Other than that use case, should only be called with values in the [0,255] range
+/// Converts an 8 bit ANSI color to it's GPUI equivalent.
+/// Accepts `usize` for compatibility with the `alacritty::Colors` interface,
+/// Other than that use case, should only be called with values in the [0,255] range
 pub fn get_color_at_index(index: usize, theme: &Theme) -> Hsla {
     let colors = theme.colors();
 

crates/ui/docs/hello-world.md

@@ -74,7 +74,7 @@ As you start using the Tailwind-style conventions you will be surprised how quic
 
 **Why `50.0/360.0` in `hsla()`?**
 
-gpui [gpui::Hsla] use `0.0-1.0` for all it's values, but it is common for tools to use `0-360` for hue.
+gpui [gpui::Hsla] use `0.0-1.0` for all its values, but it is common for tools to use `0-360` for hue.
 
 This may change in the future, but this is a little trick that let's you use familiar looking values.
 

crates/ui/src/components/checkbox.rs

@@ -73,7 +73,7 @@ impl RenderOnce for Checkbox {
         //  - a previously agreed to license that has been updated
         //
         // For the sake of styles we treat the indeterminate state as selected,
-        // but it's icon will be different.
+        // but its icon will be different.
         let selected =
             self.checked == Selection::Selected || self.checked == Selection::Indeterminate;
 

crates/ui/src/disableable.rs

@@ -1,4 +1,4 @@
-/// A trait for elements that can be disabled. Generally used to implement disabling an element's interactivity and changing it's appearance to reflect that it is disabled.
+/// A trait for elements that can be disabled. Generally used to implement disabling an element's interactivity and changing its appearance to reflect that it is disabled.
 pub trait Disableable {
     /// Sets whether the element is disabled.
     fn disabled(self, disabled: bool) -> Self;

crates/util/src/util.rs

@@ -41,8 +41,8 @@ pub fn truncate(s: &str, max_chars: usize) -> &str {
     }
 }
 
-/// Removes characters from the end of the string if it's length is greater than `max_chars` and
-/// appends "..." to the string. Returns string unchanged if it's length is smaller than max_chars.
+/// Removes characters from the end of the string if its length is greater than `max_chars` and
+/// appends "..." to the string. Returns string unchanged if its length is smaller than max_chars.
 pub fn truncate_and_trailoff(s: &str, max_chars: usize) -> String {
     debug_assert!(max_chars >= 5);
 
@@ -53,8 +53,8 @@ pub fn truncate_and_trailoff(s: &str, max_chars: usize) -> String {
     }
 }
 
-/// Removes characters from the front of the string if it's length is greater than `max_chars` and
-/// prepends the string with "...". Returns string unchanged if it's length is smaller than max_chars.
+/// Removes characters from the front of the string if its length is greater than `max_chars` and
+/// prepends the string with "...". Returns string unchanged if its length is smaller than max_chars.
 pub fn truncate_and_remove_front(s: &str, max_chars: usize) -> String {
     debug_assert!(max_chars >= 5);
 

docs/src/developing_zed__building_zed.md

@@ -40,7 +40,7 @@ Expect this to take 30min to an hour! Some of these steps will take quite a whil
      - (not applicable) Fine-grained Tokens, at the moment of writing, did not allow any kind of access of non-owned private repos
    - Keep the token in the browser tab/editor for the next two steps
 1. (Optional but reccomended) Add your GITHUB_TOKEN to your `.zshrc` or `.bashrc` like this: `export GITHUB_TOKEN=yourGithubAPIToken`
-1. Ensure the Zed.dev website is checked out in a sibling directory and install it's dependencies:
+1. Ensure the Zed.dev website is checked out in a sibling directory and install its dependencies:
     ```
     cd ..
     git clone https://github.com/zed-industries/zed.dev