[Core] Flow Tap tap-hold option to disable HRMs during fast typing (aka Global Quick Tap, Require Prior Idle).

[getreuer]

Adds Flow Tap as a core tap-hold option to disable HRMs during fast typing, aka Global Quick Tap, Require Prior Idle.

Description

I previously developed a Tap Flow community module, inspired by @filterpaper's Contextual Mod-Taps, to disable home row mods during fast typing. This PR implements Tap Flow / Flow Tap as a core QMK option. This solves a couple limitations that the module version has. Notable, the module version is unable to act on tap-hold keys that are also used in a combo. In this core implementation, the logic can be added in the proper place to work nicely with combos.

Flow Tap modifies mod-tap MT and layer-tap LT keys such that when pressed within a short timeout of the preceding key, the tapping behavior is triggered. It basically disables the hold behavior during fast typing, creating a "flow of taps." It also helps to reduce the input lag of tap-hold keys during fast typing, since the tapped behavior is sent immediately.

Naming

There are multiple reasonable ways to name this option. Some pre-existing names:

• "Global Quick Tap," being effectively an extended version of Quick Tap.
• "Require Prior Idle," named to describe the condition to decide a hold.

The name "Flow Tap" is a good one with the rationale that, one, it's short, and additionally, it's illustrative of the intended result that fast typing is a "flow of taps." It also parallels the existing "Quick Tap" and "Chordal Hold" names in a fitting way. I've named the option that way here. I'm open to renaming if there's strong favor for something else.

Implementation notes

The interesting changes are in action_tapping.c. In the Chordal Hold PR #24560, I added a "registered_taps" array in action_tapping.c to remember tapped tap-hold keys, so that they release correctly. I reuse that logic here for Flow Tap, which makes this PR relatively straightforward. Essentially, when the timing condition is met, register the tap-hold key as tapped.

How to use Flow Tap

To enable Flow Tap, define FLOW_TAP_TERM in your config.h. I recommend a timeout of 150 ms as a starting point:

#define FLOW_TAP_TERM 150

By default, Flow Tap is enabled when:

• The tap-hold key is pressed within FLOW_TAP_TERM milliseconds of the previous key press.

• The tapping keycodes of the previous key and tap-hold key are both among KC_A–KC_Z, KC_COMM, KC_DOT, KC_SCLN, KC_SLSH (the main alphas area of a conventional QWERTY layout) or KC_SPC. The idea is that this should work reasonably even if the layout is remapped on the host to an alt layout or international layout (e.g. Dvorak or AZERTY), where these same key positions are mostly used for typing letters.

As an exception to the above, Flow Tap is temporarily disabled while a tap-hold key is undecided. This is to allow chording multiple mod-tap keys without having to wait out the Flow Tap term.

Optionally, Flow Tap may be customized by defining the is_flow_tap_key() and get_flow_tap_term() callbacks. Please see the documentation added in tap_hold.md for details.

Types of Changes

• Core
• Bugfix
• New feature
• Enhancement/optimization
• Keyboard (addition or update)
• Keymap/layout (addition or update)
• Documentation

Issues Fixed or Closed by This PR

• [Feature Request] Implement ZMK's require-prior-idle-ms in QMK #24262

Checklist

• My code follows the code style of this project: C, Python
• I have read the PR Checklist document and have made the appropriate changes.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• I have tested the changes and verified that they work and don't break anything (as well as I can manage).

[filterpaper]

I suggest the name "Tap Flow" with the rationale that, one, it's short, and additionally, it's illustrative of the intended result that fast typing is a "flow of taps." I've named the option that way here. I'm open to renaming if there's strong favor for something else.

"Flow Tap" (or a name ending with tap) might sound better together with "Chordal Hold". It isn't a strong preference because creating descriptive names for arcane features isn't easy.

[getreuer]

I suggest the name "Tap Flow" with the rationale that, one, it's short, and additionally, it's illustrative of the intended result that fast typing is a "flow of taps." I've named the option that way here. I'm open to renaming if there's strong favor for something else.

"Flow Tap" (or a name ending with tap) might sound better together with "Chordal Hold". It isn't a strong preference because creating descriptive names for arcane features isn't easy.

@filterpaper thank you for that suggestion! "Flow Tap" is clever. It parallels "Chordal Hold" (and "Quick Tap" too!) in fitting way. I've updated the name.

[KarlK90]

Code LGTM and I have been daily driving this since the PR was opened - together with chordal hold this feels very natural with HRMs.

[mwpardue]

I used the tap_flow community module first and it was great, but this core implementation is awesome. It feels very natural, as KarlK90 said, and makes HRM much more usable for me. I don't expect I'll ever use a QMK keyboard without flow_tap enabled.

I do have two small issues, but I'm not sure yet if it's my configuration or an actual issue. I am using QWERTY on a ZSA Voyager, not using Oryx.

Relevant configurations:

Default TAPPING_TERM 200
FLOW_TAP_TERM 175
QUICK_TAP_TERM 175 (RGUI_T(KC_J) key only, other keys in the sequence are 0
PERMISSIVE_HOLD true
CHORDAL_HOLD true

[HOLD]LCTL_T(KC_A) + [HOLD]LALT_T(KC_S) + [TAP]KC_H
RELEASE ALL 
Immediately [HOLD]RGUI_T(KC_J) + [TAP]KC_T

The last step, pressing GUI+T, is initiated within the flow_tap term. When I press RGUI_T(KC_J) the J key will be registered as a repeating tap but if I wait out the flow_tap term (still holding RGUI_T(KC_J)) then tap KC_T, the RGUI_T(KC_J) key gets converted to a hold. I'm not sure if this is to be expected but it seems the ideal behavior would be that it would either be a tap or a hold, but converting after registering as a tap is odd.

One other scenario I've encountered is as follows:

[HOLD]LALT_T(KC_S) + [TAP]KC_H
Still holding LALT_T(KC_S), add a [HOLD]LCTL_T(KC_A) and [TAP]KC_H.

In this scenario, if the flow_tap term hasn't expired from the first KC_H then when I try to add LCTL it registers as a tap, even though LALT_T(KC_S) has already settled as a hold and hasn't been released. Again, not sure if this is expected behavior but it does interrupt the flow and seems to me it might be a use case to look at.

Even with the couple of very minor things above flow_tap is a HUGE improvement to HRM on QMK and is an amazing contribution! Thank you, @getreuer.

[getreuer]

Thank you @KarlK90 for trying it out and for the approval!

[getreuer]

@mwpardue thank you for the support and detailed feedback!

You raise an interesting point. Both of those scenarios are fast, back-to-back hotkeys. They are "working as expected" so far as what logic I intended to implement, but I see this logic has a gap in achieving the intended idea. The idea is that Flow Tap is active during "normal typing," and this shouldn't include hotkeys use.

To fix that, I just pushed a commit to this PR to tweak the default get_flow_tap_key() to return false when a mod other than Shift or AltGr is active, so it won't fire on a tap-hold key used following a hotkey. This is just the default, so as needed the user can choose to redefine it as they see fit.

[mwpardue]

@mwpardue thank you for the support and detailed feedback!

You raise an interesting point. Both of those scenarios are fast, back-to-back hotkeys. They are "working as expected" so far as what logic I intended to implement, but I see this logic has a gap in achieving the intended idea. The idea is that Flow Tap is active during "normal typing," and this shouldn't include hotkeys use.

To fix that, I just pushed a commit to this PR to tweak the default get_flow_tap_key() to return false when a mod other than Shift or AltGr is active, so it won't fire on a tap-hold key used following a hotkey. This is just the default, so as needed the user can choose to redefine it as they see fit.

I've pulled the changes and have a bit more feedback. Sorry, I don't mean to be a PITA so if I get too nitpicky please tell me.

I had get_flow_tap_term defined and as a result your changes didn't have any effect until I removed my get_flow_tap_term definitions. Personally I would say the get_flow_tap_term definition should be secondary to the is_flow_tap_key function, but I'm not sure of all the implications to that. Once I removed my get_flow_tap_term definitions your changes fixed my second use case in my previous reply.

Disregard that other use case that I said was buggy. I'm an idiot. It was working precisely as intended, I just kept testing by jumping into my browser where I use Vimium and it just so happened all the tests I performed were keys that worked the same with and without the GUI modifier, and so I thought it was converting to a hold.

[getreuer]

@mwpardue yes, sorry for the trouble. I appreciate all the feedback! As you've worked out, get_flow_tap_term() (being the more elaborate configuration function) takes precedence over is_flow_tap_key(). I'm not seeing a better way to structure it to avoid this, unfortunately.

I've put a "tip" note about this in docs, which render as blue boxes on docs.qmk.fm, to warn about that.

[mwpardue]

@mwpardue yes, sorry for the trouble. I appreciate all the feedback! As you've worked out, get_flow_tap_term() (being the more elaborate configuration function) takes precedence over is_flow_tap_key(). I'm not seeing a better way to structure it to avoid this, unfortunately.

I've put a "tip" note about this in docs, which render as blue boxes on docs.qmk.fm, to warn about that.

I think it may actually be fine. I was reviewing and I realized that my get_flow_tap_term() definition was missing the is_flow_tap_key() checks; I'm not sure why. Maybe an early version of the community module didn't have that check? I just updated the existing function I already had defined when I pulled this PR, so I could have missed that. But once I put it back the is_tap_flow_key() check seems to allowing tap_flow to bypass the term from get_flow_tap_term() when those modifiers are in a held state. I'll continue to test and let you know if I come across anything else, but right now tap_flow is working great!!

[filterpaper]

This pull request should also resolve #24860

[NikGovorov]

Awesome to see the Tap Flow module coming to core with support for streaks and combos — also, I love the new name!

After some brief testing, I have just one question: shouldn't we add an is_flow_tap_key check before updating last_input?

[amarz45]

As an exception to the above, Flow Tap is temporarily disabled while a tap-hold key is undecided. This is to allow chording multiple mod-tap keys without having to wait out the Flow Tap term.

I tried to get rid of this behaviour by defining is_flow_tap_key in my keymap.c file, but I tested it and it doesn’t work. Below is the contents of my keymap.c file, located in keyboards/keychron/v4/ansi. Notice that I commented out that the lines that disable flow tap on hotkeys.

/* Copyright 2021 @ Keychron (https://www.keychron.com)
 *
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 2 of the License, or
 * (at your option) any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program.  If not, see <http://www.gnu.org/licenses/>.
 */

#include QMK_KEYBOARD_H

bool is_flow_tap_key(uint16_t keycode) {
    //if ((get_mods() & (MOD_MASK_CG | MOD_BIT_LALT)) != 0) {
        //return false; // Disable Flow Tap on hotkeys.
    //}
    switch (get_tap_keycode(keycode)) {
        case KC_SPC:
        case KC_A ... KC_Z:
        case KC_DOT:
        case KC_COMM:
        case KC_SCLN:
        case KC_SLSH:
            return true;
    }
    return false;
}

// clang-format off

enum layers {
    MAC_BASE,
    WIN_BASE,
    _FN1,
    _FN2,
    _FN3
};

#define KC_TASK LGUI(KC_TAB)
#define KC_FLXP LGUI(KC_E)

const uint16_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = {
    [MAC_BASE] = LAYOUT_60_ansi(
        KC_ESC,  KC_1,     KC_2,    KC_3,    KC_4,    KC_5,    KC_6,    KC_7,    KC_8,    KC_9,    KC_0,     KC_MINS,  KC_EQL,   KC_BSPC,
        KC_TAB,  KC_Q,     KC_W,    KC_E,    KC_R,    KC_T,    KC_Y,    KC_U,    KC_I,    KC_O,    KC_P,     KC_LBRC,  KC_RBRC,  KC_BSLS,
        KC_CAPS, KC_A,     KC_S,    KC_D,    KC_F,    KC_G,    KC_H,    KC_J,    KC_K,    KC_L,    KC_SCLN,  KC_QUOT,            KC_ENT,
        KC_LSFT,           KC_Z,    KC_X,    KC_C,    KC_V,    KC_B,    KC_N,    KC_M,    KC_COMM, KC_DOT,   KC_SLSH,            KC_RSFT,
        KC_LCTL, KC_LOPT,  KC_LCMD,                            KC_SPC,                             KC_RCMD,  MO(_FN1), MO(_FN3), KC_RCTL),

    [WIN_BASE] = LAYOUT_60_ansi(
        KC_ESC,  KC_1,     KC_2,    KC_3,    KC_4,    KC_5,    KC_6,    KC_7,    KC_8,    KC_9,    KC_0,     KC_MINS,  KC_EQL,   KC_BSPC,
        KC_TAB,  KC_Q,     KC_W,    KC_E,    KC_R,    KC_T,    KC_Y,    KC_U,    KC_I,    KC_O,    KC_P,     KC_LBRC,  KC_RBRC,  KC_BSLS,
        KC_CAPS, KC_A,     KC_S,    MT(MOD_LALT, KC_D),    MT(MOD_LCTL, KC_F),    KC_G,    KC_H,    MT(MOD_RCTL, KC_J),    MT(MOD_LALT, KC_K),    KC_L,    KC_SCLN,  KC_QUOT,            KC_ENT,
        KC_LSFT,           KC_Z,    KC_X,    KC_C,    KC_V,    KC_B,    KC_N,    KC_M,    KC_COMM, KC_DOT,   KC_SLSH,            KC_RSFT,
        KC_LCTL, KC_LALT,  KC_LWIN,                            MT(MOD_LGUI, KC_SPC),                             KC_RALT,  MO(_FN2), MO(_FN3), KC_RCTL),

    [_FN1] = LAYOUT_60_ansi(
        KC_GRV,  KC_BRID,  KC_BRIU, KC_NO,   KC_NO,   RM_VALD, RM_VALU, KC_MPRV, KC_MPLY, KC_MNXT, KC_MUTE,  KC_VOLD,  KC_VOLU,  RM_NEXT,
        RM_TOGG, RM_NEXT,  RM_VALU, RM_HUEU, RM_SATU, RM_SPDU, _______, _______, _______, _______, KC_INS,   KC_PGUP,  KC_HOME,  _______,
        _______, RM_PREV,  RM_VALD, RM_HUED, RM_SATD, RM_SPDD, _______, _______, KC_UP,   _______, KC_PGDN,  KC_END,             _______,
        _______,           _______, _______, _______, _______, _______, NK_TOGG, KC_LEFT, KC_DOWN, KC_RIGHT, KC_DEL,             _______,
        _______, _______,  _______,                            _______,                            _______,  _______,  _______,  _______),

    [_FN2] = LAYOUT_60_ansi(
        KC_GRV,  KC_BRID,  KC_BRIU, KC_TASK, KC_FLXP, RM_VALD, RM_VALU, KC_MPRV, KC_MPLY, KC_MNXT, KC_MUTE,  KC_VOLD,  KC_VOLU,  RM_NEXT,
        RM_TOGG, RM_NEXT,  RM_VALU, RM_HUEU, RM_SATU, RM_SPDU, _______, _______, KC_APP,  KC_SCRL, KC_INS,   KC_PGUP,  KC_HOME,  _______,
        _______, RM_PREV,  RM_VALD, RM_HUED, RM_SATD, RM_SPDD, _______, _______, KC_UP,   KC_PSCR, KC_PGDN,  KC_END,             _______,
        _______,           _______, _______, _______, _______, _______, NK_TOGG, KC_LEFT, KC_DOWN, KC_RIGHT, KC_DEL,             _______,
        _______, _______,  _______,                            _______,                            _______,  _______,  _______,  _______),

    [_FN3] = LAYOUT_60_ansi(
        KC_TILD, KC_F1,    KC_F2,   KC_F3,   KC_F4,   KC_F5,   KC_F6,   KC_F7,   KC_F8,   KC_F9,   KC_F10,   KC_F11,   KC_F12,   _______,
        RM_TOGG, RM_NEXT,  RM_VALU, RM_HUEU, RM_SATU, RM_SPDU, _______, _______, _______, _______, _______,  _______,  _______,  _______,
        _______, RM_PREV,  RM_VALD, RM_HUED, RM_SATD, RM_SPDD, _______, _______, _______, _______, _______,  _______,            _______,
        _______,           _______, _______, _______, _______, _______, _______, _______, _______, _______,  _______,            _______,
        _______, _______,  _______,                            _______,                            _______,  _______,  _______,  _______)
};

[amarz45]

Ignore my previous comment because I figured out the issue. I’m experiencing something similar to this:

Hey, so IDK if I should keep responding here since it's already been merged, but I do still see that flow_tap doesn't appear to update the last_input time when a tap-hold key is tapped. It only updates if a "plain" keycode is tapped. This leads to some misfires when stringing together multiple mod-tap keys, especially when a SHIFT mod-tap precedes another key. It doesn't come up really often on QWERTY but I'm sure a layout like COLEMAK would really be affected.

I have D, F, J, K, and Space set to tap-hold keys. For the following quick sequence:

1. F down
2. F up
3. J down

J is treated as a tap-hold key instead of a tap key. This issue does not occur if I start with a tap key. I’m pretty sure this is a bug.

[getreuer]

Thanks all for the feedback!

After some brief testing, I have just one question: shouldn't we add an is_flow_tap_key check before updating last_input?

@NikGovorov Fair question. This is effectively baked into get_flow_tap_term() in this way:

If is_flow_tap_key() would return false for the previous key, then correspondingly the default definition of get_flow_tap_term() returns a timeout of 0. It is impossible to meet this timeout, so this has the effect that Flow Tap is disabled when is_flow_tap_key() returns false.

The is_flow_tap_key() callback is used only in defining get_flow_tap_term(), since this makes it easier to reason about what should happen if the user redefines these callbacks for customization. The user may choose to reuse is_flow_tap_key() or not, and whatever logic they do, it takes precedence over is_flow_tap_key().

I have D, F, J, K, and Space set to tap-hold keys. For the following quick sequence:

1. F down
2. F up
3. J down

J is treated as a tap-hold key instead of a tap key. This issue does not occur if I start with a tap key. I’m pretty sure this is a bug.

@amarz45 thanks for reporting! I am able to repro this. Interestingly a rolled press "F↓, J↓, F↑, J↑" works as intended (and is covered by a unit test), but the incorrect behavior occurs on distinct taps "F↓, F↑, J↓, J↑." I'll fix this.

[NikGovorov]

@getreuer I've reviewed the code again, and I see that you're absolutely right. However, for some reason - which I admit seems a bit strange - I believe that the get_flow_tap_term function doesn't return 0 in certain cases. Here's a specific use case I've encountered:

1. Q down;
2. Q up;
3. LT(NAV, KC_SPC) down;
4. KC_RIGHT down;
5. KC_RIGHT up;
6. LT(NAV, KC_SPC) up;
7. MT(MOD_LCTL, KC_T) down;
8. U down;
9. U up;
10. MT(MOD_LCTL, KC_T) up;

bool is_flow_tap_key(uint16_t keycode) {
    if (IS_QK_LAYER_TAP(keycode)) {
        return false;
    }
    if ((get_mods() & (MOD_MASK_CG | MOD_BIT_LALT)) != 0) {
        return false; // Disable Flow Tap on hotkeys.
    }
    switch (get_tap_keycode(keycode)) {
        case KC_SPC:
        case KC_A ... KC_Z:
        case KC_DOT:
        case KC_COMM:
        case KC_SCLN:
        case KC_SLSH:
            return true;
    }
    return false;
}

If I add is_flow_tap_key check to

qmk_firmware/quantum/action_tapping.c

Line 169 in 988d815

if (IS_NOEVENT(tapping_key.event) && !IS_MODIFIER_KEYCODE(keycode)) {

then the scenario begins to behave as expected.

[mwpardue]

@amarz45 thanks for reporting! I am able to repro this. Interestingly a rolled press "F↓, J↓, F↑, J↑" works as intended (and is covered by a unit test), but the incorrect behavior occurs on distinct taps "F↓, F↑, J↓, J↑." I'll fix this.

I think this is the issue I was trying to report, I just don't think I explained it very well. I do still encounter this, especially with a word like DEFANG, where only D F and A are taphold keys. It's somewhat common to get the A key treated as a hold.

This doesn't happen so long as I don't have multiple tap hold keys in a row. I was going to try and add an update to last_input in the key-release event for tap-hold keys that are flow-tap keys as well, I just haven't had time to decipher where it goes in action_tapping.c yet. I thought this would preserve the ability to chord holds. This was my strategy because it seemed like the reason for the hold was that the flow_tap term had expired. If I set the term higher, like 300ms, then the issue goes away unless I also slow down my typing speed.

[NikGovorov]

The only logical explanation I can see for my issue is that 4. KC_RIGHT down is being reported as MT(MOD_RALT, KC_I) down because LT(NAV, KC_SPC) hasn't settled yet. I’ve observed similar behavior in pre_process_record_user, and I suspect the same applies within action_tapping.c.

[getreuer]

@amarz45, @mwpardue, @NikGovorov thanks again for your testing and feedback! I just opened #25175 to fix the problems reported above. I'd very much appreciate if you could try it out to check how it works. Thank you!

[getreuer]

Update: a revision of Flow Tap is in #25175. @amarz45, @mwpardue, @NikGovorov have tested and confirmed that the problems reported previously are fixed. 🎉

[r-vdp]

@getreuer thank you so much for all the work you've been doing on tap-hold stuff!

I just tried out flow tap (I applied this and the other PR on top of 0.28.8), but I ran into an issue where I type git comm and then my shell offers an auto-completion, for which I want to press the right arrow key. In order to get the arrow key, I hold a key in my right hand thumb cluster which does LT(LAYER_NAVIGATION, KC_SPC), and then press another key in my right hand which does KC_RGHT. However, when typing fast with flow tap enabled, the hold of the right hand thumb key does not trigger, and the key immediately registers as KC_SPC and either I let it go and the arrow key instead is tapped as well (producing KC_I) or if I hold longer the thumb key shoots through the QUICK_TAP_TERM and starts repeating KC_SPC.

I hope that I managed to accurately explain what happens.

Without flow tap, this seems to work as expected where the LT key holds.

So it seems that somehow I cannot go from fast typing, to holding a key to trigger a modifier, I need to wait for a little bit in order to be able to hold the tap-hold key.
I also have CHORDAL_HOLD configured and the keys right before the modifier (m) happen to be in the other hand as the tap-hold key that I subsequently try to hold, but that also doesn't seem to help and the key is still tapped.

You can find my config and keymap here: https://git.sr.ht/~r-vdp/nixos-config/tree/a955e979fac395e24d709b992f5339bb093f3e03/item/keyboards/dilemma

[NikGovorov]

@getreuer thank you so much for all the work you've been doing on tap-hold stuff!

I just tried out flow tap (I applied this and the other PR on top of 0.28.8), but I ran into an issue where I type git comm and then my shell offers an auto-completion, for which I want to press the right arrow key. In order to get the arrow key, I hold a key in my right hand thumb cluster which does LT(LAYER_NAVIGATION, KC_SPC), and then press another key in my right hand which does KC_RGHT. However, when typing fast with flow tap enabled, the hold of the right hand thumb key does not trigger, and the key immediately registers as KC_SPC and either I let it go and the arrow key instead is tapped as well (producing KC_I) or if I hold longer the thumb key shoots through the QUICK_TAP_TERM and starts repeating KC_SPC.

I hope that I managed to accurately explain what happens.

Without flow tap, this seems to work as expected where the LT key holds.

So it seems that somehow I cannot go from fast typing, to holding a key to trigger a modifier, I need to wait for a little bit in order to be able to hold the tap-hold key. I also have CHORDAL_HOLD configured and the keys right before the modifier (m) happen to be in the other hand as the tap-hold key that I subsequently try to hold, but that also doesn't seem to help and the key is still tapped.

You can find my config and keymap here: https://git.sr.ht/~r-vdp/nixos-config/tree/a955e979fac395e24d709b992f5339bb093f3e03/item/keyboards/dilemma

Try adding the following function to your keymap.c. The built-in version of is_flow_tap_key doesn’t filter LT keys (by design), so this custom version should address that scenario:

bool is_flow_tap_key(uint16_t keycode) {
    if (IS_QK_LAYER_TAP(keycode)) {
        return false;
    }
    if ((get_mods() & (MOD_MASK_CG | MOD_BIT_LALT)) != 0) {
        return false; // Disable Flow Tap on hotkeys.
    }
    switch (get_tap_keycode(keycode)) {
        case KC_SPC:
        case KC_A ... KC_Z:
        case KC_DOT:
        case KC_COMM:
        case KC_SCLN:
        case KC_SLSH:
            return true;
    }
    return false;
}

[r-vdp]

@NikGovorov ah, so MT and LT keys are handled differently by default? I will try your suggestion and see how that goes, thanks!

[getreuer]

@r-vdp thanks for trying Flow Tap. Yes, that's the tradeoff with Flow Tap, "going from fast typing, to holding" requires either waiting out the Flow Tap term or that Flow Tap be disabled for that key and/or preceding key.

By default, Flow Tap is enabled for both MT and LT keys whose tapping key is a letter A–Z or punctuation , . ; / (the main alphas area) or Space. To change this, you can define the is_flow_tap_key() callback like in @NikGovorov's comment.

[hitsmaxft]

Hi @getreuer,

Thank you for your efforts in enhancing HRM for QMK!

I’ve been using FLOW TAP on my split keyboard and encountered an issue that’s quite troubling. As a Vim user, when I need to copy text, I often press o followed by MT(cmd, d) v in quick succession. However, the rapid pressing of d interrupts the hold behavior of the MT key, particularly when using both hands within a FLOW TAP window.

Additionally, there could be an opportunity to improve FLOW TAP by shortening the timing window for the flow tap when a hold key is pressed after releasing a normal key on the opposite hand.

[getreuer]

@hitsmaxft thanks for the feedback!

As a Vim user, when I need to copy text, I often press o followed by MT(cmd, d) v in quick succession. However, the rapid pressing of d interrupts the hold behavior of the MT key, particularly when using both hands within a FLOW TAP window.

Right, yes. A limitation with Flow Tap is that the defaults don't play well with a hotkey that you are so fast at that you use it within the Flow Tap term.

To get around this, you can define the get_flow_tap_term() callback to exceptionally use a shorter term or return 0 to disable Flow Tap entirely for those hotkeys. The callback takes both the tap-hold keycode and the previous keycode as args, so it's possible to be fine-grained with specifying such exceptions.

Something like:

uint16_t get_flow_tap_term(uint16_t keycode, keyrecord_t* record, 
                           uint16_t prev_keycode) {
    if (is_flow_tap_key(keycode) && is_flow_tap_key(prev_keycode)) {
        switch (keycode) {
            case LGUI_T(KC_D):
                // Disable Flow Tap for KC_O followed by LGUI_T(KC_D).
                if (prev_keycode == KC_O) { return 0; }
                break;
        }
        return FLOW_TAP_TERM;  // Default timeout.
    }
    return 0;  // Disable Flow Tap.
}

[jaeryongim]

@getreuer i have question!

First, I am a first time QMK user.
I looked it up and it seems that keymap.json is ignored if keymap.c is present, but regardless of this, should I just create and install keymap.json in the folder where keymap.c is?
The module I'm trying to use is this.
https://github.com/GEIGEIGEIST/TOTEM/tree/main/firmware/QMK/VIAL_source/totem

[hitsmaxft]

@hitsmaxft thanks for the feedback!

As a Vim user, when I need to copy text, I often press o followed by MT(cmd, d) v in quick succession. However, the rapid pressing of d interrupts the hold behavior of the MT key, particularly when using both hands within a FLOW TAP window.

Right, yes. A limitation with Flow Tap is that the defaults don't play well with a hotkey that you are so fast at that you use it within the Flow Tap term.

To get around this, you can define the get_flow_tap_term() callback to exceptionally use a shorter term or return 0 to disable Flow Tap entirely for those hotkeys. The callback takes both the tap-hold keycode and the previous keycode as args, so it's possible to be fine-grained with specifying such exceptions.

Something like:

uint16_t get_flow_tap_term(uint16_t keycode, keyrecord_t* record, 
                           uint16_t prev_keycode) {
    if (is_flow_tap_key(keycode) && is_flow_tap_key(prev_keycode)) {
        switch (keycode) {
            case LGUI_T(KC_D):
                // Disable Flow Tap for KC_O followed by LGUI_T(KC_D).
                if (prev_keycode == KC_O) { return 0; }
                break;
        }
        return FLOW_TAP_TERM;  // Default timeout.
    }
    return 0;  // Disable Flow Tap.
}

Thank you for your reply. I am now trying to alleviate the tap caused by the hands operating too quickly by comparing the coordinates of the keyrecord pressed before and after, hoping that my experimental results will be positive and can be used as an additional feature.

[drashna]

First, I am a first time QMK user. I looked it up and it seems that keymap.json is ignored if keymap.c is present, but regardless of this, should I just create and install keymap.json in the folder where keymap.c is? The module I'm trying to use is this. GEIGEIGEIST/TOTEM@main/firmware/QMK/VIAL_source/totem

There should be no issue with using both keymap.c and keymap.json. I can confirm this works, but this may require an updated repo.