Caps Lock is always a Caps Lock (even when also something else)

[Jehan]

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.
But in most input engines (well I haven't tested them all), I realized it still also works as a Caps Lock as well (i.e. the light switches on and uppercase is locked).

Steps:

• Set 'compose:caps' (for instance if you use GNOME, you can just use GNOME Tweaks Tool, in the "Keyboard & Mouse" tab, there is a "Compose Key" option which does the work for you).
• Have Ibus-Anthy or Ibus-Hangul on. They must be the first in the list of inputs.
• Be in the LATIN mode.
• Hold CapsLock + o + e.

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.
So "compose:caps" did not just override the CapsLock behavior but instead added the compose behavior (and the key does both at once, which is weird).

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)!
See: https://bugs.freedesktop.org/show_bug.cgi?id=104040#c2

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?
Hopefully once again, you can help.
Thanks.

[fujiwarat]

Probably I think your issue is GNOME.
I cannot reproduce your problem in XFCE4.

1. Run setxkbmap -layout us -option compose:caps
2. Run ibus-daemon

Because ibus-ui-gtk3 just runs setxkbmap internally.
But gnome-shell(mutter) uses combined layouts e.g. us,jp and switches layouts by the index.

[Jehan]

Indeed.
Also I realize the issue even happens with non-Ibus layouts, like "English (US)".

Thanks, I opened a bug report in GNOME: https://gitlab.gnome.org/GNOME/gnome-shell/issues/14
Closing this one.