bug#62190: 30.0.50; analyze-text-conversion in Android

[Po Lu]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Stefan, this was already fixed on the feature/android months ago, by
>> disabling text conversion in the middle of `read-key-sequence'.
>
> Sorry, I didn't realize it was so old.
>
>> I suggest you use (more) up-to-date prebuilts at:
>>
>>   https://sourceforge.net/projects/android-ports-for-gnu-emacs/upload/
>
> Will take a look at it, thanks.
>
>>> Maybe `text-conversion` should not be generated when we're "in the
>>> middle" of `read-key-sequence`?  Or maybe `text-conversion` should be
>>> turned into a sequence of "normal" events via `input-decode-map`?
>>> Or maybe more of the event processing should be done in ELisp and less
>>> in C (i.e. the raw events would be exposed to ELisp and they'd be
>>> processed a bit more like we do with our input-methods)?
>>>
>>> I'm not very knowledgeable about this topic (under Android I use my
>>> on-screen keyboards as if they were normal keyboards, very rarely even
>>> making use of the predictive features).
>>
>> Moving it to Lisp is unfortunately not possible, as Android input
>> methods require 150% obedience from Emacs that can only be accomplished
>> by hard wiring the logic in C.
>
> So maybe our best hope is to use `input-decode-map`?
>
> Some aspects might seem tricky (e.g. the fact that it could affect
> several buffers), but OTOH `input-decode-map` should simplify some of
> the code by removing the ad-hoc handling of electric-pair and auto-fill.

Unfortunately not, because the effect of an input method edit is already
performed prior to a `text-conversion' event being sent.  The edit may
also have been made to multiple frames, simultaneously.

I suggest looking at the code in textconv.c, the functions which are
decorated with `JNIEXPORT' in androidterm.c, and
java/org/gnu/emacs/EmacsInputConnection.java.  Thanks.