GNU bug report logs -
#62190
30.0.50; analyze-text-conversion in Android
Previous Next
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
[Message part 1 (text/plain, inline)]
Your bug report
#62190: 30.0.50; analyze-text-conversion in Android
which was filed against the emacs package, has been closed.
The explanation is attached below, along with your original report.
If you require more details, please reply to 62190 <at> debbugs.gnu.org.
--
62190: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62190
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
> 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
[Message part 3 (message/rfc822, inline)]
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
This bug report was last modified 2 years and 125 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.