Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug] Space Cadet Shift and Auto Shift interaction produces unwanted () characters #20978

Open
2 tasks
lanslans opened this issue May 17, 2023 · 5 comments
Open
2 tasks

Comments

@lanslans
Copy link

Describe the Bug

Enable space cadet shift - left shift (, right shift )
Enable auto shift

Quickly type shift-letter, and release shift before releasing the letter.

When using left shift, the ( will be before the letter. When using right shift, the ) will be after the letter.

If you release shift after releasing the letter, the () will not print, and the keyboard works as you would want.

Keyboard Used

Leopold FC980m modded to run QMK off a bluepill

Link to product page (if applicable)

https://geekhack.org/index.php?topic=106758.0

Operating System

No response

qmk doctor Output

No response

Is AutoHotKey / Karabiner installed

  • AutoHotKey (Windows)
  • Karabiner (macOS)

Other keyboard-related software installed

No response

Additional Context

No response

@sigprof
Copy link
Contributor

sigprof commented May 18, 2023

process_space_cadet() needs to get all key press events, so that it is able to distinguish between taps and holds of Space Cadet keys (if any other key is pressed while a Space Cadet key is held down, the Space Cadet key is handled as a modifier hold even it gets released before the tapping term expires — this implements mostly the same logic as HOLD_ON_OTHER_KEY_PRESS for MT()/LT()).

However, process_record_quantum() calls process_space_cadet() later than process_auto_shift(), and process_auto_shift() returns false for key press events of auto-shifted keys (so that it is able to disable the normal press action for those keys, and decide whether to send a normal or a shifted key at the key release time). Because of that, any subsequent process_*() handlers for auto-shifted keys are not invoked, and this includes process_space_cadet(), therefore the Space Cadet code does not detect that some other key has been pressed together with the Space Cadet key, and will execute the tap action for the Space Cadet key if it gets released earlier than the tapping term.

The difference between the two shift keys is because the Auto Shift code treats only the left Shift modifier specially — it assumes that MOD_BIT(KC_LSFT) has been set by the Auto Shift code itself, but treats MOD_BIT(KC_RSFT) as an extra modifier if AUTO_SHIFT_MODIFIERS is not defined, and in that case the Auto Shift code emits the unshifted key immediately on press, instead of emitting the appropriately shifted key on release.

One way to fix this in the core is to move the call to process_space_cadet() so that it happens before process_auto_shift(), then process_space_cadet() would be able to detect the press of any auto-shifted keys and disable its tap action appropriately. This might still fail in some other cases though, because any other feature that returns false from its process_*() function will cause the same problem, so process_space_cadet() may need to be moved even earlier (e.g., the key override code may also return false for some keys).

Replacing Space Cadet keys with MT() and a customized tap action should work too, but would introduce a delay between the physical key press and the modifier registration, which may not be desired. Using a tap dance would also result in some undesired delays (the tap dance code does not have a callback to handle key release immediately, so an isolated tap would be handled only after the tapping term had expired). Implementing a custom space-cadet-like behavior in process_record_user() could be an option (that function is called much earlier than process_space_cadet()).

@lanslans
Copy link
Author

Do you know what changed to cause this issue?

The last time I built QMK firmware (December 2020), this wasn’t an issue.

@sigprof
Copy link
Contributor

sigprof commented May 18, 2023

On QMK 0.11.x (0.11.0 was released on 2020 Nov 28) I would expect that this problem would appear for the left Shift key, but not for the right Shift; the Auto Shift implementation in 0.11.0 had this code:

#    ifndef AUTO_SHIFT_MODIFIERS
    if (get_mods() & (~MOD_BIT(KC_LSFT))) {
        return true;
    }
#    endif

However, maybe you were still using some 0.10.x version of QMK (0.10.0 was released on 2020 Aug 29); the Auto Shift implementation in that version had this code:

#    ifndef AUTO_SHIFT_MODIFIERS
                if (get_mods()) {
                    return true;
                }
#    endif

So if you were using 0.10.x, any Shift modifier that was registered by a Space Cadet key prevented the Auto Shift code from activating for the next keypress, therefore that keypress was handled normally and reached the Space Cadet code as intended. But some subsequent Auto Shift improvements changed that code:

lanslans pushed a commit to lanslans/qmk_firmware that referenced this issue Jun 9, 2023
@lanslans
Copy link
Author

lanslans commented Jun 9, 2023

lanslans@37d3fb3

I fixed it here on my own repo.

I'm hesitant to make a pull request for this, because I don't know if it will screw things up for anyone else.

@IsaacElenbaas
Copy link
Contributor

Auto Shift is horribly complicated now to work with Tap Holds and such (though some of that can be removed once I fix conflicts in my bugfix PR for it). For most features it doesn't work with, especially where the issues are related to which feature eats keys, I would say yeah - just move the other above Auto Shift if that works well enough.

Space Cadet is trivial to reimplement through custom auto shift keys if people use both and are having issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants