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

[Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

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


        Stefan