precondition
precondition
> With this PR and `HOLD_ON_OTHER_KEYPRESS`, rolling from mod taps under `TAPPING_TERM` produces the two tap actions unlike the old behavior when not using `IGNORE_MOD_TAP_INTERRUPT`. I assume this is an...
I squashed and restructured my commits so that each commit only touches a specific folder. This should be easier to follow. The underlying code changes remain the same though.
> **Backwards compatibility:** > > [ ] The now de-funct IGNORE_MOD_TAP_INTERRUPT_PER_KEY and IGNORE_MOD_TAP_INTERRUPT defines should be removed from all keebs as they are dead code prefeerably in a seperate commit...
@cykedev @chriskopher @snowe2010 @stamm @adamtabrams @rootiest @Cy6erBr4in @drashna You are tagged here because this is a pull request that makes `IGNORE_MOD_TAP_INTERRUPT` (trigger hold action only if the key is held...
> The now de-funct IGNORE_MOD_TAP_INTERRUPT_PER_KEY and IGNORE_MOD_TAP_INTERRUPT defines should be removed from all keebs as they are dead code prefeerably in a seperate commit to make the review easier. @KarlK90...
> does this mean I'll need to change my keymap to include `HOLD_ON_OTHER_KEY_PRESS`? @snowe2010 You need to add the per-key version (`HOLD_ON_OTHER_KEY_PRESS_PER_KEY`) only if you ever decide to uncomment [those...
I should almost somehow subscribe to keymap PRs like #16696 getting merged so that I can prevent more `#define IGNORE_MOD_TAP_INTERRUPT` from sneaking in under my nose.
Fixed merge conflict in keyboards/ktec/ergodone/config.h
The gergoplex lint check fail is unrelated to the PR, see https://github.com/qmk/qmk_firmware/pull/16667#issuecomment-1068710785
> Has merge conflicts after #17284 would you mind converting the tests to `EXPECT_REPORT`, `EXPECT_EMPTY_REPORT` and `EXPECT_EMPTY_REPORT`? @KarlK90 Done in https://github.com/qmk/qmk_firmware/pull/15741/commits/f8bc774ef8e3af1bb0cf8c49b4bfe3153eab7147 and https://github.com/qmk/qmk_firmware/pull/15741/commits/1a0154d163ddf28deb51b6c3c8f88df1dc98cdf8