Re: [dev] [st] XIM switching problems in combination with XKB dead keys

From: Ivan Tham <pickfire_AT_riseup.net>
Date: Tue, 21 Jul 2020 01:22:04 +0800

On Fri, Jul 17, 2020 at 07:01:59PM +0200, Maarten van Gompel wrote:
>Hi,
>
>I identified a problem when switching input methods: XIM and XKB keymaps
>with dead keys can not be used properly in the same session as that
>breaks the dead keys (= composition keys for diacritics).

Hi,

st currently does not handle switching input methods on the fly.
Restarting XIM server works but not when st is on the foreground.
I did not foresaw this kind of use cases since I thought it is
unusual to restart XIM server while st is running directly.

>My situation: I use regular XKB to type in languages using a latin or
>cyrillic script, but for Chinese I need of course need a proper input
>method (e.g. fcitx or ibus-libpinyin). I want to change between input
>methods on the fly, this currently does not work, if st is started with
>a XMODIFIERS="_AT_im=whatever" then normal dead keys don't work, regardless
>whether the underlying XIM server is running or not, if it is started
>with an empty XMODIFIERS="", then they do work. It means I need to
>restart the terminal if I want to properly switch between chinese and my
>usual dead keys. Switching in my case entails killing the XIM server if
>it's running and running setxkbmap to set the desired keymap.
>
>To reproduce:
>
>Case 1)
> $ export XMODIFIERS=""
> $ setxbkmap es
> $ st
>Type apostrophe a and output is á , as expected, but of course no XIM now
>
>Case 2)
> $ export XMODIFIERS="_AT_im=fcitx"
> $ setxbkmap es #spanish XKB keymap to illustrate the issue
> $ st
>Type apostrophe a and output is 'a instead of á

Why not allow fcitx to handle dead keys? I never used dead keys but
I think it should be possible.

I think this behavior is correct, since st is supposed to use fcitx
as XIM server.

Supposedly, one shouldn't change setxkbmap but let the IME handle
that. I used to do that but that breaks my pinyin input from fcitx
when switching back and fourth between us and us-dvorak layout, I
then stopped relying on that and let fcitx handle the input.

>I think st should behave the same way most applications do; if the xim
>server is not running, it should exhibit the same behaviour as if no XIM
>was configured at all. (for comparison; terminals like urxvt and
>alacritty behave in this way, GTK and QT apps too)

We could add a check at first to see if XMODIFIERS is valid, but I
don't think the value of XMODIFIERS should be set if XIM server is
not running.

>The problem was introduced in the following commit:
>
> 787c9a55fea7131b4f1e5c7699b68b3517db8e49 Quentin Rameau x: fix XIM handling
>
>Prior to this commit though, the situation was much worse as st would
>simply crash if the XIM server stopped, so there's good progress but we
>aren't entirely there yet :)

Good, it did improved.
Received on Mon Jul 20 2020 - 19:22:04 CEST