unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#62190: 30.0.50; analyze-text-conversion in Android
@ 2023-03-14 17:29 Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2023-03-15  0:47 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 4+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-03-14 17:29 UTC (permalink / raw)
  To: 62190; +Cc: Po Lu

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






^ permalink raw reply	[flat|nested] 4+ messages in thread

* bug#62190: 30.0.50; analyze-text-conversion in Android
  2023-03-14 17:29 bug#62190: 30.0.50; analyze-text-conversion in Android Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-03-15  0:47 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2023-03-15 17:52   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 4+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-03-15  0:47 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 62190

Stefan Monnier <monnier@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.





^ permalink raw reply	[flat|nested] 4+ messages in thread

* bug#62190: 30.0.50; analyze-text-conversion in Android
  2023-03-15  0:47 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-03-15 17:52   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2023-03-16  0:38     ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 4+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-03-15 17:52 UTC (permalink / raw)
  To: Po Lu; +Cc: 62190-done

> 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






^ permalink raw reply	[flat|nested] 4+ messages in thread

* bug#62190: 30.0.50; analyze-text-conversion in Android
  2023-03-15 17:52   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-03-16  0:38     ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 0 replies; 4+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-03-16  0:38 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 62190-done

Stefan Monnier <monnier@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.





^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2023-03-16  0:38 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-03-14 17:29 bug#62190: 30.0.50; analyze-text-conversion in Android Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-15  0:47 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-15 17:52   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-16  0:38     ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).