Robert U

> > > I think this is intended. `masked-mods` turns off the modifier for the duration of the triggered behavior but then re-applies it when it is released (if the...

> Yeah, as @urob explained, it's actually unintended behavior with my board. In your chart @vrinek, I was expecting my board to act like the PR behavior column. But instead...

A quick update on this. I cherry-picked 241f82e into the latest main and successfully build against it. So far, all my tests did go well and `masked_mods` seem to do...

> @urob i am willing to test, can you please advice on how i can do that? If you don't have a local copy of ZMK, you can use the...

@alex-popov-tech Not sure what's causing this or whether this is related to this PR. The ZMK discord https://discord.com/channels/719497620560543766/719909884769992755 might be able to provide better feedback on this

> I just merged the latest `main` into this PR's branch. @urob, this is the only diff I see between this branch and yours. [...] Do you see something I...

@vrinek @aumuell A few quick comments on the PR. 1. I submitted a small ["PR to the PR"](https://github.com/vrinek/zmk/pull/1) that excludes implicit modifiers from getting masked. It enables users to re-include...

> This sounds like a breaking change, no? Technically, yes, it does change the behavior of `mod-morph`. But I would argue that in the majority of cases what the uses...

> It sounds like you are describing a need for tap-trigger-key-positions? Is that a PR? I couldn't find anything but just based on the name this sounds indeed like what...

Just realized that there might be a very simple fix for this by simply applying the positional-hold-tap logic upon key-release (currently it is decided upon key-press). I implemented a small...