Hold-taps should honor transparency within the bindings.

[amacleod]

When one of the bindings of a hold-tap is &trans, the behavior should look at lower layers' bindings when that portion of the hold-tap is activated.

behaviors {
  hmt: homerow_mod_transparent {
    compatible = "zmk,behavior-hold-tap";
    #binding-cells = <2>;
    bindings = <&kp>, <&trans>;
    // ... and any other mandatory fields
  };
};
keymap {
  base_layer { bindings = <&kp A>; };
  other_layer { bindings = <&kp B>; };
  overlay_mods_layer {
    bindings = <&hmt LSHFT 0>;
  };
};

Expected behavior: when the overlay mods layer is active, tapping the key should either send a or b depending on which lower layer is active.

Actual behavior: tapping the key does nothing when the overlay layer is active, just as if the second binding were &none. The hold behavior works fine.

---

https://github.com/amacleod/zmk-config/blob/hold-tap-trans-repro/config/corne.keymap#L381-L391 is an example of me trying to use a transparent hold-tap to make a floating home row mods layer.

[amacleod]

Linking the locality-preservation issue https://github.com/zmkfirmware/zmk/issues/1494 as @caksoylar mentioned that it might be related

[caksoylar]

I looked into this a bit and fixing #1494 apparently didn't fix it. &trans behavior doesn't do anything special besides returning a positive code, and that is processed by the keymap logic to fall through to other layers. But hold-tap doesn't propagate up the return code of some of the behaviors it invokes due to its complex decision logic. Maybe this can be fixed, but it seems difficult (to me) for not much gain.

[amacleod]

If the effort:effect ratio would be too low, I am okay with closing this issue as "won't fix". Any action needed from me in that regard?

[caksoylar]

I guess this isn't an architectural decision to "won't fix" so we can leave this open if you want.

[amacleod]

Looks like #2848 does indeed solve my use case.