bug#21456: 24.5; Emacs does not respect fcitx as GTK input method

[Eric Abrahamsen]

On 12/04/20 10:53 AM, Lars Ingebrigtsen wrote:
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> Reproduction would likely require installing and configuring fcitx, if
>> you're willing to do that.
>
> Sure.
>
>> It's 100% reproducible, and I've started
>> Emacs like this for many years in order to make it work:
>>
>> env LC_CTYPE=zh_CN.UTF-8 /home/eric/dev/emacs/src/emacs
>>
>> I thought that might cause other weirdness in Emacs, but it never did,
>> not that I noticed.
>
> But how do you reproduce the error?

Start fcitx, configure it to toggle between English and Chinese, note
the "trigger key" (I've set mine to F7). Start Emacs, hit the trigger
key, and Emacs tells me "<f7> is undefined". In all other applications,
F7 toggles the input method.

It's been a while since I messed with this, so I did some
experimentation. I've had such hit-or-miss luck with using Emacs and the
system-wide input method that I think I've been using Emacs' own input
for a while. I'm using an Arch Linux machine running the sway Wayland
tiling window manager, and it turns out that under this setup fcitx
doesn't work in Emacs even with the LC_TYPE incantation that used to
work. I wasn't able to get the compose key to work either ("<print> is
undefined").

It's possible that the LC_TYPE thing will still work under X11.

I've been running the pgtk branch as a daily driver since it was added
to the repo, and under that branch both fcitx and the compose key work
as expected with no special configuration.

The package repos have a "fcitx" package, which I've never used, which
might solve this problem a different way.

HTH,
Eric