[Feature Request] Default Keys for Custom Keycodes

[drewlwhitney]

Feature Request Type

• Core functionality
• Add-on hardware support (eg. audio, RGB, OLED screen, etc.)
• Alteration (enhancement/optimization) of existing feature(s)
• New behavior

Description

Idea

Users must manually implement custom keycode behavior through process_record_user(). It would be convenient if instead, they could define default behavior for those keycodes. The idea is that the QMK core would treat this keycode as a custom keycode right up until would be registered, then would convert it into the default keycode.

Use Case

This is mainly useful for key-overrides. If you have two instances of the same keycode defined on one layer, you cannot choose only one of those keycodes to override unless you replace one of them with a custom keycode (as far as I've seen). You must then either manually implement the default behavior and override behavior, or use key-overrides but still implement the default behavior. The latter option requires you to keep track of whether the trigger_mods are active, and it becomes messy.

Example

// in keymap.c

enum custom_keycodes {
    EXAMPLE_CODE = SAFE_RANGE;
}; // EXAMPLE_CODE is on KC_Q in the following keymap

const uint16_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = {
    // base
    [_QWERTY] = LAYOUT_planck_grid(
        KC_TAB,  EXAMPLE_CODE,     KC_W,    KC_E,    KC_R,    KC_T,    KC_Y,    KC_U,    KC_I,    KC_O,    KC_P,    KC_BSPC,
        KC_ESC,  KC_A,             KC_S,    KC_D,    KC_F,    KC_G,    KC_H,    KC_J,    KC_K,    KC_L,    KC_SCLN, KC_QUOT,
        KC_LSFT, KC_Z,             KC_X,    KC_C,    KC_V,    KC_B,    KC_N,    KC_M,    KC_COMM, KC_DOT,  KC_SLSH, KC_ENT ,
        BACKLIT, KC_LCTL,          KC_LALT, KC_LGUI, LOWER,   KC_SPC,  KC_SPC,  RAISE,   KC_LEFT, KC_DOWN, KC_UP,   KC_RGHT
    ),

...

};

...

uint16_t get_custom_keycode_default(uint16_t custom_keycode) {
    switch (custom_keycode) {
        case EXAMPLE_CODE:
            return KC_Q; // EXAMPLE_CODE sends KC_Q by default
            break;
    }
    return KC_NO; // return KC_NO to do nothing
}

// in config.h

...

# define CUSTOM_KEYCODE_DEFAULT

Anticipated Issues

For this to work, I believe register_code, register_code16, unregister_code, unregister_code16, add_key, and del_key would have to be modified. Furthermore, to make this work with key-overrides, the key override processing functions would need to no longer filter out custom keycodes and instead attempt to register them.

I'm happy to work on implementing this if you guys think it would be useful. I would just need to know if there are other points where keycodes are registered/where custom keycodes are filtered out.

Side Note

I'm still a noob at QMK, so if I misspoke about how any features work, my bad!