Hijacking repeat key functionality

[noamvokaal]

Hey there! Is it possible to borrow some of the repeat key’s functionality (in this case: checking the last keycode) to alter the behaviour of macros? My understandig of C (and programming in general) is very limited, but I tried the code below in process_record_user to check if KC_SPACE was pressed before the macro. That did certainly not work as expected. Is it at all possible with your existing code?

    case COMMA_MACRO:
      if (get_last_keycode() == KC_SPACE) {
        if (record->event.pressed) {
          tap_code16(KC_BSPC);
          tap_code16(KC_COMMA);
          tap_code16(KC_SPACE);
        }
      }
      else {
        if (record->event.pressed) {
          tap_code16(KC_COMMA);
          tap_code16(KC_SPACE);
        }
      }
      return true;

Anyways, thank you for all of your wonderful contributions to QMK! I use every single feature in my keymap, thanks to your easy-to-follow documentation!

[getreuer]

That's a cool use of Repeat Key! Yes, that "hijacking" should be possible.

Be sure that remember_last_key_user() is defined to ignore COMMA_MACRO like this:

bool remember_last_key_user(uint16_t keycode, keyrecord_t* record,
                            uint8_t* remembered_mods) {
    switch (keycode) {
        case COMMA_MACRO:
            return false;  // Ignore this key.
    }

    return true;  // Other keys are remembered.
}

Without that definition, the problem is that when COMMA_MACRO is pressed, the "last key" returned by get_last_keycode() changes to COMMA_MACRO by the time that process_record_user() is called. I have to admit that is rather confusing. See also the "Additional Alternate keys" example in the Repeat Key docs, which makes similar use of the last key.

[noamvokaal]

This is unbelievably helpful for me as a complete noob! And the fast response is much appreciated! Thank you – the solution works as intended! :-)

I did, though, realize another problem with this solution. My space key is a layer-tap. And I’ve intercepted that layer-tap to pass on One Shot Shift to the next keypress if One Shot Shift was accidently activated before KC_SPACE. I suspect this manoeuvre is preventing the repeat key feature from detecting KC_SPACE. I used the following code inside process_record_user:

    case NAV_SPC:
      if (record->tap.count && record->event.pressed) {         // Intercepting the tap-hold
        if (oneshot_mod_state & MOD_MASK_SHIFT) {               // Checking the one shot shift state
          process_autocorrect(keycode, record);                 // Send the keycode further to autocorrect
          tap_code(KC_SPC);                                   
          set_oneshot_mods(MOD_LSFT | get_oneshot_mods());      // Activating one shot shift once again
        }

        else {                                                  // Treat it otherwise as a regular space
          process_autocorrect(keycode, record);
          tap_code(KC_SPC);
        }

        caps_word_off();                                       // Disable caps word manually
        return false;
      }
      return true;

I think the return false is preventing the KC_SPACE from being sent further to other features. The QMK gurus on Discord helped me to add process_autocorrect(keycode, record) to solve the same problem for autocorrect. Is it possible to do something similiar to the repeat key feature?

I know you’re of course not required to answer this, but I am extremely greatful for every little advice in this matter. Thank you once again!

[noamvokaal]

Okay, I think I just solved this. I suspect that this is not the tidiest of solutions, but it does at least work as intended. I ended up adding the line set_last_record(KC_SPC, record); to the NAV_SPC macro. Thank you once again for the help!