Bug 26705

Created attachment 33497 [details] [review]
changes in modules/im/ximcp

I would like to use modifiers keys (such as Control_L or Shift_R) as
dead keys in compose sequences.

Currently, only non-modifiers can be part of a compose sequence, and
they are matched against the defined compose sequences at the time the
key is pressed.  I want to extend this to modifier keys, but in contrast
to non-modifiers, they should be matched to the defined compose
sequences when the key is released, and only when no other key has been
pressed since the modifier had been pressed.

When a compose sequence is ongoing, but a non-matched non-modifier key
is pressed, the compose sequence is aborted.  In contrast, for backward
compatibility, releasing a non-matched modifier during an ongoing
compose sequence should have no effect, rather than aborting the compose
sequence.

From the user's point of view, compose would work as before, as long as
no compose sequences with modifiers are defined.  As non-modifiers only
trigger on key press, and modifiers only on key release, no additional
syntax is required in the Compose file to distinguish the two cases.

For example,

<Control_L>    : ssharp
<Shift_R> <o>  : odiaeresis

would allow to enter an ß with the left control key, and an ö by a
sequence of right shift key and o.

Why is this useful?  The number of keys in convenient reach for touch
typing is limited.  The proposal would allow to make double use of
modifier keys, some of which have a fairly good position on the keyboard
(in particular, the Control key to the left of A on Unix-style
keyboards).  So, the motivation is typing efficiency.

I attach a patch that achieves what I want.  The code in
ximcp/imLcFlt.c abuses storage for the Thai input method; this might
not be acceptable for production code, but avoids changing data
structure sizes.  The change in ximcp/imLcIc.c is necessary for GTK (I
believe that it is alse necessary to make the Braille code that
already existed in ximcp/imLcFlt.c work).