Extend custom shift keys to support TM with not basic keycodes

[sotte]

I use the custom shift keys in all my layouts. Great feature!

It's great to just use a different shift key

const custom_shift_key_t custom_shift_keys[] = {
  {KC_SLSH, KC_COLN},
}

It's great if you want to switch the normal key with the shifted key

const custom_shift_key_t custom_shift_keys[] = {
  {KC_UNDS, KC_MINS},
}

You can even enable TM while keeping a normal key and changing the shifted key.

const custom_shift_key_t custom_shift_keys[] = {
  {LCTL_T(KC_COMM), KC_QUES},
}

The one thing that I wish it could also do is easily use switch normal key and shifted key AND enable TM. Something like:

const custom_shift_key_t custom_shift_keys[] = {
  {LALT_T(KC_UNDS), KC_MINS},
}

This however does not wok. A normal press sends the unshifted version of that key which in this case is -.
I guess the problem is that KC_UNDS is not a basic keycode.

So is there a simple way to extend "custom shift keys" to allow this?
I would use this feature for my 'bottom row mod' on the symbol layer (among other things) and it has to work for these keys (removed the irrelevant keys):

    _______,   KC_LT, KC_ASTR,  KC_PLUS,  KC_GT, _______,                      _______, KC_LCBR, KC_GRV, KC_RCBR, KC_UNDS, _______,

[getreuer]

That's great to hear Custom Shift Keys has been useful for your keymap!

I guess the problem is that KC_UNDS is not a basic keycode.

Yes, exactly. "LALT_T(KC_UNDS)" does not work properly because KC_UNDS is not a basic keycode. In detail, keycodes in QMK are limited to 16 bits. This is problematic for compound keycodes, since all parameters must be packed into the 16 bits. For mod-tap keycodes like LALT_T(kc), 5 bits are spent encoding the mods and 8 bits are spent on the tapping keycode kc. Fitting into those 8 bits is where the basic keycode requirement comes from.

Given a kc exceeding 255, the upper bits are bit-masked away. This is done by the &0xFF in the mod-tap MT() macro (code link):

#define MT(mod, kc) (QK_MOD_TAP | (((mod)&0x1F) << 8) | ((kc)&0xFF))

So LALT_T(KC_UNDS) ignores the upper bits of KC_UNDS, which effectively forgets that the keycode was meant to be shifted, and the result is LALT_T(KC_MINS).

Long story short, given the keycode LALT_T(KC_UNDS), it is unfortunately not possible to distinguish it from LALT_T(KC_MINS).

The good news is that there is a workaround by changing the tap function. In process_record_user(), do

bool process_record_user(uint16_t keycode, keyrecord_t* record) {
  if (!process_custom_shift_keys(keycode, record)) { return false; }

  switch (keycode) {
    case LALT_T(KC_UNDS):  // Left alt on hold, KC_UNDS on tap.
      if (record->tap.count) {        // On tap.
        if (record->event.pressed) {  // On press.
          register_code16(KC_UNDS);
        } else {                      // On release.
          unregister_code16(KC_UNDS);
        }
        return false;  // Skip default handling.
      }
      break;
 
    // Other macros...
  }
  return true;  // Continue default handling.
}

Check out MT doesn’t work with this keycode for more examples of using mod-taps with non-basic tapping keycodes.

[sotte]

Thank you so much for the detailed(!) response. I'll give this a more detailed read and implement it. Thanks @getreuer.