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

Previous Next

Package: emacs;

Reported by: Stefan Monnier <monnier <at> iro.umontreal.ca>

Date: Tue, 14 Mar 2023 17:30:02 UTC

Severity: normal

Found in version 30.0.50

Done: Stefan Monnier <monnier <at> iro.umontreal.ca>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Po Lu <luangruo <at> yahoo.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 62190-done <at> debbugs.gnu.org
Subject: bug#62190: 30.0.50; analyze-text-conversion in Android
Date: Thu, 16 Mar 2023 08:38:38 +0800
Stefan Monnier <monnier <at> 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.




This bug report was last modified 2 years and 66 days ago.

Previous Next


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