feat: infinite timeout for leader key (qmk#6580)

* feat: implement leader_no_timeout logic * docs(leader_key): infinite leader timeout docs
BorisTestov · Apr 25, 2021 · 0ab03b3 · 0ab03b3
1 parent 67b8d91
commit 0ab03b3
Show file tree

Hide file tree

Showing 3 changed files with 25 additions and 2 deletions.
diff --git a/docs/feature_leader_key.md b/docs/feature_leader_key.md
@@ -72,6 +72,19 @@ SEQ_THREE_KEYS(KC_C, KC_C, KC_C) {
 }
 ```
 
+## Infinite Leader key timeout
+
+Sometimes your leader key is not on a comfortable places as the rest of keys on your sequence. Imagine that your leader key is one of your outer top right keys, you may need to reposition your hand just to reach your leader key.
+This can make typing the entire sequence on time hard even if you are able to type most of the sequence fast. For example, if your sequence is `Leader + asd` typing `asd` fast is very easy once you have your hands in your home row. However starting the sequence in time after moving your hand out of the home row to reach the leader key and back is not.
+To remove the stress this situation produces to your hands you can enable an infinite timeout just for the leader key. This mean that, after you hit the leader key you will have an infinite amount of time to start the rest of the sequence, allowing you to proper position your hands on the best position to type the rest of the sequence comfortably.
+This infinite timeout only affects the leader key, so in our previous example of `Leader + asd` you will have an infinite amount of time between `Leader` and `a`, but once you start the sequence the timeout you have configured (global or per key) will work normally.
+This way you can configure a very short `LEADER_TIMEOUT` but still have plenty of time to position your hands.
+
+In order to enable this, place this in your `config.h`:
+```c
+#define LEADER_NO_TIMEOUT
+```
+
 ## Strict Key Processing
 
 By default, the Leader Key feature will filter the keycode out of [`Mod-Tap`](mod_tap.md) and [`Layer Tap`](feature_layers.md#switching-and-toggling-layers) functions when checking for the Leader sequences. That means if you're using `LT(3, KC_A)`, it will pick this up as `KC_A` for the sequence, rather than `LT(3, KC_A)`, giving a more expected behavior for newer users.

diff --git a/quantum/process_keycode/process_leader.c b/quantum/process_keycode/process_leader.c
@@ -49,7 +49,10 @@ bool process_leader(uint16_t keycode, keyrecord_t *record) {
     // Leader key set-up
     if (record->event.pressed) {
         if (leading) {
-            if (timer_elapsed(leader_time) < LEADER_TIMEOUT) {
+#    ifndef LEADER_NO_TIMEOUT
+            if (timer_elapsed(leader_time) < LEADER_TIMEOUT)
+#    endif  // LEADER_NO_TIMEOUT
+            {
 #    ifndef LEADER_KEY_STRICT_KEY_PROCESSING
                 if ((keycode >= QK_MOD_TAP && keycode <= QK_MOD_TAP_MAX) || (keycode >= QK_LAYER_TAP && keycode <= QK_LAYER_TAP_MAX)) {
                     keycode = keycode & 0xFF;

diff --git a/quantum/process_keycode/process_leader.h b/quantum/process_keycode/process_leader.h
@@ -35,4 +35,11 @@ void qk_leader_start(void);
     extern uint16_t leader_time;        \
     extern uint16_t leader_sequence[5]; \
     extern uint8_t  leader_sequence_size
-#define LEADER_DICTIONARY() if (leading && timer_elapsed(leader_time) > LEADER_TIMEOUT)
+
+#ifdef LEADER_NO_TIMEOUT
+    #define LEADER_DICTIONARY() if (leading && leader_sequence_size > 0 && timer_elapsed(leader_time) > LEADER_TIMEOUT)
+#else
+    #define LEADER_DICTIONARY() if (leading && timer_elapsed(leader_time) > LEADER_TIMEOUT)
+#endif
+
+#endif