Update event-processing.md

From tech review

Author: suearkinunity

Packages/com.unity.inputsystem/Documentation~/event-processing.md

@@ -8,7 +8,7 @@ uid: input-system-event-processing
 
 Each time input is processed, [`InputSystem.Update`](xref:UnityEngine.InputSystem.InputSystem) is called implicitly by the Unity runtime.
 
-The interval at which this happens is determined by the ["Update Mode"](update-mode.md) configured in the settings. By default, input is processed in each frame __before__ <c>MonoBehaviour.Update</c> methods are called. If the setting is changed to process input in fixed updates, then this changes to input being processed each time before <c>MonoBehaviour.FixedUpdate</c> methods are called.
+The interval at which this happens is determined by the [Update Mode](update-mode.md) configured in the settings. By default, input is processed in each frame __before__ <c>MonoBehaviour.Update</c> methods are called. If the setting is changed to process input in fixed updates, then this changes to input being processed each time before <c>MonoBehaviour.FixedUpdate</c> methods are called.
 
 Normally, when input is processed, __all__ outstanding input events on the queue will be consumed. There are two exceptions to this, however.
 
@@ -17,8 +17,8 @@ When using [`UpdateMode.ProcessEventsInFixedUpdate`](xref:UnityEngine.InputSyste
 The other exception are [`BeforeRender`](xref:UnityEngine.InputSystem.LowLevel.InputUpdateType) updates. These updates are run after fixed or dynamic updates but before rendering and used used exclusively to update devices such as VR headsets that need the most up-to-date tracking data. Other input is not consumed from such updates and these updates are only enabled if such devices are actually present. `BeforeRender` updates are not considered separate frames as far as input is concerned.
 
 > [!NOTE]
-> Manually calling [`InputSystem.Update`](xref:UnityEngine.InputSystem.InputSystem) is strongly advised against except within tests employing [`InputTestFixture`](xref:UnityEngine.InputSystem.InputTestFixture) or when explicitly setting the system to [manual update mode](xref:UnityEngine.InputSystem.InputSettings.UpdateMode).
+> Manually calling `InputSystem.Update` is strongly advised against except within tests employing [`InputTestFixture`](xref:UnityEngine.InputSystem.InputTestFixture) or when explicitly setting the system to [manual update mode](xref:UnityEngine.InputSystem.InputSettings.UpdateMode).
 
-Methods such as [`InputAction.WasPerformedThisFrame`](xref:UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_WasPerformedThisFrame) and [`WasPerformedThisDynamicUpdate`](xref:UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_WasPerformedThisDynamicUpdate) operate implicitly based on the [`InputSystem.Update`] cadence described above. Meaning, that they refer to the state as per the __last__ fixed/dynamic/manual update happened.
+Methods such as [`InputAction.WasPerformedThisFrame`](xref:UnityEngine.InputSystem.InputAction.WasPerformedThisFrame) operate implicitly based on the `InputSystem.Update` cadence described above. Meaning, they refer to the state as it was in the __last__ fixed, dynamic, or manual update happened.
 
 You can query the [current/last update type](xref:UnityEngine.InputSystem.LowLevel.InputState) and [count](xref:UnityEngine.InputSystem.LowLevel.InputState) from [`InputState`](xref:UnityEngine.InputSystem.LowLevel.InputState).