Apply suggestions from code review

Co-authored-by: Markus Røyset <[email protected]>

src/event.rs

@@ -79,12 +79,12 @@ pub enum Event<'a, T: 'static> {
     ///
     /// Not all platforms support the notion of suspending applications, and there may be no
     /// technical way to guarantee being able to emit a `Suspended` event if the OS has
-    /// no formal application lifecycle (currently only Android and iOS do). For this reason
+    /// no formal application lifecycle (currently only Android and iOS do). For this reason,
     /// Winit does not currently try to emit pseudo `Suspended` events before the application
     /// quits on platforms without an application lifecycle.
     ///
     /// Considering that the implementation of `Suspended` and [`Resumed`] events may be internally
-    /// driven by multiple platform-specific events, and there may be subtle differences across
+    /// driven by multiple platform-specific events, and that there may be subtle differences across
     /// platforms with how these internal events are delivered, it's recommended that applications
     /// be able to gracefully handle redundant (i.e. back-to-back) `Suspended` or [`Resumed`] events.
     ///
@@ -112,7 +112,7 @@ pub enum Event<'a, T: 'static> {
     ///
     /// ## iOS
     ///
-    /// On iOS the `Suspended` event is currently emitted in response to an
+    /// On iOS, the `Suspended` event is currently emitted in response to an
     /// [`applicationWillResignActive`] callback which means that the application is
     /// about to transition from the active to inactive state (according to the
     /// [iOS application lifecycle]).
@@ -125,7 +125,7 @@ pub enum Event<'a, T: 'static> {
 
     /// Emitted when the application has been resumed.
     ///
-    /// For consistency all platforms emit a `Resumed` event even if they don't themselves have a
+    /// For consistency, all platforms emit a `Resumed` event even if they don't themselves have a
     /// formal suspend/resume lifecycle. For systems without a standard suspend/resume lifecycle
     /// the `Resumed` event is always emitted after the [`NewEvents(StartCause::Init)`][StartCause::Init]
     /// event.
@@ -138,15 +138,15 @@ pub enum Event<'a, T: 'static> {
     /// resumed.
     ///
     /// Considering that the implementation of [`Suspended`] and `Resumed` events may be internally
-    /// driven by multiple platform-specific events, and there may be subtle differences across
+    /// driven by multiple platform-specific events, and that there may be subtle differences across
     /// platforms with how these internal events are delivered, it's recommended that applications
     /// be able to gracefully handle redundant (i.e. back-to-back) [`Suspended`] or `Resumed` events.
     ///
     /// Also see [`Suspended`] notes.
     ///
     /// ## Android
     ///
-    /// On Android the `Resumed` event is sent when a new [`SurfaceView`] has been created. This is
+    /// On Android, the `Resumed` event is sent when a new [`SurfaceView`] has been created. This is
     /// expected to closely correlate with the [`onResume`] lifecycle event but there may technically
     /// be a discrepancy.
     ///
@@ -155,7 +155,7 @@ pub enum Event<'a, T: 'static> {
     /// Applications that need to run on Android must wait until they have been `Resumed`
     /// before they will be able to create a render surface (such as an `EGLSurface`,
     /// [`VkSurfaceKHR`] or [`wgpu::Surface`]) which depend on having a
-    /// [`SurfaceView`]. Applications must also assume that if they are [`Suspended`] then their
+    /// [`SurfaceView`]. Applications must also assume that if they are [`Suspended`], then their
     /// render surfaces are invalid and should be dropped.
     ///
     /// Also see [`Suspended`] notes.
@@ -167,7 +167,7 @@ pub enum Event<'a, T: 'static> {
     ///
     /// ## iOS
     ///
-    /// On iOS the `Resumed` event is emitted in response to an [`applicationDidBecomeActive`]
+    /// On iOS, the `Resumed` event is emitted in response to an [`applicationDidBecomeActive`]
     /// callback which means the application is "active" (according to the
     /// [iOS application lifecycle]).
     ///