Hold-tap with several param behaviors

[near bone]

Hi, is there any way to achive such behaviours? I need some hold or layer tap combinations with &uc (bindings = <&kp>, <&uc> OR bindings = <&mo>, <&uc>)

#define MAKE_HRM(NAME, TAP, TRIGGER_POS)                             \
    ZMK_HOLD_TAP(NAME,                                               \
                 bindings = <&kp>, <TAP>;                            \
                 flavor = "balanced";                                \
                 tapping-term-ms = <TAPPING_TERM_MS>;                \
                 quick-tap-ms = <QUICK_TAP_MS>;                      \
                 require-prior-idle-ms = <REQUIRE_PRIOR_IDLE_MS>;    \
                 hold-trigger-on-release;                            \
                 hold-trigger-key-positions = <TRIGGER_POS>;         \
    )


MAKE_HRM(uhml, &uc, KEYS_L) 

#define  UHM_LGUI_RU_F     &uhml LGUI UC_RU_F

While building get error, and many import errors, Im sure problem in uhml above

DT_N_S_keymap_S_layer_base_P_bindings_IDX_11_PH_FULL_NAME

[tiny bloom]

One issue is that &uc takes two arguments (UC_RU_F expands to two arguments)

Not sure if it works but might be worth trying to add the arguments to the hold tap definition and then invoke it with a dummy parameter

The general question here is if there is a workaround to use hold tap with two-param behaviors.

(If a search doesn’t bring up anything, it might be worth editing the title / original question of this post for better visibility/discoverabily)

[near bone]

Hi @tiny bloom my first post there, happy that I reach right guy

Is there constructor for &uc with 1 parameter? I think its gonna fit default ZMK behaviour style

Hold-tap with several param behaviors

[tiny bloom]

Not at the moment, though you could create a simple wrapper macro with either one or zero parameters as a workaround.

This should work if there’s no other way of binding a two parameter behavior to a hold tap

[tiny bloom]

Not sure if you saw the other message in the main help channel. But wrapping in a macro is the way to go

[near bone]

Hi, finally got around, you were right wrapper works fine

// wrapper macro for uc behaviour
ZMK_MACRO(ru_f , bindings = <&uc UC_RU_F>;)   
ZMK_MACRO(ru_bi, bindings = <&uc UC_RU_BI>;)   
ZMK_MACRO(ru_v , bindings = <&uc UC_RU_V>;)   
ZMK_MACRO(ru_a , bindings = <&uc UC_RU_A>;)  

ZMK_MACRO(ru_o , bindings = <&uc UC_RU_O>;)   
ZMK_MACRO(ru_l , bindings = <&uc UC_RU_L>;)  
ZMK_MACRO(ru_d , bindings = <&uc UC_RU_D>;)   
ZMK_MACRO(ru_zh, bindings = <&uc UC_RU_ZH>;)  

// hold tap behaviour for uc behaviour
HOLD_TAP(uht_f ,  &kp, &ru_f ,  KEYS_L) 
HOLD_TAP(uht_bi,  &kp, &ru_bi,  KEYS_L) 
HOLD_TAP(uht_v ,  &kp, &ru_v ,  KEYS_L) 
HOLD_TAP(uht_a ,  &kp, &ru_a ,  KEYS_L) 
 
HOLD_TAP(uht_o ,  &kp, &ru_o ,  KEYS_R) 
HOLD_TAP(uht_l ,  &kp, &ru_l ,  KEYS_R) 
HOLD_TAP(uht_d ,  &kp, &ru_d ,  KEYS_R) 
HOLD_TAP(uht_zh,  &kp, &ru_zh,  KEYS_R) 

// keys to use in keymap
#define UHT_RU_F    &uht_f    LGUI  0
#define UHT_RU_BI   &uht_bi   LALT  0
#define UHT_RU_V    &uht_v    LSHFT 0
#define UHT_RU_A    &uht_a    LCTRL 0

#define UHT_RU_O    &uht_o    RCTRL 0
#define UHT_RU_L    &uht_l    RSHFT 0
#define UHT_RU_D    &uht_d    LALT  0
#define UHT_RU_ZH   &uht_zh   RGUI  0

[near bone]

Hello again I faced a problem with wrapper macro implementation. When try to type unicode sequence fast I get raw unicodes (U 3526 enter).

I couldn't find any mention that someone change ZMK_UNICODE_WAIT_MS or ZMK_UNICODE_TAP_MS on Git. So I guess default values of this params works fine.

I try to set wait-time and tap time of macro to 0 and increase ZMK_UNICODE_TAP_MS but result remains same. Do you have ideas how to fix this problem?

[tiny bloom]

Can you open an issue on module repo, if possible with a minimal example that triggers the issue (e.g., does just wrapping it in a macro without the hold tap cause any problems?)

[near bone]

sure see you there

there is example of fast typing bottom row without hold tap, so i think its macro problem

@ is combo result

[near bone]

understand this issue now

while send unicode with shift held, shift applied to unicode seq itself

you can see screenshot i try to call UC_RU_S multiple time in a row with shift held and 1 in 0x441 became ! (also 2 become @)

#define UC_RU_S 0x441 0x421 // с/С

I think problem not only in shift, modifiers affect unicode seq

[tiny bloom]

It’s more complicated than that. The Unicode behavior goes through a great deal of effort to avoid precisely this issues. To that end it reimplements macro and mod morph to guarantee the right queuing order of events. (Since there’s no way to inject into the behavior queue right after a macro sequence)

My guess is that wrapping Unicode in a macro creates some race condition between the events added to the behavior queue. But hard to say without logs and/or a test case.