[Bug] RETRO_TAPPING does not work with ALT_T(*)

[tom-tan]

Describe the Bug

Even when RETRO_TAPPING is defined, ALT_T(*) works as same as without RETRO_TAPPING.

I reproduced this issue as follows:

• Add the following to crkbd/keymaps/default/config.h:

  #define RETRO_TAPPING

• Add the following to crkbd/keymaps/default/keymap.c:

  #define KC_SandA ALT_T(KC_SPC)

• Replace KC_RALT with KC_SandA to _QWERTY layer in crkbd/keymaps/default/keymap.c.
• Compile and write the firmware to crkbd
• Press the KC_SandA key over TAPPING_TERM and release it.
  • Expected behavior: A space is sent (we will see a space).
  • Actual behavior: Alt is sent (I saw that a window menu is focused on) rather than a space is sent.

System Information

• Keyboard: crkbd
  • Revision (if applicable): default
• Operating system: Windows 10
• AVR GCC version: avr-gcc (GCC) 5.4.0

• ARM GCC version: arm-none-eabi-gcc (15:6.3.1+svn253039-1build1) 6.3.1 20170620

• QMK Firmware version: 0.8.192

• Any keyboard related software installed?
  • AutoHotKey
  • Karabiner
  • Other: Nothing

Additional Context

I confirmed that SFT_T and CTL_T work as intended.

[precondition]

Are you still noticing this problem? I couldn't reproduce it

[tom-tan]

Unfortunately it still remains in 81164c1.

[precondition]

Are you sure that the space does not simply get "eaten" by the key sequence initialized by alt? When retro-tapping, KC_LALT still gets pressed and released before the tapping function of the mod-tap is sent. That's the reason why using retro tap on an alt mod-tap can be problematic in practice. A similar problem can happen if you use a desktop environment like Windows in which the start menu is brought up by pressing and then releasing the GUI modifier on its own (aka tapping it). Retro tapping LGUI_T(KC_A) would open the start menu and type 'a' in its search field, for instance.

So, when retro tapping LALT_T(KC_SPC), you actually press and release KC_LALT before tapping KC_SPC. When alt gets pressed, the menus of the current app get focus and that's why you don't see a space character being inserted. The text field you were previously on got out of focus once you tapped alt and the subsequent press of the space key gets interpreted as a component of the leader key sequence initiated by alt. You can verify that this is what happens by turning your E or H keys into alt mod-taps and try retro-tapping them in apps which have an "E॒dit" or "H॒elp" menus, you can see them getting focus because Alt followed by E would select the "E॒dit" menu (notice the underlined 'E').

The above is the normal, expected behaviour.

You should try a key event listener like https://config.qmk.fm/#/test or xev on Linux to see if there really is no activation of KC_SPC when retro-tapping KC_SandA

[kazbeel]

I use home row mod keys for Linux (most of the time), Windows (from time to time) and Mac (at work). I do have activated RETRO_TAPPING_PER_KEY and get_retro_tapping returning true for all those mod keys. In both, Linux and Windows, pressing ALT or GUI without a secondary key press results in ALT+S and GUI+D which focuses on the app's menu or activates the System Menu respectively.

This behavior is quite annoying. Is this the intended behavior? Why SFT and CTL do not behave the same way? Should they?

Why the behavior of ALT and GUI differ from CTL and SFT?

[precondition]

It is common convention in desktop UX to focus the menu and enter "leader key mode" when pressing and releasing alt by itself (i.e. without combining alt with any other key) as I've explained so yes this is the intended behaviour that's coded by the app developers. See also https://en.wikipedia.org/wiki/Alt_key#Alt_key_pressed_alone

There is no common convention regarding any special behaviour to tapping control or shift by itself so you rarely find apps that map an action to such a key sequence.

If you don't want "flashing modifiers" before sending the letter, you must use another method than retro-tap in order to trigger the tap action of the dual-role key, e.g. releasing the key before TAPPING_TERM expires.

[kassi-moon-whaler]

I figured it out, the solution was to add #define TAPPING_TERM_PER_KEY to my config.h and the following code block to my keymap.c

uint16_t get_tapping_term(uint16_t keycode, keyrecord_t *record) {
  switch (keycode) {
    case LALT_T(KC_SPC):
      return -1;
    default:
      return TAPPING_TERM;
  }
}

This treats the tapping term as infinite (or maybe just very large? c++ isn't my native language), so it won't resort to alt unless I hit another key.

I'm experiencing the same issue, it really throws me off when I hold the ALT_T(KC_SPC) just a moment too long and the focus is lost from where I'm typing. The functionality I'm looking for is to never send alt. I want to add alt as a modifier to any other keys clicked when I'm holding that key though.

With your explanation @precondition I understand why the alt modifier works how it does, but is there any work around you can think of to accomplish the desired behavior?

I've considered using a layer toggle and an alt layer that would be my normal keymap with alt to every key. That would be very difficult to maintain edge cases like Alt+F4 though, since that's on a separate layer. Essentially I'd need an Alt+Function keys layer that is activated from my function layer toggle key when in the alt layer. I'd also need to remember I have that weird pattern when changing other things about my keymap.

[kazbeel]

Wow, @kassi-moon-whaler! I will give it a try tonight! I'll give feedback then!

[kazbeel]

I totally forgot to come back here. @kassi-moon-whaler, your solution works like a charm. Thanks so much! You made my day!