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

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

[Zachary Acreman]

Emacs compiled with GTK does not respect fcitx as the system-wide GTK
input method.

When I use a keyboard configuration with right-alt mapped to Compose, I
get "<Multi-key> is undefined" messages in Emacs instead of the expected
behavior.

When I use a keyboard configuration with dead keys for accented
characters, I get messages like "<dead-acute> is undefined" instead of
the expected behavior.

Chinese Pinyin input methods are ignored.

XMODIFIERS=@im=fcitx
GTK_IM_MODULE=fcitx

fcitx input works correctly in every other application on this system
that I have tested.

I am using a freshly downloaded and compiled 24.5 source distribution,
because I saw the same problems with the Ubuntu-provided 24.4
package. For the purposes of this bug report, I am running the binary
with the -Q flag.

In GNU Emacs 24.5.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.14.13)
  of 2015-09-10 on guru
Windowing system distributor `The X.Org Foundation', version 11.0.11701000
System Description:    Ubuntu 15.04

Important settings:
   value of $LC_MONETARY: en_US.UTF-8
   value of $LC_NUMERIC: en_US.UTF-8
   value of $LC_TIME: en_US.UTF-8
   value of $LANG: en_US.UTF-8
   value of $XMODIFIERS: @im=fcitx
   locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
   tooltip-mode: t
   electric-indent-mode: t
   mouse-wheel-mode: t
   tool-bar-mode: t
   menu-bar-mode: t
   file-name-shadow-mode: t
   global-font-lock-mode: t
   font-lock-mode: t
   blink-cursor-mode: t
   auto-composition-mode: t
   auto-encryption-mode: t
   auto-compression-mode: t
   line-number-mode: t
   transient-mark-mode: t

Recent messages:
Menu-Bar mode disabled
Menu-bar mode disabled.  Use M-x menu-bar-mode to make the menu bar appear.
Menu-Bar mode enabled
Quit
Making completion list...
Quit
<Multi_key> is undefined [5 times]
@im=fcitx
Making completion list... [2 times]
Quit

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util
help-fns mail-prsvr mail-utils help-mode easymenu cus-start cus-load
time-date tooltip electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel x-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list newcomment lisp-mode prog-mode register page menu-bar
rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax
facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak
czech european ethiopic indian cyrillic chinese case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer nadvice loaddefs button
faces cus-face macroexp files text-properties overlay sha1 md5 base64
format env code-pages mule custom widget hashtable-print-readable
backquote make-network-process dbusbind gfilenotify dynamic-setting
system-font-setting font-render-setting move-toolbar gtk x-toolkit x
multi-tty emacs)

Memory information:
((conses 16 78990 7449)
  (symbols 48 18422 0)
  (miscs 40 41 99)
  (strings 32 10686 3295)
  (string-bytes 1 276107)
  (vectors 16 8990)
  (vector-slots 8 384103 17853)
  (floats 8 65 423)
  (intervals 56 227 16)
  (buffers 960 13)
  (heap 1024 44666 967))

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

[Lars Ingebrigtsen]

Zachary Acreman <zakk@acreman.net> writes:

> Emacs compiled with GTK does not respect fcitx as the system-wide GTK
> input method.
>
> When I use a keyboard configuration with right-alt mapped to Compose, I
> get "<Multi-key> is undefined" messages in Emacs instead of the expected
> behavior.
>
> When I use a keyboard configuration with dead keys for accented
> characters, I get messages like "<dead-acute> is undefined" instead of
> the expected behavior.
>
> Chinese Pinyin input methods are ignored.
>
> XMODIFIERS=@im=fcitx
> GTK_IM_MODULE=fcitx
>
> fcitx input works correctly in every other application on this system
> that I have tested.

(This bug report unfortunately got no response at the time.)

Do you have a recipe, starting from "emacs -Q", to reproduce this issue?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Eric Abrahamsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Zachary Acreman <zakk@acreman.net> writes:
>
>> Emacs compiled with GTK does not respect fcitx as the system-wide GTK
>> input method.
>>
>> When I use a keyboard configuration with right-alt mapped to Compose, I
>> get "<Multi-key> is undefined" messages in Emacs instead of the expected
>> behavior.
>>
>> When I use a keyboard configuration with dead keys for accented
>> characters, I get messages like "<dead-acute> is undefined" instead of
>> the expected behavior.
>>
>> Chinese Pinyin input methods are ignored.
>>
>> XMODIFIERS=@im=fcitx
>> GTK_IM_MODULE=fcitx
>>
>> fcitx input works correctly in every other application on this system
>> that I have tested.
>
> (This bug report unfortunately got no response at the time.)
>
> Do you have a recipe, starting from "emacs -Q", to reproduce this issue?

Reproduction would likely require installing and configuring fcitx, if
you're willing to do that. 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.

Actually, I'm running the pgtk branch as my daily driver now, maybe it's
time to remove that incantation and see if anything's changed.

Eric

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

[Lars Ingebrigtsen]

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?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

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

[Lars Ingebrigtsen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> 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.

I've never used any of that stuff, so bear with me:

I say

$ fcitx
[...]
(INFO-1295180 addon.c:151) Load Addon Config File:fcitx-x11.conf
(INFO-1295180 addon.c:151) Load Addon Config File:fcitx-vk.conf
(INFO-1295180 addon.c:151) Load Addon Config File:fcitx-classic-ui.conf
(INFO-1295180 addon.c:151) Load Addon Config File:fcitx-xkb.conf
(INFO-1295180 addon.c:151) Load Addon Config File:fcitx-keyboard.conf
(INFO-1295180 addon.c:151) Load Addon Config File:fcitx-notificationitem.conf
(ERROR-1295180 ime.c:432) fcitx-keyboard-in-tel-kagapa already exists
(ERROR-1295180 ime.c:432) fcitx-keyboard-cm-mmuock already exists
$

Now what?  I don't see any way to configure anything, and "man fcitx" is
singularly unhelpful.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Eric Abrahamsen]

On 12/06/20 14:11 PM, Lars Ingebrigtsen wrote:
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> 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.
>
> I've never used any of that stuff, so bear with me:
>
> I say
>
> $ fcitx
> [...]
> (INFO-1295180 addon.c:151) Load Addon Config File:fcitx-x11.conf
> (INFO-1295180 addon.c:151) Load Addon Config File:fcitx-vk.conf
> (INFO-1295180 addon.c:151) Load Addon Config File:fcitx-classic-ui.conf
> (INFO-1295180 addon.c:151) Load Addon Config File:fcitx-xkb.conf
> (INFO-1295180 addon.c:151) Load Addon Config File:fcitx-keyboard.conf
> (INFO-1295180 addon.c:151) Load Addon Config File:fcitx-notificationitem.conf
> (ERROR-1295180 ime.c:432) fcitx-keyboard-in-tel-kagapa already exists
> (ERROR-1295180 ime.c:432) fcitx-keyboard-cm-mmuock already exists
> $
>
> Now what?  I don't see any way to configure anything, and "man fcitx" is
> singularly unhelpful.

Sorry, I could have given more useful directions. What system are you
on? Are these errors preventing fcitx from starting up at all?

On Arch Linux I installed the "fcitx", "fcitx-libpinyin", and
"fcitx-googlepinyin" libraries -- the last two each have a dependency,
"libpinyin" and "libgooglepinyin", respectively. libpinyin and
libgooglepinyin are redundant with each other, as far as I can tell
either one should display the erroneous behavior, but you might have an
easier time installing one over the other.

There's also a "fcitx-configtool" which provides a GTK view on the
config files, that might be more work than it's worth.

On my machine the TriggerKey config is set in ~/.config/fcitx/config.
You might have to look around, but try to find the TriggerKey item. Once
fcitx is running, that's your hotkey for toggling input.

If fcitx won't start at all... I'm not sure how to debug that.

Eric

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

[Lars Ingebrigtsen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Sorry, I could have given more useful directions. What system are you
> on? Are these errors preventing fcitx from starting up at all?

No, it seems to start up fine...

> There's also a "fcitx-configtool" which provides a GTK view on the
> config files, that might be more work than it's worth.

Ah, yes, that command exists here and seems to work.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no