Re: Android input methods

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Mon, 13 Feb 2023 22:37:19 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> My problem is that modes such as `electric-indent-mode' expect, for
> >> example, newline characters to be inserted by the return key, and do not
> >> indent if the change is made directly by the input method.
> >
> > is the only problem with such modes?  Or are there other issues?
> 
> There are many others: consider the vc-dir buffer: when you type ``mmmm
> i'', it expects individual key presses, each one of which marks a file
> or registers it with the VC system.

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.

> > If input methods are actually modifying relatively small portions of
> > text (even if they request much larger regions to do that), producing
> > single-key events from that should not be too hard: all you need is
> > compare two almost identical stretches of text.  Am I missing
> > something?
> 
> If you insert text, the input method might choose to suggest
> replacements for the text, typically of the surrounding word, but also
> sometimes up to entire sentences in length.

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

> In addition, there is a mode where the input method displays extracted
> text in a window of its own, and only sends the resulting changes back
> to Emacs after it finishes.  Such changes can be almost arbitrary in
> many cases.

Turn this off.

> However, I think I've found an easier solution that doesn't involve any
> text comparison: we can enable input methods only for editing modes that
> derive from `text-mode', and perhaps prog-mode as well, whilst utilizing
> the ASCII keyboard fallback on modes which derive from special-mode.

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.

> > No problems here, except the usual issue with our superset of UTF-8.
> > We'd need to encode the text.  However, for relatively short stretches
> > of text this should be fast enough.  And the other direction already
> > exists: decode_coding_gap.
> 
> This should be easy: we provide character positions and Unicode
> characters to the input method, but use the NULL byte for characters
> that are not representable in UTF-16 (including those which need to be
> represented by surrogate pairs.)

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?

> > Strange design.  Any idea why non-ASCII characters get such complex
> > treatment?
> 
> I don't know.  It seems to be an initial oversight that had to be kept
> for backwards compatibility reasons, because applications do not expect
> key events with (a definite misnomer) the `unicode_char' field set to
> some value greater than 127.  I can't find this written down anywhere,
> however, except there are simply no keymaps that map keys to larger
> characters.

<Shrug> Even MS-Windows is capable of accepting and processing UTF-16
encoded characters in its character input routines.  So I'm still
puzzled.