Re: Android input methods

[Po Lu <luangruo@yahoo.com>]

Eli Zaretskii <eliz@gnu.org> writes:

> These commands don't insert text, so I'm unsure how they are
> relevant.  The "mmm" is not inserted into a buffer, it is a series of
> 3 commands.

Right, but if you type ``mmm'' while the IME is active, then the IME
will try to insert ``mmm'' as text.

> This feature should be turned off.  It is incompatible with Emacs.  We
> request users to turn off bidi reordering of terminal emulators for
> similar reasons.  There's no way we can or should allow external
> features do stuff like that, because they will never be as flexible as
> Emacs features.
>
> At the very least we should disable them now.  Maybe later we will
> find less drastic solutions (or maybe the input methods will grow up
> and become friendlier to Emacs).

That is possible, but we will have to ask users to do that.

> Turn this off.

OK, we already try, but there is no guarantee that this will work.

> I don't believe this is so easy.  We'd need a more flexible control on
> when the input method is enabled and disabled.  Just the major mode is
> not fine-grained enough.

Any ideas there?  I mean, under what precise circumstances should Emacs
enable and/or disable the input method?

> We already have the machinery to replace un-encodable characters with
> a fixed character while encoding, but my point is that we will need to
> encode; we cannot just memcpy.  So this will be slower than just
> copying, but not terribly so.
>
> Btw, are you saying that the text should be encoded in UTF-16?  Is
> that because it's Java?

Yes.  And instead of code points or bytes, the positions given to Emacs
are in 16-bit short units, so to convert them to multibyte character
positions in Emacs without stripping out both unencodable characters and
those that require surrogate pairs will be nasty.