Are any documentation changes warranted? this seems like a great feature.

Not really, though perhaps it should be noted that it can't be extended further to include mousekeys too, as OP_TAP_TOGGLE and OP_ONESHOT are 0xF0 and 0xF4 respectively.

At the moment, this PR doesn't fix use cases like MT(MOD_RCTL, KC_DOLLAR). This will still send 4 on tap instead of $. Is there any hope of this being addressed here?

@rgreenblatt no. No chance at all.

The problem is that there isn't enough space to be able to add the shifted notation to this. We would have to extend the keycodes.

Basic keycodes can and do use the 8 bit range, while extra stuff uses higher.

Here, for instance, the keycode is broken up a la:

ffff llll kkkk kkkk

The ffff being the special function, the llll being the layer number (and why LT is limited to 0-15), and kkkk kkkk is the specified keycode.

Shifted keycodes use the first 8 bits to mark what mod it's using, and the second 8 for the keycode. eg

rrrr mmmm kkkk kkkk

Where rrrr is right/left, mmmm is the bit for the mod (shift, ctrl, alt, gui/cmd), and the keycode.

Some of this info is from memory, so it may not be 100% accurate. But this should give you a good idea of why it's not possible.

We'd have to expand to 24 (or realistically) 32 bit keycodes. Which would double the size of the keymaps in the firmware (not insignificant) and would require a MASSIVE rewrite of the code.

Bump :)

Turns out this doesn't actually fix the issue for LT(), as it conflicts with LM() (they both use ACT_LAYER_TAP). Thanks to @drashna for spotting 😄

Here's my solution to the LM() problem - I've moved the handling out of the ACT_LAYER_TAP handling and into its own action. After all, it's not a hold/tap action, just a MO() with mods held. This seems to work great and stays within the already established limits of LM() imposed by the keycode size (layers 0-15, left mods only) so this shouldn't break VIA, or anything really.

Tested with:

LT(1, KC_RGUI)
MT(MOD_LCTL, KC_RGUI)
LM(1, MOD_LALT | MOD_RGUI)

The left/right bit is stripped from the RGUI in the LM define, turning it into an LGUI, but this is okay as it always did that anyway.

Not sure if this should be a breaking change or not.

@skullydazed ?

I don't believe it is - it doesn't even change keycode values, so VIA is safe 😄