Re: Android input methods

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Tue, 14 Feb 2023 09:57:29 +0800
> 
> 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.

Which is why IME should be turned off in that case.  For comparison,
no one in their right mind will type "mmm" in that case while some
Leim input method is active, right?

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

If there's no way to do that programmatically, yes.

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

Don't know yet.  I suggest to have some variable that Lisp can bind to
control this.  Then we'll find the cases where it is needed as we go.

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

I wouldn't call that "nasty".  AFAIU, we will need a UTF-16 variant of
BYTES_BY_CHAR_HEAD (called, say, UNITS_BY_CHAR_HEAD), and the rest is
relatively simple, like what we do with our internal encoding.