[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Android input methods

From: Po Lu
Subject: Re: Android input methods
Date: Tue, 14 Feb 2023 09:57:29 +0800
User-agent: Gnus/5.13 (Gnus v5.13)

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]