Re: [m17n-list] Modifier Keys for fcitx-m17n?

[Richard Wordingham]

On Fri, 17 Nov 2017 00:52:16 +0000
Richard Wordingham <address@hidden> wrote:

> On Thu, 16 Nov 2017 22:37:57 +0900
> handa <address@hidden> wrote:
> 
> > At the moment I can't try it
> > because I don't know how to generate "AltGr"ed key on my Japanese
> > keyboard.  

I wonder if that is related to how the problem seems to have gone
undetected.

> It seems that fctix-m17n is innocent.  The culprits seems to be higher
> up in fcitx.

The culprits in fcitx are indeed ximhandler.c (for X) and ipc.c (for
GTK, e.g. LibreOffice) in Fcitx Version 4.2.9.1.  The most obvious
correction is defeated by the utility routine FcitxHotkeyGetKey(), which
looks as though it would case grief for case sensitivity with super and
hyper.  (None of the input methods in the main M17n database uses these
two modifiers.)

The fix that works for AltGr bound to mod5 is to insert the following
line immediately before the call of FcitxInstanceProcessKey():

    state |= originstate & FcitxKeyState_ScrollLock;

The corresponding sharable objects on Ubuntu (at least, on 
Xenial 16.04) are fcitx-xim.so and fcitx-ipc.so.

The binding works by the AltGr key being declared to have keysym
ISO_Level3_Shift, and then keysyms ISO_Level3_Shift and Mode_Switch
being bound to modifier mod5.

Are there environments where an M17n input method should duplicate a
mapping for, for instance, G-i, with the same mapping for A-i?

Richard.