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

[handa]

In article <address@hidden>, Richard Wordingham <address@hidden> writes:

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

Thank you for debugging this problem.  But, if the problem is
in fcitx, please suggest your solution to the developpers of fcitx.

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

What do you mean by "duplicate"?  When an M17n input method contains a
rule for A-i, that rule should be fired even if a user types G-i?  Then,
no.   I think there's no such a situation.

---
K. Handa
address@hidden