bug#65370: 30.0.50; Android: Single key input doesn’t work in some situations

bug#65370: 30.0.50; Android: Single key input doesn’t work in some situations

[Milan Zamazal]

In some cases, minibuffer prompts expecting a single key response don't
work.  I don't know whether it's actually Android specific but I've
observed it there.

I have two reproducible examples when this happens:

1. In Dired, when trying to copy a file (using `C' key) to another file
   that already exists, Dired asks for confirmation with the "yn!q"
   prompt.  It's possible to type multiple characters into the prompt,
   the typed characters appear there, but nothing else happens.  I have
   to use C-g to quit.  Instead, the prompt should react to the first
   typed character.

2. When running `M-x org-drill' on an org-drill file (org-drill is
   available from MELPA and
   https://gitlab.com/phillord/org-drill#demonstration describes an easy
   way to try it), one can normally type digits 1-5 to proceed with the
   cards.  Instead, the prompt doesn't react to keys at all and when I
   click to the primary buffer, the typed characters are inserted there.
   Both is wrong and doesn't happen in (non-Android) Emacs 29.1.


In GNU Emacs 30.0.50 (build 1, aarch64-unknown-linux-android21) of
 2023-08-18 built on xeon
Repository revision: 02d96e39b2182660e61e85b7b07da14ba6d94210
Windowing system distributor 'ONYX', version 29.0.0
System Description: ONYX/MaxLumi/MaxLumi:10/2023-04-20_12-34_3.3.2_856e3b0d6/10278:user/dev-keys

Configured using:
 'configure --with-png=yes --with-webp=yes --with-gif=yes
 --with-json=ifavailable --with-jpeg=yes --with-xml2=yes
 --with-sqlite3=yes --with-gnutls=yes --with-tiff=yes --with-selinux=yes
 --with-modules=yes --with-tree-sitter=yes --with-imagemagick=no
 --with-lcms2=yes --with-mailutils= --with-pop=no-by-default
 --with-harfbuzz=yes --enable-check-lisp-object-type= 'CFLAGS=-O2
 -Werror=implicit-function-declaration''

Configured features:
GIF GMP GNUTLS HARFBUZZ JPEG JSON LIBSELINUX LIBXML2 MODULES NOTIFY
INOTIFY PDUMPER PNG SECCOMP SQLITE3 TIFF TREE_SITTER WEBP ZLIB

Important settings:
  locale-coding-system: nil

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  buffer-read-only: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug oc-basic cl-extra help-mode ol-eww eww
url-queue thingatpt mm-url ol-rmail ol-mhe ol-irc ol-info ol-gnus
nnselect gnus-art mm-uu mml2015 mm-view mml-smime smime gnutls dig
gnus-sum shr pixel-fill kinsoku url-file svg dom browse-url url
url-proxy url-privacy url-expand url-methods url-history url-cookie
generate-lisp-file url-domsuf url-util url-parse auth-source json map
url-vars gnus-group gnus-undo gnus-start gnus-dbus dbus xml gnus-cloud
nnimap nnmail mail-source utf7 nnoo parse-time gnus-spec gnus-int
gnus-range message sendmail mailcap yank-media puny rfc822 mml mml-sec
password-cache epa epg rfc6068 epg-config mm-decode mm-bodies mm-encode
mail-parse rfc2231 rfc2047 rfc2045 ietf-drums mailabbrev gmm-utils
mailheader gnus-win gnus nnheader gnus-util text-property-search
mail-utils range mm-util mail-prsvr wid-edit ol-docview doc-view
filenotify jka-compr image-mode exif dired dired-loaddefs ol-bibtex
bibtex iso8601 ol-bbdb ol-w3m ol-doi org-link-doi org-drill pcase
derived persist org-agenda org-element cl-seq org-persist xdg org-id
avl-tree generator org-refile org ob ob-tangle ob-ref ob-lob ob-table
ob-exp org-macro org-src ob-comint org-pcomplete pcomplete comint
ansi-osc ansi-color ring org-list org-footnote org-faces org-entities
time-date subr-x noutline outline icons ob-emacs-lisp ob-core ob-eval
org-cycle org-table ol rx org-fold org-fold-core org-keys oc
org-loaddefs find-func cal-menu calendar cal-loaddefs org-version
org-compat org-macs format-spec eieio byte-opt bytecomp byte-compile
eieio-core cl-macs gv cl-loaddefs cl-lib rmc iso-transl tooltip
cus-start cconv eldoc paren electric uniquify ediff-hook vc-hooks
lisp-float-type elisp-mode mwheel android-win term/common-win ls-lisp
touch-screen tool-bar dnd fontset image regexp-opt fringe tabulated-list
replace newcomment text-mode lisp-mode prog-mode register page tab-bar
menu-bar rfn-eshadow isearch easymenu timer select scroll-bar mouse
jit-lock font-lock syntax font-core term/tty-colors frame minibuffer
nadvice seq simple cl-generic indonesian philippine cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite emoji-zwj charscript charprop
case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
inotify android multi-tty move-toolbar make-network-process emacs)

Memory information:
((conses 16 202772 22046) (symbols 48 20946 0) (strings 32 70867 3688)
 (string-bytes 1 2241513) (vectors 16 41047)
 (vector-slots 8 726122 24207) (floats 8 333 58) (intervals 56 524 0)
 (buffers 992 12))

bug#65370: 30.0.50; Android: Single key input doesn’t work in some situations

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Milan Zamazal <pdm@zamazal.org> writes:

> In some cases, minibuffer prompts expecting a single key response don't
> work.  I don't know whether it's actually Android specific but I've
> observed it there.
>
> I have two reproducible examples when this happens:
>
> 1. In Dired, when trying to copy a file (using `C' key) to another file
>    that already exists, Dired asks for confirmation with the "yn!q"
>    prompt.  It's possible to type multiple characters into the prompt,
>    the typed characters appear there, but nothing else happens.  I have
>    to use C-g to quit.  Instead, the prompt should react to the first
>    typed character.
>
> 2. When running `M-x org-drill' on an org-drill file (org-drill is
>    available from MELPA and
>    https://gitlab.com/phillord/org-drill#demonstration describes an easy
>    way to try it), one can normally type digits 1-5 to proceed with the
>    cards.  Instead, the prompt doesn't react to keys at all and when I
>    click to the primary buffer, the typed characters are inserted there.
>    Both is wrong and doesn't happen in (non-Android) Emacs 29.1.

Thanks, both of these issues should be fixed soon.  They're particular
to the Android port, more specifically its input method text conversion
features.

bug#65370: 30.0.50; Android: Single key input doesn’t work in some situations

[Stefan Kangas]

Po Lu <luangruo@yahoo.com> writes:

> Milan Zamazal <pdm@zamazal.org> writes:
>
>> In some cases, minibuffer prompts expecting a single key response don't
>> work.  I don't know whether it's actually Android specific but I've
>> observed it there.
>>
>> I have two reproducible examples when this happens:
>>
>> 1. In Dired, when trying to copy a file (using `C' key) to another file
>>    that already exists, Dired asks for confirmation with the "yn!q"
>>    prompt.  It's possible to type multiple characters into the prompt,
>>    the typed characters appear there, but nothing else happens.  I have
>>    to use C-g to quit.  Instead, the prompt should react to the first
>>    typed character.
>>
>> 2. When running `M-x org-drill' on an org-drill file (org-drill is
>>    available from MELPA and
>>    https://gitlab.com/phillord/org-drill#demonstration describes an easy
>>    way to try it), one can normally type digits 1-5 to proceed with the
>>    cards.  Instead, the prompt doesn't react to keys at all and when I
>>    click to the primary buffer, the typed characters are inserted there.
>>    Both is wrong and doesn't happen in (non-Android) Emacs 29.1.
>
> Thanks, both of these issues should be fixed soon.  They're particular
> to the Android port, more specifically its input method text conversion
> features.

Is there anything more to do here, or should this be closed?

bug#65370: 30.0.50; Android: Single key input doesn’t work in some situations

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Stefan Kangas <stefankangas@gmail.com> writes:

> Po Lu <luangruo@yahoo.com> writes:
>
>> Milan Zamazal <pdm@zamazal.org> writes:
>>
>>> In some cases, minibuffer prompts expecting a single key response don't
>>> work.  I don't know whether it's actually Android specific but I've
>>> observed it there.
>>>
>>> I have two reproducible examples when this happens:
>>>
>>> 1. In Dired, when trying to copy a file (using `C' key) to another file
>>>    that already exists, Dired asks for confirmation with the "yn!q"
>>>    prompt.  It's possible to type multiple characters into the prompt,
>>>    the typed characters appear there, but nothing else happens.  I have
>>>    to use C-g to quit.  Instead, the prompt should react to the first
>>>    typed character.
>>>
>>> 2. When running `M-x org-drill' on an org-drill file (org-drill is
>>>    available from MELPA and
>>>    https://gitlab.com/phillord/org-drill#demonstration describes an easy
>>>    way to try it), one can normally type digits 1-5 to proceed with the
>>>    cards.  Instead, the prompt doesn't react to keys at all and when I
>>>    click to the primary buffer, the typed characters are inserted there.
>>>    Both is wrong and doesn't happen in (non-Android) Emacs 29.1.
>>
>> Thanks, both of these issues should be fixed soon.  They're particular
>> to the Android port, more specifically its input method text conversion
>> features.
>
> Is there anything more to do here, or should this be closed?

Nothing other than waiting for a reply from Milan.

bug#65370: 30.0.50; Android: Single key input doesn’t work in some situations

[Stefan Kangas]

tags 65370 fixed
thanks

Po Lu <luangruo@yahoo.com> writes:

>> Is there anything more to do here, or should this be closed?
>
> Nothing other than waiting for a reply from Milan.

OK.  Milan, are you still seeing this problem?

bug#65370: 30.0.50; Android: Single key input doesn’t work in some situations

[Milan Zamazal]

>>>>> "SK" == Stefan Kangas <stefankangas@gmail.com> writes:

    SK> Milan, are you still seeing this problem?

The first problem is gone but this problem still exists:

> 2. When running `M-x org-drill' on an org-drill file (org-drill is
>    available from MELPA and
>    https://gitlab.com/phillord/org-drill#demonstration describes an easy
>    way to try it), one can normally type digits 1-5 to proceed with the
>    cards.  Instead, the prompt doesn't react to keys at all and when I
>    click to the primary buffer, the typed characters are inserted there.
>    Both is wrong and doesn't happen in (non-Android) Emacs 29.1.

bug#65370: 30.0.50; Android: Single key input doesn’t work in some situations

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Milan Zamazal <pdm@zamazal.org> writes:

>>>>>> "SK" == Stefan Kangas <stefankangas@gmail.com> writes:
>
>     SK> Milan, are you still seeing this problem?
>
> The first problem is gone but this problem still exists:
>
>> 2. When running `M-x org-drill' on an org-drill file (org-drill is
>>    available from MELPA and
>>    https://gitlab.com/phillord/org-drill#demonstration describes an easy
>>    way to try it), one can normally type digits 1-5 to proceed with the
>>    cards.  Instead, the prompt doesn't react to keys at all and when I
>>    click to the primary buffer, the typed characters are inserted there.
>>    Both is wrong and doesn't happen in (non-Android) Emacs 29.1.

Oh, thanks.  This is because Org Drill doesn't take measures to disable
text conversion (a mechanism whereby input methods insert text directly
within buffers) within Org buffers it manages, and consequently cannot
receive text typed from the keyboard as key events.

Phillip, would you please look into this?  As a rule of thumb,
disabling text conversion requires no more than:

  (setq-local text-conversion-style nil)