27 files changed, 216 insertions, 211 deletions

diff --git a/docs/ChangeLog/20200229.md b/docs/ChangeLog/20200229.md
index 02bca3e371..fd075c24e0 100644
--- a/docs/ChangeLog/20200229.md
+++ b/docs/ChangeLog/20200229.md
@@ -36,7 +36,7 @@ Four times a year QMK runs a process for merging Breaking Changes. A Breaking Ch
 ## Encoder flip
 
 * Flips the encoder direction so that `clockwise == true` is for actually turning the knob clockwise
-* Adds `ENCODER_DIRECTION_FLIP` define, so that reversing the expected dirction is simple for users.
+* Adds `ENCODER_DIRECTION_FLIP` define, so that reversing the expected direction is simple for users.
 * Cleans up documentation page for encoders
 
 
diff --git a/docs/ChangeLog/20200530.md b/docs/ChangeLog/20200530.md
index 9def9ae123..701b6bd5d6 100644
--- a/docs/ChangeLog/20200530.md
+++ b/docs/ChangeLog/20200530.md
@@ -19,7 +19,7 @@ These PRs move the V-USB driver code out of the qmk_firmware repository and into
 
 Updates all of the per key tap-hold functions to pass the `keyrecord_t` structure, and include documentation changes.
 
-Any remaining versions or code outside of the main repo will need to be converted: 
+Any remaining versions or code outside of the main repo will need to be converted:
 | Old function                                         | New Function                                                              |
 |------------------------------------------------------|---------------------------------------------------------------------------|
 |`uint16_t get_tapping_term(uint16_t keycode)`         |`uint16_t get_tapping_term(uint16_t keycode, keyrecord_t *record)`         |
@@ -38,7 +38,7 @@ After the next breaking change you will not be able to build if `bin/qmk hello`
 [#8269](https://github.com/qmk/qmk_firmware/pull/8269)
 
 - Provides debug functionality on ChibiOS/ARM that is more compliant than previous integrations.
-- Less maintenence, fewer QMK customisations, and allows QMK to sidestep previous compile and runtime issues.
+- Less maintenance, fewer QMK customisations, and allows QMK to sidestep previous compile and runtime issues.
 - A `make git-submodule` may be required after pulling the latest QMK Firmware code to update to the new dependency.
 
 ### Fixed RGB_DISABLE_AFTER_TIMEOUT to be seconds based & small internals cleanup
@@ -51,8 +51,10 @@ After the next breaking change you will not be able to build if `bin/qmk hello`
 
 The `RGB_DISABLE_AFTER_TIMEOUT` definition is now deprecated, and has been superseded by `RGB_DISABLE_TIMEOUT`. To use the new definition, rename `RGB_DISABLE_AFTER_TIMEOUT` to `RGB_DISABLE_TIMEOUT` in your `config.h` file, and multiply the value set by 1200.
 
-Before: `#define RGB_DISABLE_AFTER_TIMEOUT 100`  
-After: `#define RGB_DISABLE_TIMEOUT 120000`
+```diff
+-#define RGB_DISABLE_AFTER_TIMEOUT 100
++#define RGB_DISABLE_TIMEOUT 120000
+```
 
 ### Switch to qmk forks for everything
 
@@ -103,8 +105,8 @@ This allows current lily58 firmware to advance with updates to the `split_common
 - Alternatively, if you did not change the OLED code from that in `default`, you may find it easier to simply copy the [relevant section](https://github.com/qmk/qmk_firmware/blob/4ac310668501ae6786c711ecc8f01f62ddaa1c0b/keyboards/lily58/keymaps/default/keymap.c#L138-L172). Otherwise, the changes you need to make are as follows (sample change [here](https://github.com/qmk/qmk_firmware/pull/6260/files#diff-20943ea59856e9bdf3d99ecb2eee40b7R138-R173))
 - [Remove](https://github.com/qmk/qmk_firmware/pull/6260/files#diff-20943ea59856e9bdf3d99ecb2eee40b7L138-L141) the block
 ```c
-#ifdef SSD1306OLED      
-  iota_gfx_init(!has_usb());   // turns on the display  
+#ifdef SSD1306OLED
+  iota_gfx_init(!has_usb());   // turns on the display
 #endif
 ```
 - Within the block bounded by `#ifdef OLED_DRIVER_ENABLE` and `#endif // OLED_DRIVER_ENABLE`, add the following block to ensure that your two OLEDs are rotated correctly across the left and right sides:
@@ -127,7 +129,7 @@ oled_rotation_t oled_init_user(oled_rotation_t rotation) {
 
 * Refactor to use split_common and remove split codes under the zinc/revx/
 * Add - backlight RGB LED and/or underglow RGB LED option
-* Add - continuous RGB animations feature (between L and R halves) 
+* Add - continuous RGB animations feature (between L and R halves)
 * Fix - keymap files to adapt to changes
     * all authors of keymaps confirmed this PR
 * Update - documents and rules.mk
@@ -164,8 +166,8 @@ void keyboard_pre_init_kb(void) {
 - The following changes are for compatibility with the OLED driver. If you don't use the OLED driver you may safely delete [this section](https://github.com/qmk/qmk_firmware/blob/e6b9980bd45c186f7360df68c24b6e05a80c10dc/keyboards/lily58/keymaps/default/keymap.c#L144-L190)
 - [Remove](https://github.com/qmk/qmk_firmware/pull/6260/files#diff-20943ea59856e9bdf3d99ecb2eee40b7L91-L158) the block
 ```c
-#ifdef SSD1306OLED      
-  iota_gfx_init(!has_usb());   // turns on the display  
+#ifdef SSD1306OLED
+  iota_gfx_init(!has_usb());   // turns on the display
 #endif
 ```
 - Within the block bounded by `#ifdef OLED_DRIVER_ENABLE` and `#endif // OLED_DRIVER_ENABLE`, add the following block to ensure that your two OLEDs are rotated correctly across the left and right sides:
diff --git a/docs/ChangeLog/20210529.md b/docs/ChangeLog/20210529.md
index 69923b0c5a..e3d250874a 100644
--- a/docs/ChangeLog/20210529.md
+++ b/docs/ChangeLog/20210529.md
@@ -12,7 +12,7 @@ Added support for MK66F18 (Teensy 3.6) microcontroller.
 
 ### New command: qmk console ([#12828](https://github.com/qmk/qmk_firmware/pull/12828)) {#new-command-qmk-console}
 
-A new `qmk console` command has been added for attaching to your keyboard's console. It operates similiarly to QMK Toolbox by allowing you to connect to one or more keyboard consoles to display debugging messages.
+A new `qmk console` command has been added for attaching to your keyboard's console. It operates similarly to QMK Toolbox by allowing you to connect to one or more keyboard consoles to display debugging messages.
 
 ### Improved command: qmk config {#improve-command-qmk-config}
 
@@ -121,8 +121,8 @@ bool encoder_update_user(uint8_t index, bool clockwise) {
             tap_code(KC_UP);
         }
     }
-    return true; 
-    // If you return true, this will allow the keyboard level code to run, as well. 
+    return true;
+    // If you return true, this will allow the keyboard level code to run, as well.
     //Returning false will override the keyboard level code. Depending on how the keyboard level function is set up.
 }
 ```
diff --git a/docs/ChangeLog/20210828.md b/docs/ChangeLog/20210828.md
index 18b1d92b0c..9268711262 100644
--- a/docs/ChangeLog/20210828.md
+++ b/docs/ChangeLog/20210828.md
@@ -104,7 +104,7 @@ void dip_switch_update_user(uint8_t index, bool active) {
     }
 }
 
-void dip_switch_update_mask_kb(uint32_t state) { 
+void dip_switch_update_mask_kb(uint32_t state) {
     dip_switch_update_mask_user(state);
 }
 
diff --git a/docs/ChangeLog/20220226.md b/docs/ChangeLog/20220226.md
index a10b6447ea..29283a3a9c 100644
--- a/docs/ChangeLog/20220226.md
+++ b/docs/ChangeLog/20220226.md
@@ -29,7 +29,7 @@ Bootloader configuration is no longer assumed. Keyboards must now set either:
 
 ### Rename `AdafruitBLE` to `BluefruitLE` ([#16127](https://github.com/qmk/qmk_firmware/pull/16127))
 
-In preparation of future bluetooth work, the `AdafruitBLE` integration has been renamed to allow potential for any other Adafruit BLE products. 
+In preparation of future bluetooth work, the `AdafruitBLE` integration has been renamed to allow potential for any other Adafruit BLE products.
 
 ### Updated Keyboard Codebases {#updated-keyboard-codebases}
 
diff --git a/docs/custom_quantum_functions.md b/docs/custom_quantum_functions.md
index c69beb055e..2c4eac64f0 100644
--- a/docs/custom_quantum_functions.md
+++ b/docs/custom_quantum_functions.md
@@ -145,7 +145,7 @@ void keyboard_pre_init_user(void) {
 
 This is called when the matrix is initialized, and after some of the hardware has been set up, but before many of the features have been initialized.
 
-This is useful for setting up stuff that you may need elsewhere, but isn't hardware related nor is dependant on where it's started.
+This is useful for setting up stuff that you may need elsewhere, but isn't hardware related nor is dependent on where it's started.
 
 
 ### `matrix_init_*` Function Documentation
@@ -209,7 +209,7 @@ You should use this function if you need custom matrix scanning code. It can als
 
 This function gets called at the end of all QMK processing, before starting the next iteration. You can safely assume that QMK has dealt with the last matrix scan at the time that these functions are invoked -- layer states have been updated, USB reports have been sent, LEDs have been updated, and displays have been drawn.
 
-Similar to `matrix_scan_*`, these are called as often as the MCU can handle. To keep your board responsive, it's suggested to do as little as possible during these function calls, potentially throtting their behaviour if you do indeed require implementing something special.
+Similar to `matrix_scan_*`, these are called as often as the MCU can handle. To keep your board responsive, it's suggested to do as little as possible during these function calls, potentially throttling their behaviour if you do indeed require implementing something special.
 
 ### Example `void housekeeping_task_user(void)` implementation
 
@@ -246,7 +246,7 @@ void check_rgb_timeout(void) {
     }
 }
 /* Then, call the above functions from QMK's built in post processing functions like so */
-/* Runs at the end of each scan loop, check if RGB timeout has occured or not */
+/* Runs at the end of each scan loop, check if RGB timeout has occurred or not */
 void housekeeping_task_user(void) {
 #ifdef RGBLIGHT_TIMEOUT
     check_rgb_timeout();
@@ -316,7 +316,7 @@ bool shutdown_kb(bool jump_to_bootloader) {
     if (!shutdown_user(jump_to_bootloader)) {
         return false;
     }
-    
+
     if (jump_to_bootloader) {
         // red for bootloader
         rgb_matrix_set_color_all(RGB_OFF);
diff --git a/docs/drivers/serial.md b/docs/drivers/serial.md
index dda75f629a..2c78f59043 100644
--- a/docs/drivers/serial.md
+++ b/docs/drivers/serial.md
@@ -33,7 +33,7 @@ On ARM platforms the bitbang driver causes connection issues when using it toget
 +-------+                 +-------+
 ```
 
-One GPIO pin is needed for the bitbang driver, as only one wire is used for receiving and transmitting data. This pin is referred to as the `SOFT_SERIAL_PIN` (SSP) in the configuration. A TRS or USB cable provides enough conductors for this driver to function. 
+One GPIO pin is needed for the bitbang driver, as only one wire is used for receiving and transmitting data. This pin is referred to as the `SOFT_SERIAL_PIN` (SSP) in the configuration. A TRS or USB cable provides enough conductors for this driver to function.
 
 ### Setup
 
@@ -63,12 +63,12 @@ SERIAL_DRIVER = bitbang
 
 ## USART Half-duplex
 
-Targeting ARM boards based on ChibiOS, where communication is offloaded to a USART hardware device that supports Half-duplex operation. The advantages over bitbanging are fast, accurate timings and reduced CPU usage. Therefore it is advised to choose Half-duplex over Bitbang if MCU is capable of utilising Half-duplex, and Full-duplex can't be used instead (e.g. lack of available GPIO pins, or imcompatible PCB design).
+Targeting ARM boards based on ChibiOS, where communication is offloaded to a USART hardware device that supports Half-duplex operation. The advantages over bitbanging are fast, accurate timings and reduced CPU usage. Therefore it is advised to choose Half-duplex over Bitbang if MCU is capable of utilising Half-duplex, and Full-duplex can't be used instead (e.g. lack of available GPIO pins, or incompatible PCB design).
 
 ### Pin configuration
 
 ```
-  LEFT                      RIGHT  
+  LEFT                      RIGHT
 +-------+  |           |  +-------+
 |       |  R           R  |       |
 |       |  |   SERIAL  |  |       |
@@ -80,7 +80,7 @@ Targeting ARM boards based on ChibiOS, where communication is offloaded to a USA
 +-------+                 +-------+
 ```
 
-Only one GPIO pin is needed for the Half-duplex driver, as only one wire is used for receiving and transmitting data. This pin is referred to as the `SERIAL_USART_TX_PIN` in the configuration. Ensure that the pin chosen for split communication can operate as the TX pin of the contoller's USART peripheral. A TRS or USB cable provides enough conductors for this driver to function. As the split connection is configured to operate in open-drain mode, an **external pull-up resistor is needed to keep the line high**. Resistor values of 1.5kΩ to 8.2kΩ are known to work. 
+Only one GPIO pin is needed for the Half-duplex driver, as only one wire is used for receiving and transmitting data. This pin is referred to as the `SERIAL_USART_TX_PIN` in the configuration. Ensure that the pin chosen for split communication can operate as the TX pin of the contoller's USART peripheral. A TRS or USB cable provides enough conductors for this driver to function. As the split connection is configured to operate in open-drain mode, an **external pull-up resistor is needed to keep the line high**. Resistor values of 1.5kΩ to 8.2kΩ are known to work.
 
 ::: warning
 ***Note:*** A pull-up resistor isn't required for RP2040 controllers configured with PIO subsystem.
@@ -278,7 +278,7 @@ There are several advanced configuration options that can be defined in your key
 
 ### Baudrate
 
-If you're having issues or need a higher baudrate with serial communication, you can change the baudrate which in turn controls the communication speed for serial. You want to lower the baudrate if you experience failed transactions. 
+If you're having issues or need a higher baudrate with serial communication, you can change the baudrate which in turn controls the communication speed for serial. You want to lower the baudrate if you experience failed transactions.
 
 ```c
 #define SELECT_SOFT_SERIAL_SPEED n
@@ -307,19 +307,19 @@ This is the default time window in milliseconds in which a successful communicat
 
 ## Troubleshooting
 
-If you're having issues withe serial communication, you can enable debug messages that will give you insights which part of the communication failed. The enable these messages add to your keyboards `config.h` file:
+If you're having issues with serial communication, you can enable debug messages that will give you insights which part of the communication failed. The enable these messages add to your keyboards `config.h` file:
 
 ```c
 #define SERIAL_DEBUG
 ```
- 
+
 ::: tip
 The messages will be printed out to the `CONSOLE` output. For additional information, refer to [Debugging/Troubleshooting QMK](../faq_debug).
 :::
 
 ## Alternate Functions for selected STM32 MCUs
 
-Pins for USART Peripherals with 
+Pins for USART Peripherals with
 
 ### STM32F303 / Proton-C [Datasheet](https://www.st.com/resource/en/datasheet/stm32f303cc.pdf)
 
diff --git a/docs/feature_debounce_type.md b/docs/feature_debounce_type.md
index eb29b4ef26..4e3b0f4543 100644
--- a/docs/feature_debounce_type.md
+++ b/docs/feature_debounce_type.md
@@ -47,7 +47,7 @@ susceptible to noise, you must choose a debounce method that will also mitigate
    * Debounce algorithms often have a 'debounce time' parameter, that specifies the maximum settling time of the switch contacts.
      This time might be measured in various units:
      * Cycles-based debouncing waits n cycles (scans), decreasing count by one each matrix_scan
-     * Timestamp-based debouncing stores the millisecond timestamp a change occurred, and does substraction to figure out time elapsed.
+     * Timestamp-based debouncing stores the millisecond timestamp a change occurred, and does subtraction to figure out time elapsed.
    * Timestamp-based debouncing is usually superior, especially in the case of noise-resistant devices because settling times of physical
      switches is specified in units of time, and should not depend on the matrix scan-rate of the keyboard.
    * Cycles-based debouncing is sometimes considered inferior, because the settling time that it is able to compensate for depends on the
diff --git a/docs/feature_eeprom.md b/docs/feature_eeprom.md
index 22257b3202..7d40e81f5a 100644
--- a/docs/feature_eeprom.md
+++ b/docs/feature_eeprom.md
@@ -100,7 +100,7 @@ bool process_record_user(uint16_t keycode, keyrecord_t *record) {
         if (record->event.pressed) { //This disables layer indication, as it's assumed that if you're changing this ... you want that disabled
             if (user_config.rgb_layer_change) {        // only if this is enabled
                 user_config.rgb_layer_change = false;  // disable it, and
-                eeconfig_update_user(user_config.raw); // write the setings to EEPROM
+                eeconfig_update_user(user_config.raw); // write the settings to EEPROM
             }
         }
         return true; break;
@@ -109,7 +109,7 @@ bool process_record_user(uint16_t keycode, keyrecord_t *record) {
   }
 }
 ```
-And lastly, you want to add the `eeconfig_init_user` function, so that when the EEPROM is reset, you can specify default values, and even custom actions. To force an EEPROM reset, use the `EE_CLR` keycode or [Bootmagic](features/bootmagic) functionallity. For example, if you want to set rgb layer indication by default, and save the default valued.
+And lastly, you want to add the `eeconfig_init_user` function, so that when the EEPROM is reset, you can specify default values, and even custom actions. To force an EEPROM reset, use the `EE_CLR` keycode or [Bootmagic](features/bootmagic) functionality. For example, if you want to set rgb layer indication by default, and save the default valued.
 
 ```c
 void eeconfig_init_user(void) {  // EEPROM is getting reset!
diff --git a/docs/feature_layers.md b/docs/feature_layers.md
index da6a28bd88..8e6510ca2a 100644
--- a/docs/feature_layers.md
+++ b/docs/feature_layers.md
@@ -25,7 +25,7 @@ active layer until pressed again.
 
 Currently, the `layer` argument of `LT()` is limited to layers 0-15, and the `kc` argument to the [Basic Keycode set](keycodes_basic), meaning you can't use keycodes like `LCTL()`, `KC_TILD`, or anything greater than `0xFF`. This is because QMK uses 16-bit keycodes, of which 4 bits are used for the function identifier and 4 bits for the layer, leaving only 8 bits for the keycode.
 
-For a similar reason, the `layer` argument of `LM()` is also limited to layers 0-15 and the `mod` argument must fit within 5 bits. As a consequence, although left and right modifiers are supported by `LM()`, it is impossible to mix and match left and right modifiers. Specifying at least one right-hand modifier in a combination such as `MOD_RALT|MOD_LSFT` will convert *all* the listed modifiers to their right-hand counterpart. So, using the aforementionned mod-mask will actually send <kbd>Right Alt</kbd>+<kbd>Right Shift</kbd>. Make sure to use the `MOD_xxx` constants over alternative ways of specifying modifiers when defining your layer-mod key.
+For a similar reason, the `layer` argument of `LM()` is also limited to layers 0-15 and the `mod` argument must fit within 5 bits. As a consequence, although left and right modifiers are supported by `LM()`, it is impossible to mix and match left and right modifiers. Specifying at least one right-hand modifier in a combination such as `MOD_RALT|MOD_LSFT` will convert *all* the listed modifiers to their right-hand counterpart. So, using the aforementioned mod-mask will actually send <kbd>Right Alt</kbd>+<kbd>Right Shift</kbd>. Make sure to use the `MOD_xxx` constants over alternative ways of specifying modifiers when defining your layer-mod key.
 
 | `LM(1,KC_LSFT)` | `LM(1,MOD_MASK_SHIFT)` | `LM(1,MOD_BIT(KC_LSFT))` | `LM(1,MOD_LSFT)` |
 |:---------------:|:----------------------:|:------------------------:|:----------------:|
@@ -61,27 +61,27 @@ Sometimes, you might want to switch between layers in a macro or as part of a ta
 
 There are a number of functions (and variables) related to how you can use or manipulate the layers.
 
-|Function                                      |Description                                                                                              |
-|----------------------------------------------|---------------------------------------------------------------------------------------------------------|
-| `layer_state_set(layer_mask)`                | Directly sets the layer state (avoid unless you know what you are doing).                               |
-| `layer_clear()`                              | Clears all layers (turns them all off).                                                                 |
-| `layer_move(layer)`                          | Turns specified layer on, and all other layers off.                                                     |
-| `layer_on(layer)`                            | Turns specified layer on, leaves all other layers in existing state.                                    |
-| `layer_off(layer)`                           | Turns specified layer off, leaves all other layers in existing state.                                   |
-| `layer_invert(layer)`                        | Inverts/toggles the state of the specified layer                                                        |
-| `layer_or(layer_mask)`                       | Turns on layers based on matching bits between specifed layer and existing layer state.                 |
-| `layer_and(layer_mask)`                      | Turns on layers based on matching enabled bits between specifed layer and existing layer state.         |
-| `layer_xor(layer_mask)`                      | Turns on layers based on non-matching bits between specifed layer and existing layer state.             |
-| `layer_debug(layer_mask)`                    | Prints out the current bit mask and highest active layer to debugger console.                           |
-| `default_layer_set(layer_mask)`              | Directly sets the default layer state (avoid unless you know what you are doing).                       |
-| `default_layer_or(layer_mask)`               | Turns on layers based on matching bits between specifed layer and existing default layer state.         |
-| `default_layer_and(layer_mask)`              | Turns on layers based on matching enabled bits between specifed layer and existing default layer state. |
-| `default_layer_xor(layer_mask)`              | Turns on layers based on non-matching bits between specifed layer and existing default layer state.     |
-| `default_layer_debug(layer_mask)`            | Prints out the current bit mask and highest active default layer to debugger console.                   |
-| [`set_single_default_layer(layer)`](ref_functions.md#setting-the-persistent-default-layer)            | Sets the default layer, but does _not_ write it to persistent memory (EEPROM). | 
-| [`set_single_persistent_default_layer(layer)`](ref_functions.md#setting-the-persistent-default-layer) | Sets the default layer and writes it to persistent memory (EEPROM).  |
-| [`update_tri_layer(x, y, z)`](ref_functions.md#update_tri_layerx-y-z) | Checks if layers `x` and `y` are both on, and sets `z` based on that (on if both on, otherwise off). |
-| [`update_tri_layer_state(state, x, y, z)`](ref_functions.md#update_tri_layer_statestate-x-y-z) | Does the same as `update_tri_layer(x, y, z)`, but from `layer_state_set_*` functions. |
+|Function                                     |Description                                                                                             |
+|---------------------------------------------|--------------------------------------------------------------------------------------------------------|
+|`layer_state_set(layer_mask)`                |Directly sets the layer state (avoid unless you know what you are doing).                               |
+|`layer_clear()`                              |Clears all layers (turns them all off).                                                                 |
+|`layer_move(layer)`                          |Turns specified layer on, and all other layers off.                                                     |
+|`layer_on(layer)`                            |Turns specified layer on, leaves all other layers in existing state.                                    |
+|`layer_off(layer)`                           |Turns specified layer off, leaves all other layers in existing state.                                   |
+|`layer_invert(layer)`                        |Inverts/toggles the state of the specified layer                                                        |
+|`layer_or(layer_mask)`                       |Turns on layers based on matching bits between specified layer and existing layer state.                |
+|`layer_and(layer_mask)`                      |Turns on layers based on matching enabled bits between specified layer and existing layer state.        |
+|`layer_xor(layer_mask)`                      |Turns on layers based on non-matching bits between specified layer and existing layer state.            |
+|`layer_debug(layer_mask)`                    |Prints out the current bit mask and highest active layer to debugger console.                           |
+|`default_layer_set(layer_mask)`              |Directly sets the default layer state (avoid unless you know what you are doing).                       |
+|`default_layer_or(layer_mask)`               |Turns on layers based on matching bits between specified layer and existing default layer state.        |
+|`default_layer_and(layer_mask)`              |Turns on layers based on matching enabled bits between specified layer and existing default layer state.|
+|`default_layer_xor(layer_mask)`              |Turns on layers based on non-matching bits between specified layer and existing default layer state.    |
+|`default_layer_debug(layer_mask)`            |Prints out the current bit mask and highest active default layer to debugger console.                   |
+|[`set_single_default_layer(layer)`](ref_functions.md#setting-the-persistent-default-layer)           |Sets the default layer, but does _not_ write it to persistent memory (EEPROM).                      |
+|[`set_single_persistent_default_layer(layer)`](ref_functions.md#setting-the-persistent-default-layer)|Sets the default layer and writes it to persistent memory (EEPROM).                                 |
+|[`update_tri_layer(x, y, z)`](ref_functions.md#update_tri_layerx-y-z)                                |Checks if layers `x` and `y` are both on, and sets `z` based on that (on if both on, otherwise off).|
+|[`update_tri_layer_state(state, x, y, z)`](ref_functions.md#update_tri_layer_statestate-x-y-z)       |Does the same as `update_tri_layer(x, y, z)`, but from `layer_state_set_*` functions.               |
 
 In addition to the functions that you can call, there are a number of callback functions that get called every time the layer changes. This passes the layer state to the function, where it can be read or modified.
 
@@ -154,7 +154,7 @@ bool process_record_user(uint16_t keycode, keyrecord_t *record) {
   switch (keycode) {
     case KC_CYCLE_LAYERS:
       // Our logic will happen on presses, nothing is done on releases
-      if (!record->event.pressed) { 
+      if (!record->event.pressed) {
         // We've already handled the keycode (doing nothing), let QMK know so no further code is run unnecessarily
         return false;
       }
diff --git a/docs/feature_userspace.md b/docs/feature_userspace.md
index 0f5c4a5f96..2c8c08b38e 100644
--- a/docs/feature_userspace.md
+++ b/docs/feature_userspace.md
@@ -24,10 +24,10 @@ For example,
 
     make planck:jack
 
-Will include the `/users/jack/` folder in the path, along with `/users/jack/rules.mk`.  
+Will include the `/users/jack/` folder in the path, along with `/users/jack/rules.mk`.
 
 ::: warning
-This `name` can be [overridden](#override-default-userspace), if needed.  
+This `name` can be [overridden](#override-default-userspace), if needed.
 :::
 
 ## `Rules.mk`
@@ -38,9 +38,9 @@ It's highly recommended that you use `<name>.c` as the default source file to be
 
     SRC += <name>.c
 
-Additional files may be added in the same way - it's recommended you have one named `<name>`.c/.h to start off with, though. 
+Additional files may be added in the same way - it's recommended you have one named `<name>`.c/.h to start off with, though.
 
-The `/users/<name>/rules.mk` file will be included in the build _after_ the `rules.mk` from your keymap. This allows you to have features in your userspace `rules.mk` that depend on individual QMK features that may or may not be available on a specific keyboard. 
+The `/users/<name>/rules.mk` file will be included in the build _after_ the `rules.mk` from your keymap. This allows you to have features in your userspace `rules.mk` that depend on individual QMK features that may or may not be available on a specific keyboard.
 
 For example, if you have RGB control features shared between all your keyboards that support RGB lighting, you can add support for that if the RGBLIGHT feature is enabled:
 ```make
@@ -82,7 +82,7 @@ You should use the `config.h` for [configuration options](config_options), and t
 
 Please include authorship (your name, GitHub username, email), and optionally [a license that's GPL compatible](https://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses).
 
-You can use this as a template: 
+You can use this as a template:
 ```
 Copyright <year> <name> <email> @<github_username>
 
@@ -100,9 +100,9 @@ You should have received a copy of the GNU General Public License
 along with this program.  If not, see <http://www.gnu.org/licenses/>.
 ```
 
-You'd want to replace the year, name, email and GitHub username with your info. 
+You'd want to replace the year, name, email and GitHub username with your info.
 
-Additionally, this is a good place to document your code, if you wish to share it with others. 
+Additionally, this is a good place to document your code, if you wish to share it with others.
 
 ## Build All Keyboards That Support a Specific Keymap
 
@@ -118,20 +118,21 @@ This is ideal for when you want ensure everything compiles successfully when pre
 
 ## Examples
 
-For a brief example, checkout [`/users/_example/`](https://github.com/qmk/qmk_firmware/tree/master/users/_example).  
-For more complicated examples, checkout the [`awesome-qmk` colletion](https://github.com/qmk/awesome-qmk).
+For a brief example, checkout [`/users/_example/`](https://github.com/qmk/qmk_firmware/tree/master/users/_example).
+
+For more complicated examples, checkout the [`awesome-qmk` collection](https://github.com/qmk/awesome-qmk).
 
 
 ### Customized Functions
 
-QMK has a bunch of [functions](custom_quantum_functions) that have [`_quantum`, `_kb`, and `_user` versions](custom_quantum_functions#a-word-on-core-vs-keyboards-vs-keymap) that you can use.  You will pretty much always want to use the user version of these functions.  But the problem is that if you use them in your userspace, then you don't have a version that you can use in your keymap. 
+QMK has a bunch of [functions](custom_quantum_functions) that have [`_quantum`, `_kb`, and `_user` versions](custom_quantum_functions#a-word-on-core-vs-keyboards-vs-keymap) that you can use.  You will pretty much always want to use the user version of these functions.  But the problem is that if you use them in your userspace, then you don't have a version that you can use in your keymap.
 
-However, you can actually add support for keymap version, so that you can use it in both your userspace and your keymap! 
+However, you can actually add support for keymap version, so that you can use it in both your userspace and your keymap!
 
 
-For instance, let's look at the `layer_state_set_user()` function.  You can enable the [Tri Layer State](ref_functions#olkb-tri-layers) functionality on all of your boards, while also retaining the Tri Layer functionality in your `keymap.c` files. 
+For instance, let's look at the `layer_state_set_user()` function.  You can enable the [Tri Layer State](ref_functions#olkb-tri-layers) functionality on all of your boards, while also retaining the Tri Layer functionality in your `keymap.c` files.
 
-In your `<name.c>` file, you'd want to add this: 
+In your `<name.c>` file, you'd want to add this:
 ```c
 __attribute__ ((weak))
 layer_state_t layer_state_set_keymap (layer_state_t state) {
@@ -143,7 +144,7 @@ layer_state_t layer_state_set_user (layer_state_t state) {
   return layer_state_set_keymap (state);
 }
 ```
-The `__attribute__ ((weak))` part tells the compiler that this is a placeholder function that can then be replaced by a version in your `keymap.c`.  That way, you don't need to add it to your `keymap.c`, but if you do, you won't get any conflicts because the function is the same name. 
+The `__attribute__ ((weak))` part tells the compiler that this is a placeholder function that can then be replaced by a version in your `keymap.c`.  That way, you don't need to add it to your `keymap.c`, but if you do, you won't get any conflicts because the function is the same name.
 
 The `_keymap` part here doesn't matter, it just needs to be something other than `_quantum`, `_kb`, or `_user`, since those are already in use. So you could use `layer_state_set_mine`, `layer_state_set_fn`, or anything else.
 
@@ -151,7 +152,7 @@ You can see a list of this and other common functions in [`template.c`](https://
 
 ### Custom Features
 
-Since the Userspace feature can support a staggering number of boards, you may have boards that you want to enable certain functionality for, but not for others. And you can actually create "features" that you can enable or disable in your own userspace.  
+Since the Userspace feature can support a staggering number of boards, you may have boards that you want to enable certain functionality for, but not for others. And you can actually create "features" that you can enable or disable in your own userspace.
 
 For instance, if you wanted to have a bunch of macros available, but only on certain boards (to save space), you could "hide" them being a `#ifdef MACROS_ENABLED`, and then enable it per board.  To do this, add this to your rules.mk
 ```make
@@ -159,11 +160,11 @@ ifeq ($(strip $(MACROS_ENABLED)), yes)
     OPT_DEFS += -DMACROS_ENABLED
 endif
 ```
-The `OPT_DEFS` setting causes `MACROS_ENABLED` to be defined for your keyboards (note the `-D` in front of the name), and you could use `#ifdef MACROS_ENABLED` to check the status in your c/h files, and handle that code based on that. 
+The `OPT_DEFS` setting causes `MACROS_ENABLED` to be defined for your keyboards (note the `-D` in front of the name), and you could use `#ifdef MACROS_ENABLED` to check the status in your c/h files, and handle that code based on that.
 
 Then you add `MACROS_ENABLED = yes` to the `rules.mk` for you keymap to enable this feature and the code in your userspace.
 
-And in your `process_record_user` function, you'd do something like this: 
+And in your `process_record_user` function, you'd do something like this:
 ```c
 bool process_record_user(uint16_t keycode, keyrecord_t *record) {
   switch (keycode) {
@@ -187,9 +188,9 @@ bool process_record_user(uint16_t keycode, keyrecord_t *record) {
 
 ### Consolidated Macros
 
-If you wanted to consolidate macros and other functions into your userspace for all of your keymaps, you can do that.  This builds upon the [Customized Functions](#customized-functions) example above. This lets you maintain a bunch of macros that are shared between the different keyboards, and allow for keyboard specific macros, too. 
+If you wanted to consolidate macros and other functions into your userspace for all of your keymaps, you can do that.  This builds upon the [Customized Functions](#customized-functions) example above. This lets you maintain a bunch of macros that are shared between the different keyboards, and allow for keyboard specific macros, too.
 
-First, you'd want to go through all of your `keymap.c` files and replace `process_record_user` with `process_record_keymap` instead.   This way, you can still use keyboard specific codes on those boards, and use your custom "global" keycodes as well.   You'll also want to replace `SAFE_RANGE` with `NEW_SAFE_RANGE` so that you wont have any overlapping keycodes
+First, you'd want to go through all of your `keymap.c` files and replace `process_record_user` with `process_record_keymap` instead.   This way, you can still use keyboard specific codes on those boards, and use your custom "global" keycodes as well.   You'll also want to replace `SAFE_RANGE` with `NEW_SAFE_RANGE` so that you won't have any overlapping keycodes
 
 Then add `#include "<name>.h"` to all of your keymap.c files.  This allows you to use these new keycodes without having to redefine them in each keymap.
 
@@ -245,7 +246,7 @@ bool process_record_user(uint16_t keycode, keyrecord_t *record) {
 }
 ```
 
-For boards that may not have a shift button (such as on a macro pad), we need a way to always include the bootloader option.  To do that, add the following to the `rules.mk` in your userspace folder: 
+For boards that may not have a shift button (such as on a macro pad), we need a way to always include the bootloader option.  To do that, add the following to the `rules.mk` in your userspace folder:
 
 ```make
 ifeq ($(strip $(FLASH_BOOTLOADER)), yes)
@@ -255,7 +256,7 @@ endif
 
 This will add a new `KC_MAKE` keycode that can be used in any of your keymaps.  And this keycode will output `make <keyboard>:<keymap>`, making frequent compiling easier.  And this will work with any keyboard and any keymap as it will output the current boards info, so that you don't have to type this out every time.
 
-Also, holding Shift will add the flash target (`:flash`) to the command.  Holding Control will add some commands that will speed up compiling time by processing multiple files at once. 
+Also, holding Shift will add the flash target (`:flash`) to the command.  Holding Control will add some commands that will speed up compiling time by processing multiple files at once.
 
 And for the boards that lack a shift key, or that you want to always attempt the flashing part, you can add `FLASH_BOOTLOADER = yes` to the `rules.mk` of that keymap.
 
diff --git a/docs/features/audio.md b/docs/features/audio.md
index 2f5e5b2d98..a5f770d811 100644
--- a/docs/features/audio.md
+++ b/docs/features/audio.md
@@ -73,16 +73,13 @@ Should you rather choose to generate and use your own sample-table with the DAC
 
 
 ### PWM (software)
-if the DAC pins are unavailable (or the MCU has no usable DAC at all, like STM32F1xx); PWM can be an alternative.
+If the DAC pins are unavailable (or the MCU has no usable DAC at all, like STM32F1xx); PWM can be an alternative.
 Note that there is currently only one speaker/pin supported.
 
-set in `rules.mk`:
-
-`AUDIO_DRIVER = pwm_software` and in `config.h`: 
-`#define AUDIO_PIN C13` (can be any pin) to have the selected pin output a pwm signal, generated from a timer callback which toggles the pin in software.
+To use this feature, set `AUDIO_DRIVER = pwm_software` in `rules.mk` and set `#define AUDIO_PIN C13` (can be any pin) in `config.h` to have the selected pin output a pwm signal, generated from a timer callback which toggles the pin in software.
 
 #### Wiring
-the usual piezo wiring: red goes to the selected AUDIO_PIN, black goes to ground.
+The usual piezo wiring: red goes to the selected AUDIO_PIN, black goes to ground.
 
 OR if you can chose to drive one piezo with two pins, for example `#define AUDIO_PIN B1`, `#define AUDIO_PIN_ALT B2` in `config.h`, with `#define AUDIO_PIN_ALT_AS_NEGATIVE` - then the red lead could go to B1, the black to B2.
 
@@ -159,7 +156,7 @@ PLAY_LOOP(my_song);
 
 It's advised that you wrap all audio features in `#ifdef AUDIO_ENABLE` / `#endif` to avoid causing problems when audio isn't built into the keyboard.
 
-The available keycodes for audio are: 
+The available keycodes for audio are:
 
 |Key                      |Aliases  |Description                                |
 |-------------------------|---------|-------------------------------------------|
@@ -178,8 +175,8 @@ These keycodes turn all of the audio functionality on and off.  Turning it off m
 |`AUDIO_PIN`                       | *Not defined*        |Configures the pin that the speaker is connected to.                                         |
 |`AUDIO_PIN_ALT`                   | *Not defined*        |Configures the pin for a second speaker or second pin connected to one speaker.              |
 |`AUDIO_PIN_ALT_AS_NEGATIVE`       | *Not defined*        |Enables support for one speaker connected to two pins.                                       |
-|`AUDIO_INIT_DELAY`                | *Not defined*        |Enables delay during startup song to accomidate for USB startup issues.                      |
-|`AUDIO_ENABLE_TONE_MULTIPLEXING`  | *Not defined*        |Enables time splicing/multiplexing to create multiple tones simutaneously.                   |
+|`AUDIO_INIT_DELAY`                | *Not defined*        |Enables delay during startup song to accommodate for USB startup issues.                     |
+|`AUDIO_ENABLE_TONE_MULTIPLEXING`  | *Not defined*        |Enables time splicing/multiplexing to create multiple tones simultaneously.                  |
 |`AUDIO_POWER_CONTROL_PIN`         | *Not defined*        |Enables power control code to enable or cut off power to speaker (such as with PAM8302 amp). |
 |`AUDIO_POWER_CONTROL_PIN_ON_STATE`| `1`                  |The state of the audio power control pin when audio is "on" - `1` for high, `0` for low.     |
 |`STARTUP_SONG`                    | `STARTUP_SOUND`      |Plays when the keyboard starts up (audio.c)                                                  |
@@ -301,9 +298,9 @@ Things that return false are not part of the mask, and are always processed.
 
 ### Music Map
 
-By default, the Music Mode uses the columns and row to determine the scale for the keys. For a board that uses a rectangular matrix that matches the keyboard layout, this is just fine.  However, for boards that use a more complicated matrix (such as the Planck Rev6, or many split keyboards) this would result in a very skewed experience.  
+By default, the Music Mode uses the columns and row to determine the scale for the keys. For a board that uses a rectangular matrix that matches the keyboard layout, this is just fine.  However, for boards that use a more complicated matrix (such as the Planck Rev6, or many split keyboards) this would result in a very skewed experience.
 
-However, the Music Map option allows you to remap the scaling for the music mode, so it fits the layout, and is more natural. 
+However, the Music Map option allows you to remap the scaling for the music mode, so it fits the layout, and is more natural.
 
 To enable this feature, add `#define MUSIC_MAP` to your `config.h` file, and then you will want to add a `uint8_t music_map` to your keyboard's `c` file, or your `keymap.c`.
 
@@ -316,13 +313,13 @@ const uint8_t music_map[MATRIX_ROWS][MATRIX_COLS] = LAYOUT_ortho_4x12(
 );
 ```
 
-You will want to use whichever `LAYOUT` macro that your keyboard uses here.  This maps it to the correct key location.  Start in  the bottom left of the keyboard layout, and  move to the right, and then upwards.  Fill in all the entries until you have a complete matrix.  
+You will want to use whichever `LAYOUT` macro that your keyboard uses here.  This maps it to the correct key location.  Start in  the bottom left of the keyboard layout, and  move to the right, and then upwards.  Fill in all the entries until you have a complete matrix.
 
-You can look at the [Planck Keyboard](https://github.com/qmk/qmk_firmware/blob/e9ace1487887c1f8b4a7e8e6d87c322988bec9ce/keyboards/planck/planck.c#L24-L29) as an example of how to implement this. 
+You can look at the [Planck Keyboard](https://github.com/qmk/qmk_firmware/blob/e9ace1487887c1f8b4a7e8e6d87c322988bec9ce/keyboards/planck/planck.c#L24-L29) as an example of how to implement this.
 
 ## Audio Click
 
-This adds a click sound each time you hit a button, to simulate click sounds from the keyboard. And the sounds are slightly different for each keypress, so it doesn't sound like a single long note, if you type rapidly. 
+This adds a click sound each time you hit a button, to simulate click sounds from the keyboard. And the sounds are slightly different for each keypress, so it doesn't sound like a single long note, if you type rapidly.
 
 Keycodes available:
 
@@ -341,7 +338,7 @@ The feature is disabled by default, to save space.  To enable it, add this to yo
 #define AUDIO_CLICKY
 ```
 
-You can configure the default, min and max frequencies, the stepping and built in randomness by defining these values: 
+You can configure the default, min and max frequencies, the stepping and built in randomness by defining these values:
 
 | Option | Default Value | Description |
 |--------|---------------|-------------|
@@ -349,7 +346,7 @@ You can configure the default, min and max frequencies, the stepping and built i
 | `AUDIO_CLICKY_FREQ_MIN` | 65.0f | Sets the lowest frequency (under 60f are a bit buggy). |
 | `AUDIO_CLICKY_FREQ_MAX` | 1500.0f | Sets the highest frequency. Too high may result in coworkers attacking you. |
 | `AUDIO_CLICKY_FREQ_FACTOR` | 1.18921f| Sets the stepping of UP/DOWN key codes.  This is a multiplicative factor.  The default steps the frequency up/down by a musical minor third.  |
-| `AUDIO_CLICKY_FREQ_RANDOMNESS`     |  0.05f |  Sets a factor of randomness for the clicks, Setting this to `0f` will make each click identical, and `1.0f` will make this sound much like the 90's computer screen scrolling/typing effect. | 
+| `AUDIO_CLICKY_FREQ_RANDOMNESS`     |  0.05f |  Sets a factor of randomness for the clicks, Setting this to `0f` will make each click identical, and `1.0f` will make this sound much like the 90's computer screen scrolling/typing effect. |
 | `AUDIO_CLICKY_DELAY_DURATION` | 1 | An integer note duration where 1 is 1/16th of the tempo, or a sixty-fourth note (see `quantum/audio/musical_notes.h` for implementation details). The main clicky effect will be delayed by this duration.  Adjusting this to values around 6-12 will help compensate for loud switches. |
 
 ## MIDI Functionality
diff --git a/docs/features/bootmagic.md b/docs/features/bootmagic.md
index 49fae5ba45..15c2bec293 100644
--- a/docs/features/bootmagic.md
+++ b/docs/features/bootmagic.md
@@ -46,7 +46,7 @@ When [handedness](split_keyboard#setting-handedness) is predetermined via option
     }
 ```
 
-If you pick the top right key for the right half, it is `R05` on the top layout. Within the key matrix below, `R05` is located on row 4 columnn 4. To use that key as the right half's Bootmagic trigger, add these entries to your `config.h` file:
+If you pick the top right key for the right half, it is `R05` on the top layout. Within the key matrix below, `R05` is located on row 4 column 4. To use that key as the right half's Bootmagic trigger, add these entries to your `config.h` file:
 
 ```c
 #define BOOTMAGIC_ROW_RIGHT 4
diff --git a/docs/features/encoders.md b/docs/features/encoders.md
index a674eaa4a6..59f949be65 100644
--- a/docs/features/encoders.md
+++ b/docs/features/encoders.md
@@ -68,7 +68,7 @@ Additionally, if one side does not have an encoder, you can specify `{}` for the
 ```
 
 ::: warning
-Keep in mind that whenver you change the encoder resolution, you will need to reflash the half that has the encoder affected by the change.
+Keep in mind that whenever you change the encoder resolution, you will need to reflash the half that has the encoder affected by the change.
 :::
 
 ## Encoder map {#encoder-map}
diff --git a/docs/features/haptic_feedback.md b/docs/features/haptic_feedback.md
index 52667965a0..08e66ea8e1 100644
--- a/docs/features/haptic_feedback.md
+++ b/docs/features/haptic_feedback.md
@@ -44,14 +44,14 @@ Not all keycodes below will work depending on which haptic mechanism you have ch
 |`QK_HAPTIC_MODE_NEXT`        |`HF_NEXT`| Go to next DRV2605L waveform                          |
 |`QK_HAPTIC_MODE_PREVIOUS`    |`HF_PREV`| Go to previous DRV2605L waveform                      |
 |`QK_HAPTIC_CONTINUOUS_TOGGLE`|`HF_CONT`| Toggle continuous haptic mode on/off                  |
-|`QK_HAPTIC_CONTINUOUS_UP`    |`HF_CONU`| Increase DRV2605L continous haptic strength           |
-|`QK_HAPTIC_CONTINUOUS_DOWN`  |`HF_COND`| Decrease DRV2605L continous haptic strength           |
+|`QK_HAPTIC_CONTINUOUS_UP`    |`HF_CONU`| Increase DRV2605L continuous haptic strength          |
+|`QK_HAPTIC_CONTINUOUS_DOWN`  |`HF_COND`| Decrease DRV2605L continuous haptic strength          |
 |`QK_HAPTIC_DWELL_UP`         |`HF_DWLU`| Increase Solenoid dwell time                          |
 |`QK_HAPTIC_DWELL_DOWN`       |`HF_DWLD`| Decrease Solenoid dwell time                          |
 
 ### Solenoids
 
-The solenoid code supports relay switches, and similar hardware, as well as solenoids. 
+The solenoid code supports relay switches, and similar hardware, as well as solenoids.
 
 For a regular solenoid,  you will need a build a circuit to drive the solenoid through a mosfet as most MCU will not be able to provide the current needed to drive the coil in the solenoid.
 
@@ -75,7 +75,7 @@ For relay switches, the hardware may already contain all of that ciruitry, and j
 |`SOLENOID_BUZZ_NONACTUATED` | `SOLENOID_MIN_DWELL` |Non-Actuated-time when the switch is in buzz mode.            |
 
 * If solenoid buzz is off, then dwell time is how long the "plunger" stays activated. The dwell time changes how the solenoid sounds.
-* If solenoid buzz is on, then dwell time sets the length of the buzz, while `SOLENOID_BUZZ_ACTUATED` and `SOLENOID_BUZZ_NONACTUATED` set the (non-)actuation times withing the buzz period.
+* If solenoid buzz is on, then dwell time sets the length of the buzz, while `SOLENOID_BUZZ_ACTUATED` and `SOLENOID_BUZZ_NONACTUATED` set the (non-)actuation times within the buzz period.
 * With the current implementation, for any of the above time settings, the precision of these settings may be affected by how fast the keyboard is able to scan the matrix.
   Therefore, if the keyboards scanning routine is slow, it may be preferable to set `SOLENOID_DWELL_STEP_SIZE` to a value slightly smaller than the time it takes to scan the keyboard.
 
@@ -104,7 +104,7 @@ Eccentric Rotating Mass vibration motors (ERM) is motor with a off-set weight at
 ```
 ##### LRA
 
-Linear resonant actuators (LRA, also know as a linear vibrator) works different from a ERM. A LRA has a weight and magnet suspended by springs and a voice coil. When the drive signal is applied, the weight would be vibrate on a single axis (side to side or up and down). Since the weight is attached to a spring, there is a resonance effect at a specific frequency. This frequency is where the LRA will operate the most efficiently. Refer to the motor's datasheet for the recommanded range for this frequency.
+Linear resonant actuators (LRA, also know as a linear vibrator) works different from a ERM. A LRA has a weight and magnet suspended by springs and a voice coil. When the drive signal is applied, the weight would be vibrate on a single axis (side to side or up and down). Since the weight is attached to a spring, there is a resonance effect at a specific frequency. This frequency is where the LRA will operate the most efficiently. Refer to the motor's datasheet for the recommended range for this frequency.
 
 ```c
 #define DRV2605L_FB_ERM_LRA 1
@@ -114,7 +114,7 @@ Linear resonant actuators (LRA, also know as a linear vibrator) works different
 /* Please refer to your datasheet for the optimal setting for your specific motor. */
 #define DRV2605L_RATED_VOLTAGE 2
 #define DRV2605L_V_PEAK 2.8
-#define DRV2605L_V_RMS 2.0 
+#define DRV2605L_V_RMS 2.0
 #define DRV2605L_V_PEAK 2.1
 #define DRV2605L_F_LRA 205 /* resonance freq */
 ```
@@ -125,7 +125,7 @@ DRV2605L comes with preloaded library of various waveform sequences that can be
 
 List of waveform sequences from the datasheet:
 
-|seq# | Sequence name          |seq# | Sequence name                  |seq# |Sequence name                           |
+|seq# | Sequence name       |seq# | Sequence name                     |seq# |Sequence name                         |
 |-----|---------------------|-----|-----------------------------------|-----|--------------------------------------|
 | 1   | strong_click            | 43  | lg_dblclick_med_60                | 85  | transition_rampup_med_smooth2        |
 | 2   | strong_click_60         | 44  | lg_dblsharp_tick                  | 86  | transition_rampup_short_smooth1      |
diff --git a/docs/features/pointing_device.md b/docs/features/pointing_device.md
index f25ea1b033..d6dcddcdf0 100644
--- a/docs/features/pointing_device.md
+++ b/docs/features/pointing_device.md
@@ -51,7 +51,7 @@ The ADNS 9800 is an SPI driven optical sensor, that uses laser output for surfac
 | `ADNS9800_CS_PIN`       | (Required) Sets the Chip Select pin connected to the sensor.           | `POINTING_DEVICE_CS_PIN` |
 
 
-The CPI range is 800-8200, in increments of 200. Defaults to 1800 CPI. 
+The CPI range is 800-8200, in increments of 200. Defaults to 1800 CPI.
 
 ### Analog Joystick
 
@@ -258,7 +258,7 @@ To use the paw 3204 sensor, add this to your `rules.mk`
 POINTING_DEVICE_DRIVER = paw3204
 ```
 
-The paw 3204 sensor uses a serial type protocol for communication, and requires an additional light source. 
+The paw 3204 sensor uses a serial type protocol for communication, and requires an additional light source.
 
 | Setting (`config.h`) | Description                                                    | Default                    |
 | -------------------- |--------------------------------------------------------------- | -------------------------- |
@@ -275,7 +275,7 @@ To use the Pimoroni Trackball module, add this to your `rules.mk`:
 POINTING_DEVICE_DRIVER = pimoroni_trackball
 ```
 
-The Pimoroni Trackball module is a I2C based breakout board with an RGB enable trackball. 
+The Pimoroni Trackball module is a I2C based breakout board with an RGB enable trackball.
 
 | Setting (`config.h`)                 | Description                                                                        | Default |
 | ------------------------------------ | ---------------------------------------------------------------------------------- | ------- |
@@ -386,7 +386,7 @@ void           pointing_device_driver_set_cpi(uint16_t cpi) {}
 ```
 
 ::: warning
-Ideally, new sensor hardware should be added to `drivers/sensors/` and `quantum/pointing_device_drivers.c`, but there may be cases where it's very specific to the hardware.  So these functions are provided, just in case. 
+Ideally, new sensor hardware should be added to `drivers/sensors/` and `quantum/pointing_device_drivers.c`, but there may be cases where it's very specific to the hardware.  So these functions are provided, just in case.
 :::
 
 ## Common Configuration
@@ -413,7 +413,7 @@ Ideally, new sensor hardware should be added to `drivers/sensors/` and `quantum/
 When using `SPLIT_POINTING_ENABLE` the `POINTING_DEVICE_MOTION_PIN` functionality is not supported and `POINTING_DEVICE_TASK_THROTTLE_MS` will default to `1`. Increasing this value will increase transport performance at the cost of possible mouse responsiveness.
 :::
 
-The `POINTING_DEVICE_CS_PIN`, `POINTING_DEVICE_SDIO_PIN`, and `POINTING_DEVICE_SCLK_PIN` provide a convenient way to define a single pin that can be used for an interchangeable sensor config.  This allows you to have a single config, without defining each device.  Each sensor allows for this to be overridden with their own defines. 
+The `POINTING_DEVICE_CS_PIN`, `POINTING_DEVICE_SDIO_PIN`, and `POINTING_DEVICE_SCLK_PIN` provide a convenient way to define a single pin that can be used for an interchangeable sensor config.  This allows you to have a single config, without defining each device.  Each sensor allows for this to be overridden with their own defines.
 
 ::: warning
 Any pointing device with a lift/contact status can integrate inertial cursor feature into its driver, controlled by `POINTING_DEVICE_GESTURES_CURSOR_GLIDE_ENABLE`. e.g. PMW3360 can use Lift_Stat from Motion register. Note that `POINTING_DEVICE_MOTION_PIN` cannot be used with this feature; continuous polling of `get_report()` is needed to generate glide reports.
@@ -424,7 +424,7 @@ Any pointing device with a lift/contact status can integrate inertial cursor fea
 | Setting                                  | Description                                                                                                               | Default       |
 | ---------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- | ------------- |
 | `POINTING_DEVICE_HIRES_SCROLL_ENABLE`    | (Optional) Enables high resolution scrolling.                                                                             | _not defined_ |
-| `POINTING_DEVICE_HIRES_SCROLL_MULTIPLIER`| (Optional) Resolution mutiplier value used by high resolution scrolling. Must be between 1 and 127, inclusive.            | `120`         |
+| `POINTING_DEVICE_HIRES_SCROLL_MULTIPLIER`| (Optional) Resolution multiplier value used by high resolution scrolling. Must be between 1 and 127, inclusive.           | `120`         |
 | `POINTING_DEVICE_HIRES_SCROLL_EXPONENT`  | (Optional) Resolution exponent value used by high resolution scrolling. Must be between 0 and 127, inclusive.             | `0`           |
 
 The `POINTING_DEVICE_HIRES_SCROLL_ENABLE` setting enables smooth and continuous scrolling when using trackballs or high-end encoders as mouse wheels (as opposed to the typical stepped behavior of most mouse wheels).
@@ -435,7 +435,7 @@ If even smoother scrolling than provided by this default value is desired, first
 The function `pointing_device_get_hires_scroll_resolution()` can be called to get the pre-computed resolution multiplier value as a `uint16_t`.
 
 ::: warning
-High resolution scrolling usually results in larger and/or more frequent mouse reports. This can result in overflow errors and overloading of the host computer's input buffer. 
+High resolution scrolling usually results in larger and/or more frequent mouse reports. This can result in overflow errors and overloading of the host computer's input buffer.
 To deal with these issues, define `WHEEL_EXTENDED_REPORT` and throttle the rate at which mouse reports are sent.
 :::
 
@@ -465,7 +465,7 @@ If there is a `_RIGHT` configuration option or callback, the [common configurati
 :::
 
 
-## Callbacks and Functions 
+## Callbacks and Functions
 
 | Function                                                      | Description                                                                                                   |
 | ------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- |
@@ -513,7 +513,7 @@ To manually manipulate the mouse reports outside of the `pointing_device_task_*`
 
 * `pointing_device_get_report()` - Returns the current report_mouse_t that represents the information sent to the host computer
 * `pointing_device_set_report(report_mouse_t mouse_report)` - Overrides and saves the report_mouse_t to be sent to the host computer
-* `pointing_device_send()` - Sends the mouse report to the host and zeroes out the report. 
+* `pointing_device_send()` - Sends the mouse report to the host and zeroes out the report.
 
 When the mouse report is sent, the x, y, v, and h values are set to 0 (this is done in `pointing_device_send()`, which can be overridden to avoid this behavior).  This way, button states persist, but movement will only occur once.  For further customization, both `pointing_device_init` and `pointing_device_task` can be overridden.
 
@@ -548,7 +548,7 @@ Recall that the mouse report is set to zero (except the buttons) whenever it is
 
 ### Drag Scroll or Mouse Scroll
 
-A very common implementation is to use the mouse movement to scroll instead of moving the cursor on the system.  This uses the `pointing_device_task_user` callback to intercept and modify the mouse report before it's sent to the host system. 
+A very common implementation is to use the mouse movement to scroll instead of moving the cursor on the system.  This uses the `pointing_device_task_user` callback to intercept and modify the mouse report before it's sent to the host system.
 
 ```c
 enum custom_keycodes {
@@ -575,7 +575,7 @@ bool process_record_user(uint16_t keycode, keyrecord_t *record) {
 }
 ```
 
-This allows you to toggle between scrolling and cursor movement by pressing the DRAG_SCROLL key.  
+This allows you to toggle between scrolling and cursor movement by pressing the DRAG_SCROLL key.
 
 ### Advanced Drag Scroll
 
@@ -711,7 +711,7 @@ If you are having issues with pointing device drivers debug messages can be enab
 ```c
 #define POINTING_DEVICE_DEBUG
 ```
- 
+
 ::: tip
 The messages will be printed out to the `CONSOLE` output. For additional information, refer to [Debugging/Troubleshooting QMK](../faq_debug).
 :::
@@ -720,7 +720,7 @@ The messages will be printed out to the `CONSOLE` output. For additional informa
 ---
 # Automatic Mouse Layer {#pointing-device-auto-mouse}
 
-When using a pointing device combined with a keyboard the mouse buttons are often kept on a separate layer from the default keyboard layer, which requires pressing or holding a key to change layers before using the mouse. To make this easier and more efficient an additional pointing device feature may be enabled that will automatically activate a target layer as soon as the pointing device is active _(in motion, mouse button pressed etc.)_ and deactivate the target layer after a set time.   
+When using a pointing device combined with a keyboard the mouse buttons are often kept on a separate layer from the default keyboard layer, which requires pressing or holding a key to change layers before using the mouse. To make this easier and more efficient an additional pointing device feature may be enabled that will automatically activate a target layer as soon as the pointing device is active _(in motion, mouse button pressed etc.)_ and deactivate the target layer after a set time.
 
 Additionally if any key that is defined as a mouse key is pressed then the layer will be held as long as the key is pressed and the timer will be reset on key release. When a non-mouse key is pressed then the layer is deactivated early _(with some exceptions see below)_.  Mod, mod tap, and one shot mod keys are ignored _(i.e. don't hold or activate layer but do not deactivate the layer either)_ when sending a modifier keycode _(e.g. hold for mod tap)_ allowing for mod keys to be used with the mouse without activating the target layer when typing.
 
@@ -754,8 +754,9 @@ void pointing_device_init_user(void) {
 }
 ```
 
-Because the auto mouse feature can be disabled/enabled during runtime and starts as disabled by default it must be enabled by calling `set_auto_mouse_enable(true);` somewhere in firmware before the feature will work.   
-_Note: for setting the target layer during initialization either setting `AUTO_MOUSE_DEFAULT_LAYER` in `config.h` or calling `set_auto_mouse_layer(<mouse_layer>)` can be used._   
+Because the auto mouse feature can be disabled/enabled during runtime and starts as disabled by default it must be enabled by calling `set_auto_mouse_enable(true);` somewhere in firmware before the feature will work.
+
+_Note: for setting the target layer during initialization either setting `AUTO_MOUSE_DEFAULT_LAYER` in `config.h` or calling `set_auto_mouse_layer(<mouse_layer>)` can be used._
 
 
 ## How to Customize:
@@ -774,7 +775,7 @@ There are a few ways to control the auto mouse feature with both `config.h` opti
 
 ### Adding mouse keys
 
-While all default mouse keys and layer keys(for current mouse layer) are treated as mouse keys, additional Keyrecords can be added to mouse keys by adding them to the is_mouse_record_* stack. 
+While all default mouse keys and layer keys(for current mouse layer) are treated as mouse keys, additional Keyrecords can be added to mouse keys by adding them to the is_mouse_record_* stack.
 
 #### Callbacks for setting up additional key codes as mouse keys:
 | Callback                                                             | Description                                        |
@@ -782,7 +783,7 @@ While all default mouse keys and layer keys(for current mouse layer) are treated
 | `bool is_mouse_record_kb(uint16_t keycode, keyrecord_t* record)`     |  keyboard level callback for adding mouse keys     |
 | `bool is_mouse_record_user(uint16_t keycode, keyrecord_t* record)`   |  user/keymap level callback for adding mouse keys  |
 
-##### To use the callback function to add mouse keys:   
+##### To use the callback function to add mouse keys:
 
 The following code will cause the enter key and all of the arrow keys to be treated as mouse keys (hold target layer while they are pressed and reset active layer timer).
 ```c
@@ -806,7 +807,7 @@ bool is_mouse_record_kb(uint16_t keycode, keyrecord_t* record) {
 
 There are several functions that allow for more advanced interaction with the auto mouse feature allowing for greater control.
 
-### Functions to control auto mouse enable and target layer:   
+### Functions to control auto mouse enable and target layer:
 | Function                                                   | Description                                                                          | Aliases                   |     Return type |
 | :--------------------------------------------------------- | ------------------------------------------------------------------------------------ | ------------------------- | --------------: |
 | `set_auto_mouse_enable(bool enable)`                       | Enable or disable auto mouse (true:enable, false:disable)                            |                           |    `void`(None) |
@@ -825,25 +826,27 @@ There are several functions that allow for more advanced interaction with the au
 | `get_auto_mouse_key_tracker(void)`                         | Gets the current count for the auto mouse key tracker.                               |                           |        `int8_t` |
 | `set_auto_mouse_key_tracker(int8_t key_tracker)`           | Sets/Overrides the current count for the auto mouse key tracker.                     |                           |    `void`(None) |
 
-_NOTES:_   
-    - _Due to the nature of how some functions work, the `auto_mouse_trigger_reset`, and `auto_mouse_layer_off` functions should never be called in the `layer_state_set_*` stack as this can cause indefinite loops._   
-    - _It is recommended that `remove_auto_mouse_layer` is used in the `layer_state_set_*` stack of functions and `auto_mouse_layer_off` is used everywhere else_   
-    - _`remove_auto_mouse_layer(state, false)` or `auto_mouse_layer_off()` should be called before any instance of `set_auto_mouse_enabled(false)` or `set_auto_mouse_layer(layer)` to ensure that the target layer will be removed appropriately before disabling auto mouse or changing target to avoid a stuck layer_      
-    
-### Functions for handling custom key events:   
+_NOTES:_
+
+- _Due to the nature of how some functions work, the `auto_mouse_trigger_reset`, and `auto_mouse_layer_off` functions should never be called in the `layer_state_set_*` stack as this can cause indefinite loops._
+- _It is recommended that `remove_auto_mouse_layer` is used in the `layer_state_set_*` stack of functions and `auto_mouse_layer_off` is used everywhere else_
+- _`remove_auto_mouse_layer(state, false)` or `auto_mouse_layer_off()` should be called before any instance of `set_auto_mouse_enabled(false)` or `set_auto_mouse_layer(layer)` to ensure that the target layer will be removed appropriately before disabling auto mouse or changing target to avoid a stuck layer_
+
+### Functions for handling custom key events:
 | Function                                                   | Description                                                                      |     Return type |
 | :--------------------------------------------------------- | -------------------------------------------------------------------------------- | --------------: |
 | `auto_mouse_keyevent(bool pressed)`                        | Auto mouse mouse key event (true: key down, false: key up)                       |    `void`(None) |
 | `auto_mouse_trigger_reset(bool pressed)`                   | Reset auto mouse status on key down and start delay timer (non-mouse key event)  |    `void`(None) |
 | `auto_mouse_toggle(void)`                                  | Toggle on/off target toggle state (disables layer deactivation when true)        |    `void`(None) |
-| `get_auto_mouse_toggle(void)`                              | Return value of toggling state variable                                          |          `bool` |   
+| `get_auto_mouse_toggle(void)`                              | Return value of toggling state variable                                          |          `bool` |
+
 _NOTE: Generally it would be preferable to use the `is_mouse_record_*` functions to add any additional keys that should act as mouse keys rather than adding `auto_mouse_keyevent(record.event->pressed)` to `process_records_*`_
 
-### Advanced control examples   
+### Advanced control examples
 
-#### Disable auto mouse on certain layers:   
+#### Disable auto mouse on certain layers:
 
-The auto mouse feature can be disabled any time and this can be helpful if you want to disable the auto mouse feature under certain circumstances such as when particular layers are active. One issue however is the handling of the target layer, it needs to be removed appropriately **before** disabling auto mouse _(see notes under control functions above)_. The following function would disable the auto_mouse feature whenever the layers `_LAYER5` through `_LAYER7` are active as the top most layer _(ignoring target layer)_.   
+The auto mouse feature can be disabled any time and this can be helpful if you want to disable the auto mouse feature under certain circumstances such as when particular layers are active. One issue however is the handling of the target layer, it needs to be removed appropriately **before** disabling auto mouse _(see notes under control functions above)_. The following function would disable the auto_mouse feature whenever the layers `_LAYER5` through `_LAYER7` are active as the top most layer _(ignoring target layer)_.
 
 ```c
 // in keymap.c:
@@ -882,7 +885,7 @@ layer_state_t default_layer_state_set_user(layer_state_t state) {
             auto_mouse_layer_off();
             set_auto_mouse_layer(_MOUSE_LAYER_2);
             break;
-        
+
         default:
             if((AUTO_MOUSE_TARGET_LAYER) == _MOUSE_LAYER_1) break;
             auto_mouse_layer_off();
@@ -892,9 +895,11 @@ layer_state_t default_layer_state_set_user(layer_state_t state) {
 }
 ```
 
-### Use custom keys to control auto mouse:  
-Custom key records could also be created that control the auto mouse feature.   
-The code example below would create a custom key that would toggle the auto mouse feature on and off when pressed while also setting a bool that could be used to disable other code that may turn it on such as the layer code above.   
+### Use custom keys to control auto mouse:
+
+Custom key records could also be created that control the auto mouse feature.
+
+The code example below would create a custom key that would toggle the auto mouse feature on and off when pressed while also setting a bool that could be used to disable other code that may turn it on such as the layer code above.
 
 ```c
 // in config.h:
@@ -923,11 +928,11 @@ bool process_record_user(uint16_t keycode, keyrecord_t* record) {
 
 ## Customize Target Layer Activation
 
-Layer activation can be customized by overwriting the `auto_mouse_activation` function. This function is checked every time `pointing_device_task` is called when inactive and every `AUTO_MOUSE_DEBOUNCE` ms when active, and will evaluate pointing device level conditions that trigger target layer activation. When it returns true, the target layer will be activated barring the usual exceptions _(e.g. delay time has not expired)_.   
+Layer activation can be customized by overwriting the `auto_mouse_activation` function. This function is checked every time `pointing_device_task` is called when inactive and every `AUTO_MOUSE_DEBOUNCE` ms when active, and will evaluate pointing device level conditions that trigger target layer activation. When it returns true, the target layer will be activated barring the usual exceptions _(e.g. delay time has not expired)_.
 
 By default it will return true if any of the `mouse_report` axes `x`,`y`,`h`,`v` are non zero, or if there is any mouse buttons active in `mouse_report`.
 _Note: The Cirque pinnacle track pad already implements a custom activation function that will activate on touchdown as well as movement all of the default conditions, currently this only works for the master side of split keyboards._
- 
+
 | Function                                                   | Description                                                                      |     Return type |
 | :--------------------------------------------------------- | -------------------------------------------------------------------------------- | --------------: |
 | `auto_mouse_activation(report_mouse_t mouse_report)`       | Overwritable function that controls target layer activation (when true)          |          `bool` |
@@ -939,12 +944,12 @@ When using a custom pointing device (overwriting `pointing_device_task`) the fol
 ```c
 bool pointing_device_task(void) {
     //...Custom pointing device task code
-    
+
     // handle automatic mouse layer (needs report_mouse_t as input)
     pointing_device_task_auto_mouse(local_mouse_report);
-    
+
     //...More custom pointing device task code
-    
+
     return pointing_device_send();
 }
 ```
diff --git a/docs/features/repeat_key.md b/docs/features/repeat_key.md
index 7f2bdc44e6..543dfd1008 100644
--- a/docs/features/repeat_key.md
+++ b/docs/features/repeat_key.md
@@ -5,7 +5,7 @@ Key after tapping the <kbd>Z</kbd> key types another "`z`." This is useful for
 typing doubled letters, like the `z` in "`dazzle`": a double tap on <kbd>Z</kbd>
 can instead be a roll from <kbd>Z</kbd> to <kbd>Repeat</kbd>, which is
 potentially faster and more comfortable. The Repeat Key is also useful for
-hotkeys, like repeating Ctrl + Shift + Right Arrow to select by word. 
+hotkeys, like repeating Ctrl + Shift + Right Arrow to select by word.
 
 Repeat Key remembers mods that were active with the last key press. These mods
 are combined with any additional mods while pressing the Repeat Key. If the last
@@ -49,10 +49,10 @@ reduce firmware size, Alternate Repeat may be disabled by adding in config.h:
 
 The following alternate keys are defined by default. See
 `get_alt_repeat_key_keycode_user()` below for how to change or add to these
-definitions. Where it makes sense, these definitions also include combinations 
+definitions. Where it makes sense, these definitions also include combinations
 with mods, like Ctrl + Left &harr; Ctrl + Right Arrow.
 
-**Navigation** 
+**Navigation**
 
 |Keycodes                           |Description                        |
 |-----------------------------------|-----------------------------------|
@@ -65,7 +65,7 @@ with mods, like Ctrl + Left &harr; Ctrl + Right Arrow.
 |`MS_WHLL` &harr; `MS_WHLR`         | Mouse Wheel Left &harr; Right     |
 |`MS_WHLU` &harr; `MS_WHLD`         | Mouse Wheel Up &harr; Down        |
 
-**Misc** 
+**Misc**
 
 |Keycodes                           |Description                        |
 |-----------------------------------|-----------------------------------|
@@ -73,7 +73,7 @@ with mods, like Ctrl + Left &harr; Ctrl + Right Arrow.
 |`KC_LBRC` &harr; `KC_RBRC`         | `[` &harr; `]`                    |
 |`KC_LCBR` &harr; `KC_RCBR`         | `{` &harr; `}`                    |
 
-**Media** 
+**Media**
 
 |Keycodes                           |Description                        |
 |-----------------------------------|-----------------------------------|
@@ -176,9 +176,9 @@ macro](../feature_macros). This way macros can be used without having to
 dedicate keys to them. The following defines a couple shortcuts.
 
 * Typing <kbd>K</kbd>, <kbd>Alt Repeat</kbd> produces "`keyboard`," with the
-  initial "`k`" typed as usual and the "`eybord`" produced by the macro. 
+  initial "`k`" typed as usual and the "`eybord`" produced by the macro.
 * Typing <kbd>.</kbd>, <kbd>Alt Repeat</kbd> produces "`../`," handy for "up
-  directory" on the shell. Similary, <kbd>.</kbd> types the initial "`.`" and 
+  directory" on the shell. Similarly, <kbd>.</kbd> types the initial "`.`" and
   "`./`" is produced by the macro.
 
 ```c
@@ -290,7 +290,7 @@ By default, pressing the Repeat Key will simply behave as if the last key
 were pressed again. This also works with macro keys with custom handlers,
 invoking the macro again. In case fine-tuning is needed for sensible repetition,
 you can handle how a key is repeated with `get_repeat_key_count()` within
-`process_record_user()`. 
+`process_record_user()`.
 
 The `get_repeat_key_count()` function returns a signed count of times the key
 has been repeated or alternate repeated. When a key is pressed as usual,
@@ -306,16 +306,16 @@ bool process_record_user(uint16_t keycode, keyrecord_t* record) {
             if (get_repeat_key_count() > 0) {
                 // MY_MACRO is being repeated!
                 if (record->event.pressed) {
-                    SEND_STRING("repeat!");    
+                    SEND_STRING("repeat!");
                 }
-            } else {                          
+            } else {
                 // MY_MACRO is being used normally.
-                if (record->event.pressed) {  
+                if (record->event.pressed) {
                     SEND_STRING("macro");
                 }
             }
             return false;
-     
+
         // Other macros...
     }
     return true;
@@ -347,19 +347,19 @@ bool process_record_user(uint16_t keycode, keyrecord_t* record) {
         case MY_MACRO:
             if (get_repeat_key_count() > 0) {        // Repeating.
                 if (record->event.pressed) {
-                    SEND_STRING("repeat!");    
+                    SEND_STRING("repeat!");
                 }
             } else if (get_repeat_key_count() < 0) { // Alternate repeating.
                 if (record->event.pressed) {
                     SEND_STRING("alt repeat!");
                 }
             } else {                                 // Used normally.
-                if (record->event.pressed) {  
+                if (record->event.pressed) {
                     SEND_STRING("macro");
                 }
             }
             return false;
-     
+
         // Other macros...
     }
     return true;
@@ -377,7 +377,7 @@ bool process_record_user(uint16_t keycode, keyrecord_t* record) {
 | `set_last_mods(mods)`          | Set the mods to apply when repeating.                                  |
 | `get_repeat_key_count()`       | Signed count of times the key has been repeated or alternate repeated. |
 | `get_alt_repeat_key_keycode()` | Keycode to be used for alternate repeating.                            |
- 
+
 
 ## Additional "Alternate" keys
 
@@ -437,7 +437,7 @@ static void process_altrep3(uint16_t keycode, uint8_t mods) {
 
 bool process_record_user(uint16_t keycode, keyrecord_t* record) {
     switch (keycode) {
-        case ALTREP2: 
+        case ALTREP2:
             if (record->event.pressed) {
                 process_altrep2(get_last_keycode(), get_last_mods());
             }
diff --git a/docs/features/rgb_matrix.md b/docs/features/rgb_matrix.md
index b0110b436b..95ee4c4896 100644
--- a/docs/features/rgb_matrix.md
+++ b/docs/features/rgb_matrix.md
@@ -125,13 +125,13 @@ enum rgb_matrix_effects {
     RGB_MATRIX_CYCLE_SPIRAL,        // Full gradient spinning spiral around center of keyboard
     RGB_MATRIX_DUAL_BEACON,         // Full gradient spinning around center of keyboard
     RGB_MATRIX_RAINBOW_BEACON,      // Full tighter gradient spinning around center of keyboard
-    RGB_MATRIX_RAINBOW_PINWHEELS,   // Full dual gradients spinning two halfs of keyboard
+    RGB_MATRIX_RAINBOW_PINWHEELS,   // Full dual gradients spinning two halves of keyboard
     RGB_MATRIX_FLOWER_BLOOMING,     // Full tighter gradient of first half scrolling left to right and second half scrolling right to left
     RGB_MATRIX_RAINDROPS,           // Randomly changes a single key's hue
     RGB_MATRIX_JELLYBEAN_RAINDROPS, // Randomly changes a single key's hue and saturation
-    RGB_MATRIX_HUE_BREATHING,       // Hue shifts up a slight ammount at the same time, then shifts back
-    RGB_MATRIX_HUE_PENDULUM,        // Hue shifts up a slight ammount in a wave to the right, then back to the left
-    RGB_MATRIX_HUE_WAVE,            // Hue shifts up a slight ammount and then back down in a wave to the right
+    RGB_MATRIX_HUE_BREATHING,       // Hue shifts up a slight amount at the same time, then shifts back
+    RGB_MATRIX_HUE_PENDULUM,        // Hue shifts up a slight amount in a wave to the right, then back to the left
+    RGB_MATRIX_HUE_WAVE,            // Hue shifts up a slight amount and then back down in a wave to the right
     RGB_MATRIX_PIXEL_FRACTAL,       // Single hue fractal filled keys pulsing horizontally out to edges
     RGB_MATRIX_PIXEL_FLOW,          // Pulsing RGB flow along LED wiring with random hues
     RGB_MATRIX_PIXEL_RAIN,          // Randomly light keys with random hues
@@ -240,7 +240,7 @@ In order to change the delay of temperature decrease define `RGB_MATRIX_TYPING_H
 
 As heatmap uses the physical position of the leds set in the g_led_config, you may need to tweak the following options to get the best effect for your keyboard. Note the size of this grid is `224x64`.
 
-Limit the distance the effect spreads to surrounding keys. 
+Limit the distance the effect spreads to surrounding keys.
 
 ```c
 #define RGB_MATRIX_TYPING_HEATMAP_SPREAD 40
@@ -406,8 +406,8 @@ const char* effect_name = rgb_matrix_get_mode_name(rgb_matrix_get_mode());
 #define RGB_MATRIX_VAL_STEP 16 // The value by which to increment the brightness per adjustment action
 #define RGB_MATRIX_SPD_STEP 16 // The value by which to increment the animation speed per adjustment action
 #define RGB_MATRIX_DEFAULT_FLAGS LED_FLAG_ALL // Sets the default LED flags, if none has been set
-#define RGB_MATRIX_SPLIT { X, Y }       // (Optional) For split keyboards, the number of LEDs connected on each half. X = left, Y = Right.
-                                        // If reactive effects are enabled, you also will want to enable SPLIT_TRANSPORT_MIRROR
+#define RGB_MATRIX_SPLIT { X, Y } // (Optional) For split keyboards, the number of LEDs connected on each half. X = left, Y = Right.
+                                  // If reactive effects are enabled, you also will want to enable SPLIT_TRANSPORT_MIRROR
 #define RGB_TRIGGER_ON_KEYDOWN      // Triggers RGB keypress events on key down. This makes RGB control feel more responsive. This may cause RGB to not function properly on some boards
 ```
 
diff --git a/docs/features/space_cadet.md b/docs/features/space_cadet.md
index 0abdaebf33..66761f5a46 100644
--- a/docs/features/space_cadet.md
+++ b/docs/features/space_cadet.md
@@ -32,7 +32,7 @@ COMMAND_ENABLE = no
 
 ## Configuration
 
-By default Space Cadet assumes a US ANSI layout, but if your layout uses different keys for parentheses, you can redefine them in your `config.h`. In addition, you can redefine the modifier to send on tap, or even send no modifier at all. The new configuration defines bundle all options up into a single define of 3 key codes in this order: the `Modifier` when held or when used with other keys, the `Tap Modifer` sent when tapped (no modifier if `KC_TRNS`), finally the `Keycode` sent when tapped. Now keep in mind, mods from other keys will still apply to the `Keycode` if say `KC_RSFT` is held while tapping `SC_LSPO` key with `KC_TRNS` as the `Tap Modifer`.
+By default Space Cadet assumes a US ANSI layout, but if your layout uses different keys for parentheses, you can redefine them in your `config.h`. In addition, you can redefine the modifier to send on tap, or even send no modifier at all. The new configuration defines bundle all options up into a single define of 3 key codes in this order: the `Modifier` when held or when used with other keys, the `Tap Modifier` sent when tapped (no modifier if `KC_TRNS`), finally the `Keycode` sent when tapped. Now keep in mind, mods from other keys will still apply to the `Keycode` if say `KC_RSFT` is held while tapping `SC_LSPO` key with `KC_TRNS` as the `Tap Modifier`.
 
 |Define          |Default                        |Description                                                                      |
 |----------------|-------------------------------|---------------------------------------------------------------------------------|
diff --git a/docs/features/split_keyboard.md b/docs/features/split_keyboard.md
index fbf5d3d3e2..4b299b14f8 100644
--- a/docs/features/split_keyboard.md
+++ b/docs/features/split_keyboard.md
@@ -1,12 +1,12 @@
-# Split Keyboard 
+# Split Keyboard
 
-Many keyboards in the QMK Firmware repo are "split" keyboards. They use two controllers—one plugging into USB, and the second connected by a serial or an I<sup>2</sup>C connection over a TRRS or similar cable. 
+Many keyboards in the QMK Firmware repo are "split" keyboards. They use two controllers—one plugging into USB, and the second connected by a serial or an I<sup>2</sup>C connection over a TRRS or similar cable.
 
-Split keyboards can have a lot of benefits, but there is some additional work needed to get them enabled.  
+Split keyboards can have a lot of benefits, but there is some additional work needed to get them enabled.
 
-QMK Firmware has a generic implementation that is usable by any board, as well as numerous board specific implementations. 
+QMK Firmware has a generic implementation that is usable by any board, as well as numerous board specific implementations.
 
-For this, we will mostly be talking about the generic implementation used by the Let's Split and other keyboards. 
+For this, we will mostly be talking about the generic implementation used by the Let's Split and other keyboards.
 
 ::: warning
 ARM split supports most QMK subsystems when using the 'serial' and 'serial_usart' drivers. I2C slave is currently unsupported.
@@ -29,33 +29,33 @@ Notes:
 
 ## Hardware Configuration
 
-This assumes that you're using two Pro Micro-compatible controllers, and are using TRRS jacks to connect to two halves. 
+This assumes that you're using two Pro Micro-compatible controllers, and are using TRRS jacks to connect to two halves.
 
 ### Required Hardware
 
 Apart from diodes and key switches for the keyboard matrix in each half, you will need 2x TRRS sockets and 1x TRRS cable.
 
-Alternatively, you can use any sort of cable and socket that has at least 3 wires. 
+Alternatively, you can use any sort of cable and socket that has at least 3 wires.
 
 If you want to use I<sup>2</sup>C to communicate between halves, you will need a cable with at least 4 wires and 2x 4.7kΩ pull-up resistors.
 
-#### Considerations 
+#### Considerations
 
-The most commonly used connection is a TRRS cable and jacks.  These provide 4 wires, making them very useful for split keyboards, and are easy to find. 
+The most commonly used connection is a TRRS cable and jacks.  These provide 4 wires, making them very useful for split keyboards, and are easy to find.
 
-However, since one of the wires carries VCC, this means that the boards are not hot pluggable. You should always disconnect the board from USB before unplugging and plugging in TRRS cables, or you can short the controller, or worse. 
+However, since one of the wires carries VCC, this means that the boards are not hot pluggable. You should always disconnect the board from USB before unplugging and plugging in TRRS cables, or you can short the controller, or worse.
 
-Another option is to use phone cables (as in, old school RJ-11/RJ-14 cables). Make sure that you use one that actually supports 4 wires/lanes.  
+Another option is to use phone cables (as in, old school RJ-11/RJ-14 cables). Make sure that you use one that actually supports 4 wires/lanes.
 
-However, USB cables, SATA cables, and even just 4 wires have been known to be used for communication between the controllers. 
+However, USB cables, SATA cables, and even just 4 wires have been known to be used for communication between the controllers.
 
 ::: warning
-Using USB cables for communication between the controllers works just fine, but the connector could be mistaken for a normal USB connection and potentially short out the keyboard, depending on how it's wired.  For this reason, they are not recommended for connecting split keyboards.  
+Using USB cables for communication between the controllers works just fine, but the connector could be mistaken for a normal USB connection and potentially short out the keyboard, depending on how it's wired.  For this reason, they are not recommended for connecting split keyboards.
 :::
 
 ### Serial Wiring
 
-The 3 wires of the TRS/TRRS cable need to connect GND, VCC, and D0/D1/D2/D3 (aka PD0/PD1/PD2/PD3) between the two Pro Micros. 
+The 3 wires of the TRS/TRRS cable need to connect GND, VCC, and D0/D1/D2/D3 (aka PD0/PD1/PD2/PD3) between the two Pro Micros.
 
 ::: tip
 Note that the pin used here is actually set by `SOFT_SERIAL_PIN` below.
@@ -66,7 +66,7 @@ Note that the pin used here is actually set by `SOFT_SERIAL_PIN` below.
 
 ### I<sup>2</sup>C Wiring
 
-The 4 wires of the TRRS cable need to connect GND, VCC, and SCL and SDA (aka PD0/pin 3 and PD1/pin 2, respectively) between the two Pro Micros. 
+The 4 wires of the TRRS cable need to connect GND, VCC, and SCL and SDA (aka PD0/pin 3 and PD1/pin 2, respectively) between the two Pro Micros.
 
 The pull-up resistors may be placed on either half. If you wish to use the halves independently, it is also possible to use 4 resistors and have the pull-ups in both halves.
 Note that the total resistance for the connected system should be within spec at 2.2k-10kOhm, with an 'ideal' at 4.7kOhm, regardless of the placement and number.
@@ -75,13 +75,13 @@ Note that the total resistance for the connected system should be within spec at
 
 ## Firmware Configuration
 
-To enable the split keyboard feature, add the following to your `rules.mk`: 
+To enable the split keyboard feature, add the following to your `rules.mk`:
 
 ```make
 SPLIT_KEYBOARD = yes
 ```
 
-If you're using a custom transport (communication method), then you will also need to add: 
+If you're using a custom transport (communication method), then you will also need to add:
 
 ```make
 SPLIT_TRANSPORT = custom
@@ -109,7 +109,7 @@ You can configure the firmware to read a pin on the controller to determine hand
 #define SPLIT_HAND_PIN B7
 ```
 
-This will read the specified pin. By default, if it's high, then the controller assumes it is the left hand, and if it's low, it's assumed to be the right side. 
+This will read the specified pin. By default, if it's high, then the controller assumes it is the left hand, and if it's low, it's assumed to be the right side.
 
 This behaviour can be flipped by adding this to you `config.h` file:
 
@@ -141,10 +141,10 @@ While `MATRIX_MASKED` isn't necessary to use `SPLIT_HAND_MATRIX_GRID` successful
 
 #### Handedness by EEPROM
 
-This method sets the keyboard's handedness by setting a flag in the persistent storage (`EEPROM`).  This is checked when the controller first starts up, and determines what half the keyboard is, and how to orient the keyboard layout. 
+This method sets the keyboard's handedness by setting a flag in the persistent storage (`EEPROM`).  This is checked when the controller first starts up, and determines what half the keyboard is, and how to orient the keyboard layout.
 
 
-To enable this method, add the following to your `config.h` file: 
+To enable this method, add the following to your `config.h` file:
 
 ```c
 #define EE_HANDS
@@ -176,7 +176,7 @@ Some controllers (e.g. Blackpill with DFU compatible bootloader) will need to be
 [QMK Toolbox](https://github.com/qmk/qmk_toolbox/releases/) can also be used to flash EEPROM handedness files. Place the controller in bootloader mode and select menu option Tools -> EEPROM -> Set Left/Right Hand
 :::
 
-This setting is not changed when re-initializing the EEPROM using the `EE_CLR` key, or using the `eeconfig_init()` function.  However, if you reset the EEPROM outside of the firmware's built in options (such as flashing a file that overwrites the `EEPROM`, like how the [QMK Toolbox](https://github.com/qmk/qmk_toolbox/releases/)'s "Reset EEPROM" button works), you'll need to re-flash the controller with the `EEPROM` files. 
+This setting is not changed when re-initializing the EEPROM using the `EE_CLR` key, or using the `eeconfig_init()` function.  However, if you reset the EEPROM outside of the firmware's built in options (such as flashing a file that overwrites the `EEPROM`, like how the [QMK Toolbox](https://github.com/qmk/qmk_toolbox/releases/)'s "Reset EEPROM" button works), you'll need to re-flash the controller with the `EEPROM` files.
 
 You can find the `EEPROM` files in the QMK firmware repo, [here](https://github.com/qmk/qmk_firmware/tree/master/quantum/split_common).
 
@@ -208,13 +208,13 @@ Because not every split keyboard is identical, there are a number of additional
 #define USE_I2C
 ```
 
-This configures the use of I<sup>2</sup>C support for split keyboard transport (AVR only).  
+This configures the use of I<sup>2</sup>C support for split keyboard transport (AVR only).
 
 ```c
 #define SOFT_SERIAL_PIN D0
 ```
 
-This sets the pin to be used for serial communication. If you're not using serial, you shouldn't need to define this.  
+This sets the pin to be used for serial communication. If you're not using serial, you shouldn't need to define this.
 
 However, if you are using serial and I<sup>2</sup>C on the board, you will need to set this, and to something other than D0 and D1 (as these are used for I<sup>2</sup>C communication).
 
@@ -235,7 +235,7 @@ If you're having issues with serial communication, you can change this value, as
 #define FORCED_SYNC_THROTTLE_MS 100
 ```
 
-This sets the maximum number of milliseconds before forcing a synchronization of data from master to slave. Under normal circumstances this sync occurs whenever the data _changes_, for safety a data transfer occurs after this number of milliseconds if no change has been detected since the last sync. 
+This sets the maximum number of milliseconds before forcing a synchronization of data from master to slave. Under normal circumstances this sync occurs whenever the data _changes_, for safety a data transfer occurs after this number of milliseconds if no change has been detected since the last sync.
 
 ```c
 #define SPLIT_MAX_CONNECTION_ERRORS 10
@@ -249,7 +249,7 @@ Set to 0 to disable the disconnection check altogether.
 ```
 How long (in milliseconds) the master part should block all connection attempts to the slave after the communication has been flagged as disconnected (see `SPLIT_MAX_CONNECTION_ERRORS` above).
 
-One communication attempt will be allowed everytime this amount of time has passed since the last attempt. If that attempt succeeds, the communication is seen as working again.
+One communication attempt will be allowed every time this amount of time has passed since the last attempt. If that attempt succeeds, the communication is seen as working again.
 
 Set to 0 to disable this throttling of communications while disconnected. This can save you a couple of bytes of firmware size.
 
@@ -280,7 +280,7 @@ This enables syncing of the Host LED status (caps lock, num lock, etc) between b
 #define SPLIT_MODS_ENABLE
 ```
 
-This enables transmitting modifier state (normal, weak, oneshot and oneshot locked) to the non primary side of the split keyboard. The purpose of this feature is to support cosmetic use of modifer state (e.g. displaying status on an OLED screen).
+This enables transmitting modifier state (normal, weak, oneshot and oneshot locked) to the non primary side of the split keyboard. The purpose of this feature is to support cosmetic use of modifier state (e.g. displaying status on an OLED screen).
 
 ```c
 #define SPLIT_WPM_ENABLE
@@ -304,7 +304,7 @@ This enables transmitting the current ST7565 on/off status to the slave side of
 #define SPLIT_POINTING_ENABLE
 ```
 
-This enables transmitting the pointing device status to the master side of the split keyboard. The purpose of this feature is to enable use pointing devices on the slave side. 
+This enables transmitting the pointing device status to the master side of the split keyboard. The purpose of this feature is to enable use pointing devices on the slave side.
 
 ::: warning
 There is additional required configuration for `SPLIT_POINTING_ENABLE` outlined in the [pointing device documentation](pointing_device#split-keyboard-configuration).
@@ -401,7 +401,7 @@ By default, the inbound and outbound data is limited to a maximum of 32 bytes ea
 
 ### Hardware Configuration Options
 
-There are some settings that you may need to configure, based on how the hardware is set up. 
+There are some settings that you may need to configure, based on how the hardware is set up.
 
 ```c
 #define MATRIX_ROW_PINS_RIGHT { <row pins> }
@@ -433,7 +433,7 @@ This option enables synchronization of the RGB Light modes between the controlle
 #define RGBLED_SPLIT { 6, 6 }
 ```
 
-This sets how many LEDs are directly connected to each controller.  The first number is the left side, and the second number is the right side.  
+This sets how many LEDs are directly connected to each controller.  The first number is the left side, and the second number is the right side.
 
 ::: tip
 This setting implies that `RGBLIGHT_SPLIT` is enabled, and will forcibly enable it, if it's not.
@@ -479,7 +479,7 @@ This set the maximum slave timeout when waiting for communication from master wh
 
 Master/slave delegation is made either by detecting voltage on VBUS connection or waiting for USB communication (`SPLIT_USB_DETECT`). Pro Micro boards can use VBUS detection out of the box and be used with or without `SPLIT_USB_DETECT`.
 
-Many ARM boards, but not all, do not support VBUS detection. Because it is common that ARM boards lack VBUS detection, `SPLIT_USB_DETECT` is automatically defined on ARM targets (technically when ChibiOS is targetted).
+Many ARM boards, but not all, do not support VBUS detection. Because it is common that ARM boards lack VBUS detection, `SPLIT_USB_DETECT` is automatically defined on ARM targets (technically when ChibiOS is targeted).
 
 ### Teensy boards
 
@@ -501,7 +501,7 @@ You may need to use the 5V pad from the regulator block above as the pads were t
 
 ## Additional Resources
 
-Nicinabox has a [very nice and detailed guide](https://github.com/nicinabox/lets-split-guide) for the Let's Split keyboard, that covers most everything you need to know, including troubleshooting information. 
+Nicinabox has a [very nice and detailed guide](https://github.com/nicinabox/lets-split-guide) for the Let's Split keyboard, that covers most everything you need to know, including troubleshooting information.
 
 However, the RGB Light section is out of date, as it was written long before the RGB Split code was added to QMK Firmware. Instead, wire each strip up directly to the controller.
 
diff --git a/docs/features/st7565.md b/docs/features/st7565.md
index de3e44d8e9..09a1efce30 100644
--- a/docs/features/st7565.md
+++ b/docs/features/st7565.md
@@ -182,12 +182,12 @@ void st7565_render(void);
 void st7565_set_cursor(uint8_t col, uint8_t line);
 
 // Advances the cursor to the next page, writing ' ' if true
-// Wraps to the begining when out of bounds
+// Wraps to the beginning when out of bounds
 void st7565_advance_page(bool clearPageRemainder);
 
 // Moves the cursor forward 1 character length
 // Advance page if there is not enough room for the next character
-// Wraps to the begining when out of bounds
+// Wraps to the beginning when out of bounds
 void st7565_advance_char(void);
 
 // Writes a single character to the buffer at current cursor position
diff --git a/docs/features/stenography.md b/docs/features/stenography.md
index 4176344b5a..b253890e13 100644
--- a/docs/features/stenography.md
+++ b/docs/features/stenography.md
@@ -102,7 +102,7 @@ STENO_ENABLE = yes
 STENO_PROTOCOL = all
 ```
 
-If you want to switch protocols programatically, as part of a custom macro for example, don't use `tap_code(QK_STENO_*)`, as `tap_code` only supports [basic keycodes](../keycodes_basic). Instead, you should use `steno_set_mode(STENO_MODE_*)`, whose valid arguments are `STENO_MODE_BOLT` and `STENO_MODE_GEMINI`.
+If you want to switch protocols programmatically, as part of a custom macro for example, don't use `tap_code(QK_STENO_*)`, as `tap_code` only supports [basic keycodes](../keycodes_basic). Instead, you should use `steno_set_mode(STENO_MODE_*)`, whose valid arguments are `STENO_MODE_BOLT` and `STENO_MODE_GEMINI`.
 
 The default protocol is Gemini PR but the last protocol used is stored in non-volatile memory so QMK will remember your choice between reboots of your keyboard &mdash; assuming that your keyboard features (emulated) EEPROM.
 
diff --git a/docs/hand_wire.md b/docs/hand_wire.md
index be21cf2cc4..492ca384b1 100644
--- a/docs/hand_wire.md
+++ b/docs/hand_wire.md
@@ -162,7 +162,7 @@ The pins you'll absolutely have to avoid, as with any controller, are: GND, VCC,
 
 Cut wires to the length of the distance from the a point on each column/row to the controller.  You can solder anywhere along the row, as long as it's after the diode - soldering before the diode (on the keyswitch side) will cause that row not to work.
 
-Ribbon cable can be used to keep this extra tidy.  You may also want to consider routing the wires beneath the exisiting columns/rows.
+Ribbon cable can be used to keep this extra tidy.  You may also want to consider routing the wires beneath the existing columns/rows.
 
 <img src="https://i.imgur.com/z2QlKfB.jpg" alt="Ribbon Cable" width="350"/>
 
@@ -188,7 +188,7 @@ qmk import-kbfirmware /path/to/export.json
 For example:
 
 ```
-$ qmk import-kbfirmware ~/Downloads/gh62.json 
+$ qmk import-kbfirmware ~/Downloads/gh62.json
 Ψ Importing gh62.json.
 
 ⚠ Support here is basic - Consider using 'qmk new-keyboard' instead
@@ -227,16 +227,16 @@ If you've done all of these things, keep in mind that sometimes you might have h
 
 ## Finishing up
 
-Once you have confirmed that the keyboard is working, if you have used a seperate (non handwire specific) controller you will want to secure it in place.  This can be done in many different ways e.g. hot glue, double sided sticky tape, 3D printed caddy, electrical tape.
+Once you have confirmed that the keyboard is working, if you have used a separate (non handwire specific) controller you will want to secure it in place.  This can be done in many different ways e.g. hot glue, double sided sticky tape, 3D printed caddy, electrical tape.
 
-If you found this fullfilling you could experiment by adding additional features such as [in switch LEDs](https://geekhack.org/index.php?topic=94258.0), [in switch RGB](https://www.reddit.com/r/MechanicalKeyboards/comments/5s1l5u/photoskeyboard_science_i_made_a_handwired_rgb/), [RGB underglow](https://medium.com/@DavidNZ/hand-wired-custom-keyboard-cdd14429c7b3#.7a1ovebsk) or even an [OLED display!](https://www.reddit.com/r/olkb/comments/5zy7og/adding_ssd1306_oled_display_to_your_build/) 
+If you found this fulfilling you could experiment by adding additional features such as [in switch LEDs](https://geekhack.org/index.php?topic=94258.0), [in switch RGB](https://www.reddit.com/r/MechanicalKeyboards/comments/5s1l5u/photoskeyboard_science_i_made_a_handwired_rgb/), [RGB underglow](https://medium.com/@DavidNZ/hand-wired-custom-keyboard-cdd14429c7b3#.7a1ovebsk) or even an [OLED display!](https://www.reddit.com/r/olkb/comments/5zy7og/adding_ssd1306_oled_display_to_your_build/)
 
 There are a lot of possibilities inside the firmware - explore [the documentation](/) for a full feature list, and dive into the different keyboards to see how people use all of them. You can always stop by [the OLKB subreddit](https://reddit.com/r/olkb) or [QMK Discord](https://discord.gg/qmk) for help!
 
 ## Links to Other Guides
 
 - [matt3o's step by step guide (BrownFox build)](https://deskthority.net/viewtopic.php?f=7&t=6050) also his [website](https://matt3o.com/hand-wiring-a-custom-keyboard/) and [video guide](https://www.youtube.com/watch?v=LVzpsjFWPP4)
-- [Cribbit's "Modern hand wiring guide - stronger, cleaner, easier"](https://geekhack.org/index.php?topic=87689.0) 
+- [Cribbit's "Modern hand wiring guide - stronger, cleaner, easier"](https://geekhack.org/index.php?topic=87689.0)
 - [Sasha Solomon's "Building my first Keyboard"](https://medium.com/@sachee/building-my-first-keyboard-and-you-can-too-512c0f8a4c5f)
 - [RoastPotatoes' "How to hand wire a Planck"](https://blog.roastpotatoes.co/guide/2015/11/04/how-to-handwire-a-planck/)
 - [Masterzen's "Handwired keyboard build log"](https://www.masterzen.fr/2018/12/16/handwired-keyboard-build-log-part-1/)
diff --git a/docs/hardware_drivers.md b/docs/hardware_drivers.md
index 694d46971a..40a25d9fa7 100644
--- a/docs/hardware_drivers.md
+++ b/docs/hardware_drivers.md
@@ -24,7 +24,7 @@ Support for WS2811/WS2812{a,b,c} LED's. For more information see the [RGB Light]
 
 ## IS31FL3731
 
-Support for up to 2 drivers. Each driver impliments 2 charlieplex matrices to individually address LEDs using I2C. This allows up to 144 same color LEDs or 32 RGB LEDs. For more information on how to setup the driver see the [RGB Matrix](features/rgb_matrix) page.
+Support for up to 2 drivers. Each driver implements 2 charlieplex matrices to individually address LEDs using I2C. This allows up to 144 same color LEDs or 32 RGB LEDs. For more information on how to setup the driver see the [RGB Matrix](features/rgb_matrix) page.
 
 ## IS31FL3733
 
diff --git a/docs/quantum_painter_lvgl.md b/docs/quantum_painter_lvgl.md
index 40b3c3b2f1..0ff0e321ec 100644
--- a/docs/quantum_painter_lvgl.md
+++ b/docs/quantum_painter_lvgl.md
@@ -5,7 +5,7 @@ LVGL (Light and Versatile Graphics Library) is an open-source graphics library p
 LVGL integrates with [Quantum Painter's](quantum_painter) API and drivers to render to the display, the hardware supported by Quantum Painter is also supported by LVGL.
 
 ::: tip
-Keep in mind that enabling the LVGL integration has a big impact in firmware size, it is recommeded to use a supported MCU with >256 kB of flash space.
+Keep in mind that enabling the LVGL integration has a big impact in firmware size, it is recommended to use a supported MCU with >256 kB of flash space.
 :::
 
 To learn more about LVGL and how to use it please take a look at their [official documentation](https://docs.lvgl.io/8.2/intro/)
@@ -35,7 +35,7 @@ static painter_device_t display;
 void keyboard_post_init_kb(void) {
     display = qp_make_.......;         // Create the display
     qp_init(display, QP_ROTATION_0);   // Initialise the display
-    
+
     if (qp_lvgl_attach(display)) {     // Attach LVGL to the display
         ...Your code to draw           // Run LVGL specific code to draw
     }
diff --git a/docs/squeezing_avr.md b/docs/squeezing_avr.md
index c3f3d3c6e1..458b442d59 100644
--- a/docs/squeezing_avr.md
+++ b/docs/squeezing_avr.md
@@ -5,14 +5,14 @@ AVR is severely resource-constrained, and as QMK continues to grow, it is approa
 However, if you need to reduce the compiled size of your firmware to fit the controller's limited flash size, there are a number of options to do so.
 
 ## `rules.mk` Settings
-First and foremost is enabling link time optimization. To do so, add this to your rules.mk: 
+First and foremost is enabling link time optimization. To do so, add this to your rules.mk:
 ```make
 LTO_ENABLE = yes
 ```
 This will cause the final step to take longer, but should get you a smaller compiled size. This also disables Action Functions, and Action Macros, both of which are deprecated.
 This will get you the most savings, in most situations.
 
-From there, disabling extraneous systems will help -- e.g.: 
+From there, disabling extraneous systems will help -- e.g.:
 ```make
 CONSOLE_ENABLE = no
 COMMAND_ENABLE = no
@@ -21,10 +21,10 @@ EXTRAKEY_ENABLE = no
 ```
 This disables some of the functionality that you may not need. But note that extrakeys disables stuff like the media keys and system volume control.
 
-If that isn't enough to get your firmware down to size, then there are some additional features that you can disable: 
+If that isn't enough to get your firmware down to size, then there are some additional features that you can disable:
 ```make
 SPACE_CADET_ENABLE = no
-GRAVE_ESC_ENABLE = no 
+GRAVE_ESC_ENABLE = no
 MAGIC_ENABLE = no
 ```
 These features are enabled by default, but they may not be needed. Double check to make sure. The [Magic Keycodes](keycodes_magic) are the largest and control things like NKRO toggling, GUI and ALT/CTRL swapping, etc. Disabling them will disable those functions. See [Magic Functions](#magic-functions) for disabling related functions.
@@ -51,7 +51,7 @@ Starting with Lock Key support. If you have a Cherry MX Lock switch (lucky you!)
 #undef LOCKING_SUPPORT_ENABLE
 #undef LOCKING_RESYNC_ENABLE
 ```
-Oneshots. If you're not using these, you can disable the feature by adding this to your `config.h`: 
+Oneshots. If you're not using these, you can disable the feature by adding this to your `config.h`:
 ```c
 #define NO_ACTION_ONESHOT
 ```
@@ -61,7 +61,7 @@ The same with tapping keys (mod tap, layer tap, etc)
 ```
 ## Audio Settings
 
-If you're using the Audio feature, by default that includes the music mode feature. This tranlates matrix positions into notes. It's neat for sure, but most likely, you're not using it. You can disable it by adding this to your `config.h`:
+If you're using the Audio feature, by default that includes the music mode feature. This translates matrix positions into notes. It's neat for sure, but most likely, you're not using it. You can disable it by adding this to your `config.h`:
 ```c
 #define NO_MUSIC_MODE
 ```
@@ -124,7 +124,7 @@ into this:
     oled_write_P(PSTR("WPM: "), false);
     oled_write(get_u8_str(get_current_wpm(), ' '), false);
 ```
-which outputs `WPM:   5`. Or this: 
+which outputs `WPM:   5`. Or this:
 ```c
     // NEW CODE
     oled_write_P(PSTR("WPM: "), false);
diff --git a/docs/usb_nkro.txt b/docs/usb_nkro.txt
index d9f1d12292..5817291b6b 100644
--- a/docs/usb_nkro.txt
+++ b/docs/usb_nkro.txt
@@ -58,7 +58,7 @@ USB NKRO methods
 
 Report Format
 -------------
-Other report formats than followings are possible, though these format are typical one.
+Other report formats than following are possible, though these format are typical one.
 
 1. Standard             8bytes
     modifiers(bitmap)       1byte