I have a customized /usr/share/X11/locale/en_US.UTF-8/Compose file which worked fine in practically all applications (except OpenOffice, they seem to use their own ^%$@*&}{~<?;"]% keyboard input handler. Since one of the last system updates (emerge -uND world) however, my Xcompose file seems to be respected only in Konsole for as far as I can see. It seems as if the original key compositions are in place now — one example: I defined compose-m-minus as m-dash (whereas in the default configuration, the m-dash is composed from compose-minus-minus-minus). In konsole, I still can use compose-m-minus (and compose-minus-minus-minus does not work), whereas everywhere else (as far as I can see), I can only get the m-dash by composing it with compose-minus-minus-minus (and compose-m-minus does not work). What's going wrong? Reproducible: Always Steps to Reproduce: 1. Edit your /usr/share/X11/locale/en_US.UTF-8/Compose (or whatever locale you use instad of en_US.UTF-8), adding the following line at the end (this won't interfere with anything else per se): <Multi_key> <m> <minus> : "—" U2014 # EM DASH 2. In the SystemConfig/Input Devices/Keyboard/Advanced, select CapsLock in the "Position of Compose key" setting. 2. Restart X 3. Hit <caps lock> M - In konsole, you might see a long dash (—), in all other applications, you might hear a beep instead. Actual Results: Beeps (to signal that the key composition was not understood) Expected Results: Produces the m-dash (—)
When I noticed that only non-KDE applications were actually affeted, I remembered that I had to set the GTK_IM_MODULE variable to make the Compose file work. The solution then was to add the following lines to /etc/environment: GTK_IM_MODULE=xim QT_IM_MODULE=xim
