[ENHANCEMENT] Compose using transliterated characters

[ajithramayyan]

Is your feature request related to a problem? Please describe

Currently ibus typing booster compose mechanism relies on the key event. Please consider adding the option of compose sequences to derive the value from the transliterations.

Describe the solution you’d like

As an example, en-pn-eqf transliterates the double quotes to hyphen. With the current mechanism, to use Compose - -, I need to press the key to the right of 0 though in the layout hyphen is to the left of the "Enter" key. My request is to include an option so that users have the choice to direct bus typing booster to use transliterated values in place of key events.

Describe alternatives you’ve considered

No response

Anything else?

No response

[mike-fabian]

d25414f

This is an experimental patch which I think solves your problem.

I think I don’t want to include this in the next release yet, I think this is sort of experimental and needs more testing, I am not sure whether yet whether this has surprising disadvantages.

If you want you can test as well by checking out the https://github.com/mike-fabian/ibus-typing-booster/compare/compose-transliterate branch, build, install and test.

[ajithramayyan]

Thanks for the quick fix. Yes, it is working well.
One thing I noted is the change that happens when I type an invalid compose sequence:
While using pn-eqf, if I type Compose + minus + period and then space, then the sequence I typed changes to )y.
I do not understand whether this is expected or not.

[mike-fabian]

Thanks for the quick fix. Yes, it is working well. One thing I noted is the change that happens when I type an invalid compose sequence: While using pn-eqf, if I type Compose + minus + period and then space, then the sequence I typed changes to )y. I do not understand whether this is expected or not.

Yes, hat is expected. When you are using an English US keyboard layout (Or something which is almost the same like the Indian English keyboard layout and type Compose + " + ' then with my new patch the " and the ' are not used directly but their transliterations according to your en-pn-eqf.mim input method. Your input method transliterate these as follows:

("\"" "-")
("'" ".")

Therfore you see -. in the preedit now.

If you then type Tab you could see the possible completions of that compose sequence. If you type a character which cannot continue this compose sequence (but is not a commit trigger key), you hear an error beep and can continue to try other keys to complete the compose sequence or remove characters from the compose sequence with Backspace to correct it.

But you you type a commit trigger key like space, Left, Right, ... then this aborts processing the compose sequence, inserts the current contents of the preedit, i.e. -. into the input and returns False to let normal processing of the input -. continue. Apparently using this as a Compose sequence was abortet, so the fallback is to try using it as normal input into your input method.

So now -. is fed again into your en-pn-eqf.mim input method and this transliterates this input as follows:

("-" ")")
("." "y")

I.e. -. is now transliterated as )y and the space then commits this and adds a space so the final result is )y .

If a compose sequence is aborted by a commit trigger key, it is treated as "normal" input instead as a fallback.

That might be a bit surprising but it has some logic.

If you decide that you want to discard that compose sequence and not finish it or further process it as normal input, you can cancel it with Escape.

Do you think my patch is an improvement?

It seems more useful than the behaviour before my patch.
For example, /usr/share/X11/locale/en_US.UTF-8/Compose contains

<Multi_key> <U093C> <U0930> : "ऱ" U0931 # DEVANAGARI LETTER RRA

when using hi-inscript2.mim and the typed keys are used directly for compose without transliteration, there would be no way to type that compose sequence, the untransliterated keys are all ASCII, typing <U093C> <U0930> is not possible.
When using a inscript keyboard layout from /usr/share/X11/xkb/symbols/in, one could type <U093C> <U0930> and use this compose sequence.

The /usr/share/m17n/hi-inscript2.mim input method has transliterations which produce these characters though, it transliterates:

    ']' to ़ U+093C DEVANAGARI SIGN NUKTA
    'j' to र U+0930 DEVANAGARI LETTER RA

because it contains this:

("]" "़")
("j" "र")

I think it makes sense to assume that a user of hi-inscript2 when typing ] and j wants the transliterations and not the ASCII characters, so it makes sense to also use the transliterations in the compose sequence.

So I think my patch is an improvement.

I did some more testing and also added a test case and I am quite confident now that it does not break anything.

So I think I could include it in the next release.