[Patch] Improvement for unicode.mim, allow all Unicode chars, not only BMP

[Mike FABIAN]

unicode.mim currently supports only characters from the BMP.

And it commits after typing 4 hex digits without waiting for a space to
commit which causes problems for some users, see:

https://github.com/ibus/ibus-m17n/issues/4

I improved unicode.mim to allow typing all Unicode characters like this:

- I allowed typing any number of hex digits and made it commit only
  when a space is typed.
- When more than 5 hex digits are typed and space is used to commit,
  an empty string is committed.

A patch 0001-Improve-unicode.mim-to-allow-input-of-characters-abo.patch
is attached.

This patch makes the behaviour almost the same as the Shift+Ctrl+u Unicode input
ibus offers.

“Almost” because ibus uses just “u” as the prompt whereas unicode.mim
uses “U+” as the prompt. I thought keeping that difference in the
prompt is good so one can easily see which Unicode input mechanism is used.
In case somebody reports a problem one could ask how the prompt looks like
to know immediately whether the problem is m17n or ibus related.

But apart from the prompt it is probably better to make the rest of
the behaviour the same.

The default key binding for ibus to start Unicode code point input is
Shift+Control+u.  In case of unicode.mim, both Control+u *and*
Shift+Control+u start the Unicode code point input.

Control+u seems to cause a problem for some users because it masks
that keyboard shortcut for example in LibreOffice Writer where it is used
to underline text. See:

https://github.com/ibus/ibus-m17n/issues/44#issuecomment-1047663137

unicode.mim contains this to define the keybinding to start Unicode
code point input:

(command
 (start (_"Start Unicode
Start typing hexadecimal numbers of Unicode character.")
        (C-U)))

But even though Shift is not mentioned there, both Shift+Control+u *and*
Control+u start Unicode code point input!

I tried to change that to (S-C-U), (S-C-u), (C-S-U), or (C-S-u) but
that doesn’t change anything at all, still Unicode code point input
is started both with Shift+Control+u *and* Control+u.

Then I changed it to (C-a) and now I can also start Unicode code point
input by typing Control+a *but* the original key binding Control+u is
also still working.

So the Control+u seems to be hardcoded somewhere else outside of the unicode.mim
file, maybe somewhere in m17n-lib.

How can that be changed? Changing it to Shift+Control+u would probably cause
less conflict with key bindings in other programs.

Another thing which I didn’t know and which surprised me a lot is this:

One does not need to explicitly switch to the unicode.mim input method
to do this Unicode code point input. Using *any* m17n input method
seems to implicitly also load unicode.mim somehow.

For example, I can use the hi-itrans.mim input method and while
using that type Control+u and input a Unicode character by its code point.

That is quite convenient because one can keep using hi-itrans.mim and quickly
input a character not available in hi-itrans.mim without having to switch
explicitly to unicode.mim. This is really nice, but it makes the conflict
of Control+u with key bindings in other programs more serious.


-- 
Mike FABIAN <mfabian@redhat.com>
睡眠不足はいい仕事の敵だ。

ttt
Description: Binary data