Re: Android input methods

[Po Lu]

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.

> OK, so let's talk about the details in those case where we would like
> to produce single-key events to Emacs.
>
> How large are the "preconversion text" regions in practice?  You
> described quite large regions, but I'm not sure I understand why an
> input method would want to manipulate such a large portion of text.
> Surely, inserting a single non-ASCII character never needs to
> manipulate more than a few character positions?  I mean, to type a
> character one usually needs to enter a small number of keystrokes;
> anything else would make typing extremely inconvenient and slow.
>
> 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.

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.

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.

It should be easy to fix electric indentation and other
prog-mode-features to handle text insertion by the input method.

Apparently (and this is not written in any documentation), if you set
the input type to TYPE_CLASS_TEXT without providing any ``input method
connection'', even input methods that normally don't provide the ASCII
keyboard fallback can be convinced to do so.

>> >> If Emacs makes a change to the buffer outside the area in which the
>> >> input method expresses interest, then it is obligated to ``restart'' the
>> >> input method.  This takes a significant amount of time to complete.
>> >
>> > What does Emacs have to do to "restart" an input method? what does
>> > this mean in practice?
>> 
>> In practice, this means the input method will hide and reshow its
>> editing window.
>
> The editing window is shown by the input method, not by Emacs, right?
> I asked about what Emacs needs to do for this "restarting" action.
>
>> > And how much time is "a significant amount of time" in this case?
>> 
>> Up to a second.
>
> So the user types something and the response is after 1 sec?

Yes, if the editor makes an edit that the input method wasn't expecting,
you will see the input method window disappear and reappear again up to
a second later.  It works in practice because editors do not do that.

The period is apparently shorter if you turn off animations, but only
the user can do that in the system settings.

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

>> So, Emacs will have to implement (at least optional) translation
>> between these complex editing commands and simple character input
>> events.
>
> Yes, but AFAIU only to placate the electric-input features and
> similar.

Please see what I said above about toggling the input method behavior
depending on the major mode of the selected buffer.

>> > You mean, if I select, say, a Cyrillic keyboard and start typing, what
>> > Emacs will see is the above complex insert/delete/replace commands
>> > instead of a series of single Cyrillic characters?  And this only
>> > happens with non-ASCII characters, but not with ASCII?
>> 
>> Yes, that's what will happen right now.
>
> 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.