feat(behaviors): Hold-tap - Hold while undecided
Addresses #1393
Wow, we even can merge it soon? You guys are crazy fast! Loving it!
I am trying to understand why the modkey getting stuck with this option, but I don't see a problem in your code.
If someone would review the pull, I would suggest it to get merged. :) The solution seems to be working perfectly! Also any code that was added, only runs if this flavor is turned on, so it won't have effect on other things.
Could someone review and approve this? Would be good if it is out in official! It has been working like a charm since the last update! The readme of zmk changed on master AFAIK, so maybe that will need a little evident correction.
Could we get it reviewed. I have been using it since aug 1, and everything is working perfectly. It really is and important feature, not just for me but for anyone trying to use SHIFT + mouse.
I do not feel this MR is on the right track implementation-wise. It adds two new state variables (first_pressed and hold_released) while completely ignoring the existing status variable.
I would suggest to implement this in the following way, more in line with the original implementation of hold-tap. It uses the existing status variable and existing machinery to centralise decisionmaking.
- add a new
statusenum valueSTATUS_UNDECIDED_INITIAL_HOLD - add a new function
status_is_undecidedwhich returns true if a status isSTATUS_UNDECIDEDorSTATUS_UNDECIDED_INITIAL_HOLD. Replace all tests forSTATUS_UNDECIDEDwith this new function. - add a new
decision_momentenum valueHT_KEY_DOWN. Calldecide_hold_tapon initial press with this new value. - add a new function
decide_initial_holdwhich is called at the top ofdecide_hold_tapwhich setsSTATUS_UNDECIDED_INITIAL_HOLDwhen appropriate and presses the hold key binding. - modify
press_binding. If 'hold' is decided, do not press the hold again wheninitial_holdis enabled. If 'tap' is decided, make sure to release the initial hold.
@okke-formsma your idea, of trying to solve the functionality without that 2 extra states, seems to be an important request. I also think the functionality should be more deeply integrated, while I think Nicon thought things would be more modular if he used these two states.
I can't reach @nickconway on discord anymore, I have tried to do so in the last 3 weeks. I don't know what is happening to him, so probably the correction of the pull request is on us.
Just want to add that this PR works perfectly for me. I am using this for shift, gui(Mac) and ctrl(Windows). Without this option, homerow mods aren't very usable with mouse clicks.
I am using it also, and shift + mouseclicks are insanely good! Loving it so much! I hope some day we will merge it!
Close this in favor of https://github.com/zmkfirmware/zmk/pull/1811