]> git.donarmstrong.com Git - qmk_firmware.git/commitdiff
Updated Home (markdown)
authorskullydazed <skullydazed@users.noreply.github.com>
Fri, 17 Feb 2017 00:34:35 +0000 (16:34 -0800)
committerskullydazed <skullydazed@users.noreply.github.com>
Fri, 17 Feb 2017 00:34:35 +0000 (16:34 -0800)
Home.md

diff --git a/Home.md b/Home.md
index f73690518d0c34ee2f0be3ec32c03598130fe451..85e384403d6bf8f2b02f66ea896ac060b1368729 100644 (file)
--- a/Home.md
+++ b/Home.md
@@ -236,6 +236,27 @@ For a value of `4` for this imaginary setting. So we `undef` it first, then `def
 
 You can then override any settings, rather than having to copy and paste the whole thing.
 
 
 You can then override any settings, rather than having to copy and paste the whole thing.
 
+### Prevent stuck modifiers
+
+Consider the following scenario:
+
+1. Layer 0 has a key defined as Shift.
+2. The same key is defined on layer 1 as the letter A.
+3. User presses Shift.
+4. User switches to layer 1 for whatever reason.
+5. User releases Shift, or rather the letter A.
+6. User switches back to layer 0.
+
+Shift was actually never released and is still considered pressed.
+
+If such situation bothers you add this to your `config.h`:
+
+    #define PREVENT_STUCK_MODIFIERS
+
+This option uses 5 bytes of memory per every 8 keys on the keyboard
+rounded up (5 bits per key). For example on Planck (48 keys) it uses
+(48/8)\*5 = 30 bytes.
+
 # Going beyond the keycodes
 
 Aside from the [basic keycodes](https://github.com/qmk/qmk_firmware/wiki/Keycodes), your keymap can include shortcuts to common operations.
 # Going beyond the keycodes
 
 Aside from the [basic keycodes](https://github.com/qmk/qmk_firmware/wiki/Keycodes), your keymap can include shortcuts to common operations.
@@ -260,27 +281,6 @@ Hit the semicolon key once, send a semicolon. Hit it twice, rapidly -- send a co
 
 `DF(layer)` - sets default layer to *layer*. The default layer is the one at the "bottom" of the layer stack - the ultimate fallback layer. This currently does not persist over power loss. When you plug the keyboard back in, layer 0 will always be the default. It is theoretically possible to work around that, but that's not what `DF` does.
 
 
 `DF(layer)` - sets default layer to *layer*. The default layer is the one at the "bottom" of the layer stack - the ultimate fallback layer. This currently does not persist over power loss. When you plug the keyboard back in, layer 0 will always be the default. It is theoretically possible to work around that, but that's not what `DF` does.
 
-## Prevent stuck modifiers
-
-Consider the following scenario:
-
-1. Layer 0 has a key defined as Shift.
-2. The same key is defined on layer 1 as the letter A.
-3. User presses Shift.
-4. User switches to layer 1 for whatever reason.
-5. User releases Shift, or rather the letter A.
-6. User switches back to layer 0.
-
-Shift was actually never released and is still considered pressed.
-
-If such situation bothers you add this to your `config.h`:
-
-    #define PREVENT_STUCK_MODIFIERS
-
-This option uses 5 bytes of memory per every 8 keys on the keyboard
-rounded up (5 bits per key). For example on Planck (48 keys) it uses
-(48/8)\*5 = 30 bytes.
-
 ## Macro shortcuts: Send a whole string when pressing just one key
 
 Instead of using the `ACTION_MACRO` function, you can simply use `M(n)` to access macro *n* - *n* will get passed into the `action_get_macro` as the `id`, and you can use a switch statement to trigger it. This gets called on the keydown and keyup, so you'll need to use an if statement testing `record->event.pressed` (see keymap_default.c).
 ## Macro shortcuts: Send a whole string when pressing just one key
 
 Instead of using the `ACTION_MACRO` function, you can simply use `M(n)` to access macro *n* - *n* will get passed into the `action_get_macro` as the `id`, and you can use a switch statement to trigger it. This gets called on the keydown and keyup, so you'll need to use an if statement testing `record->event.pressed` (see keymap_default.c).