|Summary:||CapsLock remapped to Compose key broken|
|Status:||RESOLVED NOTOURBUG||QA Contact:|
|i915 platform:||i915 features:|
Description Jehan 2017-12-03 14:36:25 UTC
My system is Fedora 27/GNOME 3.26. I remap the CapsLock into the compose key using the tweak tool, which apparently set /org/gnome/desktop/input-sources/xkb-options dconf settings as: ['compose:caps']. This used to work, but stopped working from Fedora 26/GNOME 3.24. Also it is never working, but inconsistently, i.e. differently depending on the order of my layouts. - If I set "Korean (Hangul)" first and "Japanese" second, CapsLock will still work as a normal CapsLock in both layouts: the key will lights on and off and the letters will be uppercase on light-on, and lowercase on light-off. - If I set "Japanese" first and "Korean (Hangul)" second, CapsLock will work as a Compose key for "Japanese" layout (yeah!), but it will still not work as a Compose for the "Korean (Hangul)" layout. Nevertheless it will stop working as a CapsLock either, meaning the key will be simply rendered useless in "Korean (Hangul)". I first opened this bug to libxkbcommon (cf. bug 104040) where I was told to reopen it for xkeyboard-config. Apparently I was informed that the order does indeed matters and that the "Japanese" layout overrides explicitly the CapsLock: https://cgit.freedesktop.org/xkeyboard-config/tree/symbols/jp?h=xkeyboard-config-2.22#n47 Nevertheless this is not good, first because we should still be able to re-override ourselves the CapsLock to Compose ourselves, over any layout. And by the way, it works over "Japanese"! So we did re-overrided the override there! Unfortunately my main layout is "Korean (Hangul)", I want my Compose there and it used to work just a few versions before. So that's a regression! :-) Expected result: a layout override such as ['compose:caps'] should work over every layout of one's list whatever their order and their own overrides. Therefore it should be applied last, I guess.
Comment 1 Jehan 2018-01-18 04:28:14 UTC
Hello! I have been playing with xkeyboard-config today, and I am not sure this is the actual culprit in the issue. Could you tell me if you think I am barking at the wrong tree? Do you think that maybe the issue is in ibus? Or maybe ibus-hangul? Or even another component? The topic involves so many software that I am a bit lost to where I should look for a fix.
Comment 2 Sergey V. Udaltsov 2018-01-18 19:22:26 UTC
to me it looks like ibus issue, dealing with Korean and Japanese in GNOME
Comment 3 Jehan 2018-01-19 01:14:45 UTC
Just for the record, after going through many components in the chain of text input, I could finally find the issue as being a side effect in ibus-hangul behavior because of a recent change in ibus (the bug was not in ibus, but triggered by it). So I made a fix in ibus-hangul: https://github.com/choehwanjin/ibus-hangul/pull/54 This whole mapping difference when changing the order of inputs was weird but unrelated (and apparently an expected behavior, even though I find this a bit bad because it makes for non-consistent input behaviors).