Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Caps Lock is always a Caps Lock (even when also something else) #1979
The title is a bit weird, so let me explain. This is a followup of #1976 which is mostly fixed, but I realized something is still not perfectly right. So basically my Caps lock key is remapped to the Compose key with the 'compose:caps' option.
Expected result: the light on the CapsLock key must not switch on, Capitalization of letter must not be locked for subsequent letters, and "œ" must be outputted.
Actual result: the light on the CapsLock key goes on, Capitalization of letter is locked for subsequent letters, and "Œ" is outputted.
Why I didn't realize it before was because the first input in my list was "Japanese" (not "Ibus-Anthy" but the Japanese qwerty layout). And apparently this layout overrides the CapsLock key. Moreover since it turns out that the order of layouts/inputs matter, having Japanese first, then "Ibus-Hangul" or "Ibus-Anthy" after make them behave as expected (only Compose, no CapsLock), which is great since there is at least a workaround to my problem (always leave Japanese layout first of the list)!
Now it's less a big issue to me as long as the workaround works. But this is obviously not long term solution. One should be able to set Ibus-Anthy or Ibus-Hangul (or other ibus engines which I have not tested) first in their input list and have the "caps:compose" option work as expected (as an override to CapsLock).
I would like to understand how to fix this, and where is the problem in the input stack. Is it in Ibus? In Ibus-Hangul/Anthy? Other?
Probably I think your issue is GNOME.
Because ibus-ui-gtk3 just runs setxkbmap internally.
Thanks, I opened a bug report in GNOME: https://gitlab.gnome.org/GNOME/gnome-shell/issues/14