Feature: input processor behavior invocation

[petejohanson]

Adds a new input processor that can trigger behaviors for certain input events.

PR check-list

• Branch has a clean commit history
• Additional tests are included, if changing behaviors/core code that is testable.
• Proper Copyright + License headers added to applicable files (Generally, we stick to "The ZMK Contributors" for copyrights to help avoid churn when files get edited)
• Pre-commit used to check formatting of files, commit messages, etc.

[Nick-Munnich]

I'm immediately curious about the complex behavior/hold-tap limitations. Could you elaborate a bit?

[petejohanson]

I'm immediately curious about the complex behavior/hold-tap limitations. Could you elaborate a bit?

Those behaviors rely on tracking things based on the key position, which isn't part of the binding event details when there's no associated key position for this. This PR is still a draft because I'm next working on a "event to key position event mapper" processor that will allow certain input events to generate key position events, i.e. "key presses", to trigger keymap processing like normal, for folks interested in extending they keymaps to allow more complex behaviors.

[Nick-Munnich]

This PR is still a draft because I'm next working on a "event to key position event mapper" processor that will allow certain input events to generate key position events [...]

I recall a brief discussion on Discord a while ago where I suggested a (pair of) behavior to trigger behaviors from specific locations in the keymap, "Trigger the behavior found at my current index on this layer", "trigger the behavior found on layer X at index X". Though another processor is probably a cleaner way of resolving the issue, but as a backup/if you like the idea.

[petejohanson]

This PR is still a draft because I'm next working on a "event to key position event mapper" processor that will allow certain input events to generate key position events [...]

I recall a brief discussion on Discord a while ago where I suggested a (pair of) behavior to trigger behaviors from specific locations in the keymap, "Trigger the behavior found at my current index on this layer", "trigger the behavior found on layer X at index X". Though another processor is probably a cleaner way of resolving the issue, but as a backup/if you like the idea.

I want the processor to honor whatever layers are active though, so folks can combine the processor with various layer settings for effect.

[petejohanson]

@Nick-Munnich Ok, I went with extending the virtual key positions to support this more extensively, and remove that limitation. I've removed that note, and added a test showing the use with hold tap.