Implicit feature: Custom shift keys can make Layer Tap layers with advanced keycodes

[humanplayer2]

QMK's layer tap option LT(layer, kc) only supports basic keycodes in the layer---but this can be (partially) circumvented using the custom_shift_keys feature from this repo!

First observation is that Custom shift keys as-is supports overriding the default shift behavior with advanced keycodes. Having set up Custom shift keys as described in the blog post, we can set up our shift keys (both left and right) to send an advanced keycode. E.g., this makes Shift + A send Left Alt + Left GUI + B:

const custom_shift_key_t custom_shift_keys[] = {
  {KC_A , LAG(KC_B)}
};

Second observation is that our custom shift keys can be used in combination with Mod-Tap as normally. In our keymap, we can set e.g. C as a tap-mod key using

MT(MOD_RSFT,KC_C)

Cool! Now we have a tap-hold key that sends an advanced keycode---and if we didn't need our shift keys, we could define a full layer using a long list of remappings in custom_shift_key_t custom_shift_keys.

Third observation is that we can quite straightforwardly augment the Custom shift keys code to support Control, Alt and GUI, and to differentiate left and right versions of these mods.

E.g., to include a custom RGUI key, leaving LGUI as default, do the following:

In custom_shift_keys.c:

Duplicate all the code below the original, so you have it twice. In the new code, replace:
- process_custom_shift_keys with process_custom_rgui_keys
- MOD_MASK_SHIFT with MOD_BIT(KC_RIGHT_GUI)
- NUM_CUSTOM_SHIFT_KEYS with NUM_CUSTOM_RGUI_KEYS
- custom_shift_keys with custom_rgui_keys
- MOD_LSFT with MOD_RGUI

In custom_shift_keys.h:

Duplicate all the code below the original, so you have it twice. In the new code, replace:

• shifted_keycode with rguied_keycode
• custom_shift_key_t with custom_rgui_key_t
• custom_shift_key_t custom_shift_keys with custom_shift_key_t custom_shift_keys
• NUM_CUSTOM_SHIFT_KEYS with NUM_CUSTOM_RGUI_KEYS
• process_custom_shift_keys with process_custom_rgui_keys

In keymap.c:

Use custom_rgui_key_t custom_rgui_keys to define your layer (and set NUM_CUSTOM_RGUI_KEYS)

const custom_rgui_key_t custom_rgui_keys[] = {
  {KC_COMMA, C(KC_V)}, // Right GUI + . is Control + V
// ... 
    };

uint8_t NUM_CUSTOM_RGUI_KEYS =
    sizeof(custom_rgui_keys) / sizeof(custom_rgui_key_t);

Include process_custom_rgui_keys in process_record_user (maybe along with process_custom_shift_keys, as here):

bool process_record_user(uint16_t keycode, keyrecord_t* record) {
  if (!process_custom_shift_keys(keycode, record)) { return false; }
  if (!process_custom_rgui_keys(keycode, record)) { return false; }
  // Your macros ...
  return true;
}

Finally, add RGUI in a mod-tap as a keycode in your keymap---e.g. (MT(MOD_RGUI,KC_SPACE))--- and enjoy your mod-tap/layer-tap layer with advanced keycodes!

The above can then be repeated for other default mods, which at least allows for a handful of layers.

Disclaimer

I haven't tested this with any advanced keycodes apart from modifiers such as C(kc) and LAG(kc).

[getreuer]

@humanplayer2 thanks for sharing this!

To check that I understand the described idea: the result is that pressing KC_COMMA while holding the MT(MOD_RGUI,KC_SPACE) key will send Control + V, is that correct?

Implementation does get more involved to define both custom shift and custom rgui behaviors. Potentially another approach is in terms of QMK's Key Overrides. Key Overrides has a lot of flexibility beyond what Custom shift keys does. Something like

const key_override_t lag_b_key_override =  // RShift + A is Left Alt + Left GUI + B
    ko_make_basic(MOD_BIT(KC_RSFT), KC_A, LAG(KC_B));
const key_override_t ctrl_v_key_override =  // RGUI + , is Ctrl + V
    ko_make_basic(MOD_BIT(KC_RGUI), KC_COMM, C(KC_V));

Of course, writing mod handling code yourself is potentially even more flexible, and more fun =)

[humanplayer2]

Yep, that's correctly understood =)

And thank you for the suggestion. I'm keeping it in mind for when I'll do a rewrite -- and am ready to learn another bite of QMK :)

[akaralar]

@humanplayer2 is this any different than intercepting the tap behaviour of an LT(layer, kc) and sending the advanced key instead?

ie, I want to have a key where it changes layer on hold, and sends } on tap, which isn't a basic keycode because it's a shifted keycode.

So I define my layer-tap key with a basic keycode, ie

#define LS_SNUM LT(SNUM, KC_3) // The tap is intercepted later to send "}"

and then later in process_record_user

switch (keycode) {
    case LS_SNUM:
        if (record->event.pressed && record->tap.count != 0) {
            tap_code16(KC_RCBR);
            return false;
        }
        return true;
}

and hence I have a layer-tap key with a non-basic keycode. I couldn't quite wrap my head around what you described, does it accomplish anything different, or is it the same thing with a different flavour? Not trying to judge or anything, just curious and trying to understand!

[humanplayer2]

No malice interpreted at all =)

If I understand you correctly, then I think it is different. E.g.: Say we look at our physical keys labelled 3 and A.

• What I'd want is that just tapping 3 sends KC_3 and just tapping A sends KC_A, while holding A activates a layer in which tapping 3 would send KC_RCBR.
• What I understand you'd want is that just tapping 3 sends KC_RCBR, and holding 3 activates a layer.

Right?

[akaralar]

I'd say that is mostly correct. In my keyboard, the key that I assign the LT is unrelated to the physical 3 key, the KC_3 is just a placeholder value because as you say we later intercept the tap keycode and we do not send it, we send a non-basic keycode instead. So I thought your method did what you described in the first sentence:

QMK's layer tap option LT(layer, kc) only supports basic keycodes in the layer---but this can be (partially) circumvented using the custom_shift_keys feature from this repo!

which I interpreted as "LT(layer, kc) only supports basic keycodes for kc, here is a way to send an advanced keycode when you tap it". So I was mostly providing a way to do this.

In your response you say

What I'd want is that just tapping 3 sends KC_3 and just tapping A sends KC_A, while holding A activates a layer in which tapping 3 would send KC_RCBR.

The way I would do this is I would create a new layer, make a key LT(NEWLAYER, KC_A) in the default layer and place the KC_RCBR in the new layer as a standalone key. So I guess at this point my question is, do you want to achieve this without creating a new layer?

[humanplayer2]

I've added `s around "layer" now, hoping to make it clearer :)

I used KC_RSBR because you used it, but I'm unsure of it's status, so let me use C(KC_V)) instead, as an example of a non-basic keycode.

What I want is a new layer where C(KC_V)) is a standalone key. Using LT(NEWLAYER, KC_A), NEWLAYER supports only basic keycodes, so only KC_A, not C(KC_A). Custom shift keys support C(KC_A).

In my config, I define almost full layers for some of my mods, using Custom shift keys. So no, I don't want to avoid creating new layers: but I want to be able to "LT" into them while they contain non-basic keycodes.