Open infused-kim opened 1 year ago
I just found a workaround for this. By nesting the tap dance within the layer tap / hold-tap, the delay disappears.
Since this use-case is being used in the documentation, perhaps it would make sense to update the example with this structure that is working much better?
/*
* Tap dancing nav layer
*
* Usage: &td_nav_layer NAV 0
* Tap: RET
* Double Tap: NAV_WORD layer
* Triple-Tap-Hold: RET repeated
* Hold: NAV layer
*/
td_nav_layer_inner: td_nav_layer_inner {
compatible = "zmk,behavior-tap-dance";
label = "td_nav_layer_inner";
#binding-cells = <0>;
tapping-term-ms = <250>;
bindings = <&kp RET>, <&nav_word>, <&kp RET>;
};
td_nav_layer: td_nav_layer {
compatible = "zmk,behavior-hold-tap";
label = "td_nav_layer";
#binding-cells = <2>;
flavor = "tap-preferred";
tapping-term-ms = <250>;
quick-tap-ms = <225>;
bindings = <&mo>, <&td_nav_layer_inner>;
};
I think it would be worthwhile for the testing team to check if nesting tap-dances inside hold-taps, rather than hold-taps inside tap-dances, is a better implementation of their combination in all use cases.
Out of curiosity, could you provide debug logs so we can compare them with your previous setup to determine why making the hold-tap as the parent behavior improves the activation timing?
This is similar to #1672
I didn't check but I guess this is caused by the same reasons for issue as #1701 - order in CMakeList that prevents tap-dance from being interrupted. And there are other combinations that don't work with tap-dance, probably because of that.
I noticed that a layer tap within a tap dance takes much longer to activate than having the layer tap without the tap dance.
Here is an example config:
What I am expecting
&td_num_layer
key and pressw
key to write7
.What is actually happening
&td_num_layer
key and pressw
key to write7
.w
appears instead&td_num_layer
is executedTo make it work, I have to:
&td_num_layer
keyw
key7
appearsLog
Based on the log it looks like the layer tap behavior starts its timing only after the tap dance has been decided. But that's probably not what most users want.