GNU bug report logs - #62190
30.0.50; analyze-text-conversion in Android

Previous Next

Full log

Message #13 received at 62190-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 62190-done <at> debbugs.gnu.org
Subject: Re: bug#62190: 30.0.50; analyze-text-conversion in Android
Date: Wed, 15 Mar 2023 13:52:51 -0400

> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.