Feature request: add tap-ms property to hold-tap behavior

[manna-harbour]

Hold-tap taps are sent as press immediately followed by release. This can cause compatibility issues with other systems.

QMK has TAP_CODE_DELAY for this purpose, default 100ms, https://github.com/qmk/qmk_firmware/blob/master/docs/config_options.md#behaviors-that-can-be-configured.

The macros behavior has a tap-ms property, implemented with behavior_queue, default 100ms, https://zmk.dev/docs/behaviors/macros#tap-time.

Hold-tap could be implemented using behavior_queue with tap-ms in the same way as in the macros behavior.

It might also be necessary to do this with all behaviors that generate key events, such as shifted keycodes in kp. See #756, #759, #815,

[lesshonor]

...probably worth noting that QMK's default for this value is actually 0

(a lot of projects began setting it to 10ms because supposedly Windows ignores volume up and down events sent more quickly than that, but 100ms would be quite noticeable)

[caksoylar]

The default tap time of macros has been changed to 30ms since then, but that is probably still a bit long outside of remote desktopping and such.

Now that there are parametrizable macros, this could be worked around easier using them instead of &kp:

        kpt: kp_tap_time {
            compatible = "zmk,behavior-macro-one-param";
            label = "KPT";
            tap-ms = <10>;  // tweak as needed
            #binding-cells = <1>;
            bindings = <&macro_param_1to1>, <&kp MACRO_PLACEHOLDER>;
        };

Then using &kpt instead of &kp in the hold-tap definition.