How to reproduce:
setxkbmap -layout us -variant dvorak-alt-intl -option compose:caps.Expected behaviour: It should print "氓".
Actual behaviour: It prints "aa".
I cannot reproduce this with compose:menu.
@Mikaela Did you try with Caps Lock?
@victor-catalyst When I wrote the comment I didn't, I communicated unclearly and tried to point out that the issue title is invalid.
However now that I asked, I tried and Caps Lock as compose key works without issues*, so I cannot reproduce this.
From required info of Contributing.adoc:
lsb_release -saI am running the toppernmost details are from my localhost (rxvt-unicode (urxvt) v9.22 - released: 2016-01-23) in tmux 2.6 and the lower is over ssh in tmux 1.9.
* to be honest I did encounter irrelevant issues such as copy-pasting setxkbmap -layout us -variant dvorak-alt-intl -option compose:caps to my terminal without sanity checking it first as I am using Finnish/Swedish QWERTY keyboard and it took me a moment to restore back from US Dvorak and after adjusting my own command I accidentally first wrote capslock instead of caps which naturally didn't work and when I reached the correct command (setxkbmap -option compose:caps -option terminate:ctrl_alt_bksp -option nbsp:none) I had locked my laptop to only use Caps Lock which again took a little of searxing to find these instructions for disabling Caps Lock from terminal where finally sudo pacman -S xdotool && xdotool key Caps_Lock finally let me out of CAPS LOCKED state. I think Caps Lock as Compose is a nice idea and I might be copying you later, have you encountered any drawbacks that way?
I don't know what else to do then, because it works in at least Firefox, Thunderbird, XTerm+Bash. Interestingly, I tested with two applications where I have never needed the compose key, JetBrains IDEA and Git GUI, and it fails in both of them as well. So this is actually a wider issue. My bad.
Looking at various bugs and suggestions (1, 2) it appears that the trick is to run ibus-daemon --xim.