Fix various typos

Mainly fix typos in comments, but also some minor code changes:

* Rename `apply_on_poiner` to `apply_on_pointer`.
* Rename `ImeState::Commited` to `ImeState::Committed`
* Correct `cfg_attr` usage: `wayland_platfrom` -> `wayland_platform`.

src/platform_impl/windows/drop_handler.rs

@@ -214,10 +214,10 @@ impl FileDropHandler {
         } else if get_data_result == DV_E_FORMATETC {
             // If the dropped item is not a file this error will occur.
             // In this case it is OK to return without taking further action.
-            debug!("Error occured while processing dropped/hovered item: item is not a file.");
+            debug!("Error occurred while processing dropped/hovered item: item is not a file.");
             None
         } else {
-            debug!("Unexpected error occured while processing dropped/hovered item.");
+            debug!("Unexpected error occurred while processing dropped/hovered item.");
             None
         }
     }

src/platform_impl/windows/event_loop.rs

@@ -427,7 +427,7 @@ impl<T: 'static> EventLoop<T> {
         // The Windows API has no documented requirement for bitwise
         // initializing a `MSG` struct (it can be uninitialized memory for the C
         // API) and there's no API to construct or initialize a `MSG`. This
-        // is the simplest way avoid unitialized memory in Rust
+        // is the simplest way avoid uninitialized memory in Rust
         let mut msg = unsafe { mem::zeroed() };
         let msg_status = wait_for_msg(&mut msg, timeout);
 
@@ -475,7 +475,7 @@ impl<T: 'static> EventLoop<T> {
         // The Windows API has no documented requirement for bitwise
         // initializing a `MSG` struct (it can be uninitialized memory for the C
         // API) and there's no API to construct or initialize a `MSG`. This
-        // is the simplest way avoid unitialized memory in Rust
+        // is the simplest way avoid uninitialized memory in Rust
         let mut msg = unsafe { mem::zeroed() };
 
         loop {
@@ -1102,7 +1102,7 @@ unsafe fn public_window_callback_inner(
         .unwrap_or_else(|| result = ProcResult::Value(-1));
 
     // I decided to bind the closure to `callback` and pass it to catch_unwind rather than passing
-    // the closure to catch_unwind directly so that the match body indendation wouldn't change and
+    // the closure to catch_unwind directly so that the match body indentation wouldn't change and
     // the git blame and history would be preserved.
     let callback = || match msg {
         WM_NCCALCSIZE => {
@@ -2381,7 +2381,7 @@ unsafe extern "system" fn thread_event_target_callback(
     let mut userdata_removed = false;
 
     // I decided to bind the closure to `callback` and pass it to catch_unwind rather than passing
-    // the closure to catch_unwind directly so that the match body indendation wouldn't change and
+    // the closure to catch_unwind directly so that the match body indentation wouldn't change and
     // the git blame and history would be preserved.
     let callback = || match msg {
         WM_NCDESTROY => {
@@ -2391,7 +2391,7 @@ unsafe extern "system" fn thread_event_target_callback(
         }
         WM_PAINT => unsafe {
             ValidateRect(window, ptr::null());
-            // Default WM_PAINT behaviour. This makes sure modals and popups are shown immediatly when opening them.
+            // Default WM_PAINT behaviour. This makes sure modals and popups are shown immediately when opening them.
             DefWindowProcW(window, msg, wparam, lparam)
         },
 

src/platform_impl/windows/keyboard.rs

@@ -328,7 +328,7 @@ impl KeyEventBuilder {
         }
     }
 
-    // Alowing nominimal_bool lint because the `is_key_pressed` macro triggers this warning
+    // Allowing nominimal_bool lint because the `is_key_pressed` macro triggers this warning
     // and I don't know of another way to resolve it and also keeping the macro
     #[allow(clippy::nonminimal_bool)]
     fn synthesize_kbd_state(
@@ -737,7 +737,7 @@ fn get_async_kbd_state() -> [u8; 256] {
 
 /// On windows, AltGr == Ctrl + Alt
 ///
-/// Due to this equivalence, the system generates a fake Ctrl key-press (and key-release) preceeding
+/// Due to this equivalence, the system generates a fake Ctrl key-press (and key-release) preceding
 /// every AltGr key-press (and key-release). We check if the current event is a Ctrl event and if
 /// the next event is a right Alt (AltGr) event. If this is the case, the current event must be the
 /// fake Ctrl event.

src/platform_impl/windows/keyboard_layout.rs

@@ -192,7 +192,7 @@ pub(crate) struct Layout {
 
     /// Maps numpad keys from Windows virtual key to a `Key`.
     ///
-    /// This is useful because some numpad keys generate different charcaters based on the locale.
+    /// This is useful because some numpad keys generate different characters based on the locale.
     /// For example `VK_DECIMAL` is sometimes "." and sometimes ",". Note: numpad-specific virtual
     /// keys are only produced by Windows when the NumLock is active.
     ///
@@ -790,7 +790,7 @@ fn vkey_to_non_char_key(
         //VK_HANGEUL => Key::Named(NamedKey::HangulMode), // Deprecated in favour of VK_HANGUL
 
         // VK_HANGUL and VK_KANA are defined as the same constant, therefore
-        // we use appropriate conditions to differentate between them
+        // we use appropriate conditions to differentiate between them
         VK_HANGUL if is_korean => Key::Named(NamedKey::HangulMode),
         VK_KANA if is_japanese => Key::Named(NamedKey::KanaMode),
 
@@ -798,7 +798,7 @@ fn vkey_to_non_char_key(
         VK_FINAL => Key::Named(NamedKey::FinalMode),
 
         // VK_HANJA and VK_KANJI are defined as the same constant, therefore
-        // we use appropriate conditions to differentate between them
+        // we use appropriate conditions to differentiate between them
         VK_HANJA if is_korean => Key::Named(NamedKey::HanjaMode),
         VK_KANJI if is_japanese => Key::Named(NamedKey::KanjiMode),
 
@@ -983,7 +983,7 @@ fn vkey_to_non_char_key(
                 // This matches IE and Firefox behaviour according to
                 // https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/key/Key_Values
                 // At the time of writing, there is no `NamedKey::Finish` variant as
-                // Finish is not mentionned at https://w3c.github.io/uievents-key/
+                // Finish is not mentioned at https://w3c.github.io/uievents-key/
                 // Also see: https://github.com/pyfisch/keyboard-types/issues/9
                 Key::Unidentified(native_code)
             }