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


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

From: Po Lu <luangruo <at> yahoo.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 62190 <at> debbugs.gnu.org
Subject: Re: bug#62190: 30.0.50; analyze-text-conversion in Android
Date: Wed, 15 Mar 2023 08:47:16 +0800
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

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

Stefan, this was already fixed on the feature/android months ago, by
disabling text conversion in the middle of `read-key-sequence'.  I
suggest you use (more) up-to-date prebuilts at:

  https://sourceforge.net/projects/android-ports-for-gnu-emacs/upload/

> 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"?

This is up to the input method, Emacs knows nothing about the input
method policy, only that it should perform edits and apply faces to the
buffer as instructed.

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




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

Previous Next


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