Fix typos. (lapce#502)

src/id.rs

@@ -72,7 +72,7 @@ impl ViewId {
     pub(crate) fn state(&self) -> Rc<RefCell<ViewState>> {
         VIEW_STORAGE.with_borrow_mut(|s| {
             if !s.view_ids.contains_key(*self) {
-                // if view_ids doens't have this view id, that means it's been cleaned up,
+                // if view_ids doesn't have this view id, that means it's been cleaned up,
                 // so we shouldn't create a new ViewState for this Id.
                 s.stale_view_state.clone()
             } else {

src/view.rs

@@ -16,7 +16,7 @@
 //! For all reactive state that your type contains, either in the form of signals or derived signals, you need to process the changes within an effect.
 //! The most common pattern is to [get](floem_reactive::ReadSignal::get) the data in an effect and pass it in to `id.update_state()` and then handle that data in the `update` method of the View trait.
 //!
-//! For exmaple a minimal slider might look like the following. First, we define the struct with the [`ViewData`] that contains the [`Id`].
+//! For example a minimal slider might look like the following. First, we define the struct with the [`ViewData`] that contains the [`Id`].
 //! Then, we use a function to construct the slider. As part of this function we create an effect that will be re-run every time the signals in the  `percent` closure change.
 //! In the effect we send the change to the associated [`Id`]. This change can then be handled in the [`Widget::update`] method.
 //! ```rust
@@ -29,7 +29,7 @@
 //! pub fn slider(percent: impl Fn() -> f32 + 'static) -> Slider {
 //!    let id = ViewId::new();
 //!
-//!    // If the following effect is not created, and `percent` is accesed directly,
+//!    // If the following effect is not created, and `percent` is accessed directly,
 //!    // `percent` will only be accessed a single time and will not be reactive.
 //!    // Therefore the following `create_effect` is necessary for reactivity.
 //!    create_effect(move |_| {

src/views/decorator.rs

@@ -1,6 +1,6 @@
 //! # Decorator
 //!
-//! The decorator trait is the primary interface for extending the appereance and functionality of ['View']s.
+//! The decorator trait is the primary interface for extending the appearance and functionality of ['View']s.
 
 use floem_reactive::{create_effect, create_updater};
 use floem_winit::keyboard::Key;

src/views/editor/mod.rs

@@ -1391,7 +1391,7 @@ fn create_view_effects(cx: Scope, ed: &Editor) {
     // lines based on that
     ed3.lines.layout_event.listen_with(cx, move |val| {
         let ed = &ed2;
-        // TODO: Move this logic onto screen lines somehow, perhaps just an auxilary
+        // TODO: Move this logic onto screen lines somehow, perhaps just an auxiliary
         // function, to avoid getting confused about what is relevant where.
 
         match val {

src/views/editor/view.rs

@@ -44,7 +44,7 @@ pub struct DiffSection {
     /// The y index that the diff section is at.  
     /// This is multiplied by the line height to get the y position.  
     /// So this can roughly be considered as the `VLine of the start of this diff section, but it
-    /// isn't necessarily convertable to a `VLine` due to jumping over empty code sections.
+    /// isn't necessarily convertible to a `VLine` due to jumping over empty code sections.
     pub y_idx: usize,
     pub height: usize,
     pub kind: DiffSectionKind,

src/views/editor/visual_line.rs

@@ -1,6 +1,6 @@
 //! Visual Line implementation  
 //!   
-//! Files are easily broken up into buffer lines by just spliiting on `\n` or `\r\n`.  
+//! Files are easily broken up into buffer lines by just splitting on `\n` or `\r\n`.
 //! However, editors require features like wrapping and multiline phantom text. These break the
 //! nice one-to-one correspondence between buffer lines and visual lines.  
 //!   
@@ -223,7 +223,7 @@ pub trait TextLayoutProvider {
         wrap: ResolvedWrap,
     ) -> Arc<TextLayoutLine>;
 
-    /// Translate a column position into the postiion it would be before combining with the phantom
+    /// Translate a column position into the position it would be before combining with the phantom
     /// text
     fn before_phantom_col(&self, line: usize, col: usize) -> usize;
 
@@ -1062,7 +1062,7 @@ fn find_rvline_of_offset(
                     // There is no previous line, we do nothing.
                 } else {
                     // We have to get rvline info for that rvline, so we can get the last line index
-                    // This should aways have at least one rvline in it.
+                    // This should always have at least one rvline in it.
                     let font_sizes = lines.font_sizes.borrow();
                     let (prev, _) = prev_rvline(&layouts, text_prov, &**font_sizes, rv)?;
                     return Some(prev);
@@ -1928,7 +1928,7 @@ fn prev_rvline(
 
 // FIXME: Put this in our cosmic-text fork.
 
-/// Hit position but decides wether it should go to the next line based on the `before` bool.
+/// Hit position but decides whether it should go to the next line based on the `before` bool.
 /// (Hit position should be equivalent to `before=false`).  
 /// This is needed when we have an idx at the end of, for example, a wrapped line which could be on
 /// the first or second line.

src/views/mod.rs

@@ -33,7 +33,7 @@
 //! The dynamic stack can dynamically change the elements in the stack by reactively updating the list of items provided to the [dyn_stack](dyn_stack()).
 //! Virtual stacks and virtual lists are like the dynamic stack but they also lazily load the items as they appear in a [scroll view](scroll()) and do not support the flexbox nor grid layout algorithms.
 //! Instead, they give every element a consistent size and use a basic layout.
-//! This is done for perfomance and allows for lists of millions of items to be used with very high performance.
+//! This is done for performance and allows for lists of millions of items to be used with very high performance.
 //!
 //! Lists differ from stacks in that they also have built-in support for the selection of items: up and down using arrow keys, top and bottom control using the home and end keys, and for the "acceptance" of an item using the Enter key.
 //! You could build this manually yourself using stacks but it is common enough that it is built-in as a list.

src/views/text_editor.rs

@@ -173,7 +173,7 @@ impl EditorCustomStyle {
         self
     }
 
-    /// Sets the padding to the left of the nubmers in the gutter.
+    /// Sets the padding to the left of the numbers in the gutter.
     pub fn gutter_left_padding(mut self, padding: f64) -> Self {
         self.0 = self
             .0

src/views/toggle_button.rs

@@ -17,12 +17,12 @@ use crate::{
     views::Decorators,
 };
 
-/// Controls the switching behavior of the switch. The cooresponding style prop is [ToggleButtonBehavior]
+/// Controls the switching behavior of the switch. The corresponding style prop is [ToggleButtonBehavior]
 #[derive(Debug, Clone, PartialEq)]
 pub enum ToggleHandleBehavior {
-    /// The switch foreground item will follow the position of the cursor. The toggle event happens when the cursor passes teh 50% threshhold.
+    /// The switch foreground item will follow the position of the cursor. The toggle event happens when the cursor passes the 50% threshold.
     Follow,
-    /// The switch foreground item will "snap" from being toggled off/on when the cursor passes the 50% threshhold.
+    /// The switch foreground item will "snap" from being toggled off/on when the cursor passes the 50% threshold.
     Snap,
 }
 
@@ -137,7 +137,7 @@ impl View for ToggleButton {
             crate::event::Event::PointerUp(_event) => {
                 self.id.request_layout();
 
-                // if held and pointer up. toggle the position (toggle state drag alrady changed the position)
+                // if held and pointer up. toggle the position (toggle state drag already changed the position)
                 if self.held == ToggleState::Held {
                     if self.position > self.width / 2. {
                         self.position = 0.;

src/views/virtual_stack.rs

@@ -76,7 +76,7 @@ struct VirtualStackState<T> {
 
 /// A View that is like a [`dyn_stack`](super::dyn_stack()) but also lazily loads the items as they appear in a [scroll view](super::scroll()) and does not support the flexbox nor grid layout algorithms.
 /// Instead, the Virtual Stack gives every element a consistent size and uses a basic layout.
-/// This is done for perfomance and allows for lists of millions of items to be used with very high performance.
+/// This is done for performance and allows for lists of millions of items to be used with very high performance.
 ///
 /// ## Example
 /// ```

src/window_id.rs

@@ -100,7 +100,7 @@ impl WindowIdExtSealed for WindowId {
 ///    methods whose return value have that as a prerequisite will return `None` or return a
 ///    reasonable default.
 ///  * X11: Some window managers (Openbox was one such which was tested) *appear* to support
-///    retreiving separate window-with-frame and window-content positions and sizes, but in
+///    retrieving separate window-with-frame and window-content positions and sizes, but in
 ///    fact report the same values for both.
 #[allow(private_bounds)]
 pub trait WindowIdExt: WindowIdExtSealed {
@@ -138,7 +138,7 @@ pub trait WindowIdExt: WindowIdExtSealed {
     fn is_document_edited(&self) -> bool;
 
     /// Instruct the window manager to indicate in the window's decorations
-    /// the the window contains an unsaved, edited document.  Only has an
+    /// that the window contains an unsaved, edited document.  Only has an
     /// effect on Mac OS.
     #[allow(unused_variables)] // edited unused on non-mac builds
     fn set_document_edited(&self, edited: bool) {