It was hard to find, so I want to share how I got Compose key configured’n’working on Archlinux. Note: if you’re reading it in the future, I hope some of the problems (e.g. with ibus) are outdated. Leave a comment if that’s true.
At the moment of writing this, the Internet has pretty scarce info about text input internals for GNU/Linux. Most of the info I got by arguing with ibus maintainer here, here, and here. What you may want to know with relation to Compose key, is that the input (including XCompose) is done with XKB protocol. It sounds pretty X11, but is used on Wayland either.
An important note: the Compose Input Methods in either ibus or fcitx has lame imitations, they doesn’t even read
~/.XCompose. That’s not what you want, the real XCompose have to be configured with XKB, and is not an IM.
To make XCompose working with ibus you’d have to set globally (in the
/etc/profile) GTK_IM_MODULE and QT_IM_MODULE variables to
ibus, then “XMODIFIERS=@im=ibus” (this one may be not mandatory, Idk), and either execute
setxkbmap -option compose:rwin (substitute
rwin with the favorite key if needed), or set it up in the dungeon of XKB configuration (I couldn’t find quickly for where and how, and configured via X-files, see below, but it won’t work obviously with Wayland).
The ibus way worked with gnome-on-wayland as well as on X11, but you didn’t really want ibus as it’s pretty raw. To me the most annoyng are non-working LED on layout switch, and missing support for multicharacters, i.e. you can’t configure getting
the on pressing Compose+t. CJK people doesn’t like ibus either. Fortunately, even though ibus maintainer doesn’t seem to be interested in fixing anything personally, at least they maintains it, so you can write a patch, and hope the PR to be merged.
I’m using instead the fcitx implementation of Compose (and I didn’t test it with Wayland), but it is tricky, so follow the hands!
- Install fcitx.
- Add into the
/etc/profile (or wherever to be exported globally, overwrite if you had the variables set to anything else):
- Important: make sure that fcitx daemon is not running! Idk why, but for it starts, everything breaks. The daemon shalt not pass! From what I understand, Qt and GTK, and may be EFL, are having some internally supplied fcitx modules (about GTK it’s for sure) that probably get called. Still, why fcitx daemon kills the fun, is a puzzle.
Configure the Compose key. For starters, just to test if it works, you could run
setxkbmap -option compose:rwin (to set the right win-logo key as Compose), then press some combinations. Ideally you’d have to have the
~/.XCompose file, and to press its combinations, to make sure it’s being read. If everything is fine, you could configure it via X11 files (and may be XKB ones, but Idk how). Here the X11 example I’m using:
$ cat /etc/X11/xorg.conf.d/00-keyboard.conf
# Read and parsed by systemd-localed. It's probably wise not to edit this file
# manually too freely.
Option "XkbLayout" "us,ru"
Option "XkbModel" "pc105"
Option "XkbOptions" "grp:rctrl_rshift_toggle,grp_led:scroll,lv3:ralt_switch,compose:rwin"
Now, if you look at
00-keyboard.conf example thinking of ibus, make sure to remove the language switch option, so that it wouldn’t conflict with ibus config.
You may want a ready to go XCompose file (the dotxcompose in the repository) as a
~/.XCompose. It’s made to be backward-compatible with system XCompose file, so you may want to overwrite some combinations, in particular these to press a ^ just single time.