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

[GNU bug Tracking System]

Your message dated Wed, 15 Mar 2023 13:52:51 -0400
with message-id <jwv35653nxe.fsf-monnier+emacs@gnu.org>
and subject line Re: bug#62190: 30.0.50; analyze-text-conversion in Android
has caused the debbugs.gnu.org bug report #62190,
regarding 30.0.50; analyze-text-conversion in Android
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
62190: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62190
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
> --- Begin Message ---
>
>
>
> Subject: 
>
> 30.0.50; analyze-text-conversion in Android
>
>
>
>
> Date: 
>
> Tue, 14 Mar 2023 13:29:43 -0400
>
>
>
>
> Package: Emacs
> Version: 30.0.50
>
>
> I tried out the Emacs distributed on F-Droid, which is apparently built
> from our feature/android work, and I bumped into
> `analyze-text-conversion`.  Currently, this breaks things like `ESC x`
> (I don't have Meta/Alt on my keyboard) or `C-h l` because the second
> event I get is not a letter (like `x` or `l`) but the event
> `text-conversion`.  I guess this may depend on the keyboard, admittedly.
>
> IIUC this is tied to the feature whereby you can "build" a word from the
> keyboard before sending it "for real" to Emacs, but you get to see this
> word in your buffer before it's "committed"?
>
> 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).
>
>
>         Stefan
>
>
>
>
> --- End Message ---
> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: bug#62190: 30.0.50; analyze-text-conversion in Android
>
>
>
>
> Date: 
>
> Wed, 15 Mar 2023 13:52:51 -0400
>
>
>
>
> User-agent: 
>
> Gnus/5.13 (Gnus v5.13)
>
>
>
>
> > 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
>
>
>
> --- End Message ---