GNU bug report logs - #53698
29.0.50; ibus input method of chinese with rime engine can't work in v27 and ibus candidate menu blink in v29

Previous Next

Full log

Message #26 received at 53698 <at> debbugs.gnu.org (full text, mbox):

From: Štěpán Němec <stepnem <at> gmail.com>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 53698 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 江 暇疆 <aiselcce <at> outlook.com>
Subject: Re: bug#53698: 29.0.50; ibus input method of chinese with rime
 engine can't work in v27 and ibus candidate menu blink in v29
Date: Thu, 03 Feb 2022 13:49:52 +0100

On Thu, 03 Feb 2022 20:06:13 +0800
Po Lu via wrote:

> Štěpán Němec <stepnem <at> gmail.com> writes:
>
>> The problem with that option is that it apparently breaks some key
>> modifiers, e.g. with x-gtk-use-native-input non-nil it becomes
>> impossible to bind C-S-u (Emacs processes it the same as C-u).
>
> Yes, the problem is the same as on the PGTK port, since both use the
> same input method system.
>
>> AFAICT, X input has been broken (or rather, you get to pick: either you
>> get working IME (with x-gtk-use-native-input non-nil), or working
>> modifier keybindings (with it being nil); but given that
>> x-gtk-use-native-input defaults to nil, for many/most people IME will
>> just stop working;
>
> It works here for me (Fedora 35, stock GNOME with IBus), but we do want
> to fix this problem and keep X input methods working as well as they
> used to.

I don't use any desktop environment, just plain X.Org (with XMonad on
Arch Linux).

> Do you see the same problem in other programs that use XIM, such as
> xterm?

No, it continues working everywhere as before (including xterm), with
the exception of Emacs.

> If not, try placing:
>
>   Emacs.inputStyle: none
> in your X defaults file, and see if that solves the problem.

It does not (no observable effect).

> Most of this is caused by a more fundamental problem: XIM is an obsolete
> interface with many limitations; most applications today rely on the
> authors of input method frameworks to provide input modules for their
> specific toolkit, and as a result the XIM backends for input method
> frameworks get very little testing and are buggy.
>
> Unfortunately, since we cannot demand that input method frame developers
> provide modules specifically for supporting Emacs, the only choice we
> have is between using the legacy interface standard to X (XIM) or the
> toolkit's input method system (GTK native input), each with its own
> limitations and advantages.
>
> It's a sad situation, but there's nothing we can do.
>
>> also, it's not just IMEs like fcitx or ibus, XkbLayout switching has
>> the same problem) since the commit that introduced the option
>> (bisected yesterday):
>>
>> commit d76fb0c11e98
>> Author: Po Lu <luangruo <at> yahoo.com>
>> Date:   Sat Jan 8 15:21:51 2022 +0800
>>
>>     Allow using GTK+ to handle input methods on X
>
> Are you sure that's the commit which introduced this bug, and not one of
> the preceeding commits that added features to the XIM support?

Yes.  My git-bisect(1) invocation was

  git bisect start 3dfefb8bb4d9 041fff3d3dda

and given the interactive nature of the issue, I watched IME/XkbLayout
switching break and work again repeatedly while jumping around the
commit. The preceding 63c83e4 does not exhibit the issues.

> I find that hard to believe, since it doesn't touch anything related to
> XIM.

-- 
Štěpán

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.