From 6919c2fb2d45dc4063c9ef52a69d857ed30657c7 Mon Sep 17 00:00:00 2001
From: Matt Kraai <kraai@ftbfs.org>
Date: Thu, 9 Jul 2020 15:08:26 +0000
Subject: [PATCH] Fix misspellings in comments (#1618)

---
 src/lib.rs                            | 2 +-
 src/monitor.rs                        | 2 +-
 src/platform_impl/linux/x11/window.rs | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/lib.rs b/src/lib.rs
index ce666656..4a45022c 100644
--- a/src/lib.rs
+++ b/src/lib.rs
@@ -28,7 +28,7 @@
 //! Some user activity, like mouse movement, can generate both a [`WindowEvent`] *and* a
 //! [`DeviceEvent`]. You can also create and handle your own custom [`UserEvent`]s, if desired.
 //!
-//! You can retreive events by calling [`EventLoop::run`][event_loop_run]. This function will
+//! You can retrieve events by calling [`EventLoop::run`][event_loop_run]. This function will
 //! dispatch events for every [`Window`] that was created with that particular [`EventLoop`], and
 //! will run until the `control_flow` argument given to the closure is set to
 //! [`ControlFlow`]`::`[`Exit`], at which point [`Event`]`::`[`LoopDestroyed`] is emitted and the
diff --git a/src/monitor.rs b/src/monitor.rs
index 126b03e2..5cf680ff 100644
--- a/src/monitor.rs
+++ b/src/monitor.rs
@@ -1,7 +1,7 @@
 //! Types useful for interacting with a user's monitors.
 //!
 //! If you want to get basic information about a monitor, you can use the [`MonitorHandle`][monitor_handle]
-//! type. This is retreived from one of the following methods, which return an iterator of
+//! type. This is retrieved from one of the following methods, which return an iterator of
 //! [`MonitorHandle`][monitor_handle]:
 //! - [`EventLoopWindowTarget::available_monitors`][loop_get]
 //! - [`Window::available_monitors`][window_get].
diff --git a/src/platform_impl/linux/x11/window.rs b/src/platform_impl/linux/x11/window.rs
index a7e31980..ae63f436 100644
--- a/src/platform_impl/linux/x11/window.rs
+++ b/src/platform_impl/linux/x11/window.rs
@@ -227,7 +227,7 @@ impl UnownedWindow {
                 // is > 0, like we do in glutin.
                 //
                 // It is non obvious which masks, if any, we should pass to
-                // `XGetVisualInfo`. winit doesn't recieve any info about what
+                // `XGetVisualInfo`. winit doesn't receive any info about what
                 // properties the user wants. Users should consider choosing the
                 // visual themselves as glutin does.
                 match pl_attribs.visual_infos {