GNU bug report logs -
#34517
tmm menubar menu items have no effect on Android
Previous Next
Reported by: Juri Linkov <juri <at> linkov.net>
Date: Sun, 17 Feb 2019 21:10:03 UTC
Severity: normal
Found in version 26.1
Fixed in version 27.0.50
Done: Juri Linkov <juri <at> linkov.net>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 34517 in the body.
You can then email your comments to 34517 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#34517
; Package
emacs
.
(Sun, 17 Feb 2019 21:10:03 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Juri Linkov <juri <at> linkov.net>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Sun, 17 Feb 2019 21:10:03 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Touching the top menu items like “File” opens a file submenu nicely
in tmm's *Completions* buffer.
But touching menu items in its submenu like “New Window on Right”
does nothing.
In GNU Emacs 26.1 (build 1, aarch64-unknown-linux-android)
of 2019-02-17 built on localhost
Recent messages:
Loading uniquify...done
Loading electric...done
Loading emacs-lisp/eldoc...done
Loading cus-start...done
Loading tooltip...done
Loading /data/data/com.termux/files/usr/share/emacs/26.1/lisp/leim/leim-list.el (source)...done
Finding pointers to doc strings...done
Loading /data/data/com.termux/files/usr/share/emacs/26.1/lisp/emacs-lisp/site-init.el (source)...done
For information about GNU Emacs and the GNU system, type C-h C-a.
Loading loadup.el (source)...done
Making completion list... [2 times]
Configured using:
'configure --disable-dependency-tracking
--prefix=/data/data/com.termux/files/usr
--libdir=/data/data/com.termux/files/usr/lib --disable-rpath
--disable-rpath-hack --host=aarch64-linux-android --disable-autodepend
--with-gif=no --with-gnutls --with-jpeg=no --without-gconf
--without-gsettings --without-lcms2 --without-x --with-png=no
--with-tiff=no --with-xml2 --with-xpm=no emacs_cv_sanitize_address=yes
emacs_cv_prog_cc_no_pie=no ac_cv_lib_elf_elf_begin=no
gl_cv_func_dup2_works=no ac_cv_func_setrlimit=no --disable-nls
--enable-shared --disable-static
--libexecdir=/data/data/com.termux/files/usr/libexec 'CFLAGS= -Oz'
CPPFLAGS=-I/data/data/com.termux/files/usr/include
LDFLAGS=-L/data/data/com.termux/files/usr/lib'
Configured features:
NOTIFY GNUTLS LIBXML2 ZLIB THREADS CANNOT_DUMP
Important settings:
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
Major mode: Fundamental
Minor modes in effect:
xterm-mouse-mode: t
tooltip-mode: t
global-eldoc-mode: t
electric-indent-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
buffer-read-only: t
line-number-mode: t
transient-mark-mode: t
Load-path shadows:
None found.
Features:
(shadow sort mail-extr emacsbug message rmc puny seq byte-opt gv
bytecomp byte-compile cconv cl-loaddefs cl-lib dired dired-loaddefs
format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg
epg-config gnus-util rmail tool-bar rmail-loaddefs mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
regexp-opt rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
term/xterm xterm time-date elec-pair mule-util xt-mouse tooltip
cus-start eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow isearch timer select mouse
jit-lock font-lock syntax facemenu font-core term/tty-colors frame
cl-generic 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
charscript charprop case-table epa-hook jka-cmpr-hook help simple abbrev
obarray minibuffer cl-preloaded nadvice loaddefs button faces cus-face
macroexp files text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget hashtable-print-readable backquote inotify
multi-tty make-network-process emacs)
Memory information:
((conses 16 150707 11135)
(symbols 48 19406 1)
(miscs 40 60 96)
(strings 32 51526 1360)
(string-bytes 1 2200213)
(vectors 16 24842)
(vector-slots 8 1078498 126892)
(floats 8 183 263)
(intervals 56 233 0)
(buffers 992 12))
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#34517
; Package
emacs
.
(Mon, 18 Feb 2019 21:24:03 GMT)
Full text and
rfc822 format available.
Message #8 received at 34517 <at> debbugs.gnu.org (full text, mbox):
> Touching the top menu items like “File” opens a file submenu nicely
> in tmm's *Completions* buffer.
>
> But touching menu items in its submenu like “New Window on Right”
> does nothing.
I can reproduce this in the latest version 27 on GNU/Linux:
clicking with the mouse on menu items from M-` (tmm-menubar)
has the same effect, i.e. no effect.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#34517
; Package
emacs
.
(Tue, 19 Feb 2019 03:34:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 34517 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Date: Mon, 18 Feb 2019 23:22:03 +0200
>
> > Touching the top menu items like “File” opens a file submenu nicely
> > in tmm's *Completions* buffer.
> >
> > But touching menu items in its submenu like “New Window on Right”
> > does nothing.
>
> I can reproduce this in the latest version 27 on GNU/Linux:
> clicking with the mouse on menu items from M-` (tmm-menubar)
> has the same effect, i.e. no effect.
tmm-menubar is supposed to be for when there's no mouse at all, so why
do we expect a mouse click to do anything in that case?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#34517
; Package
emacs
.
(Tue, 19 Feb 2019 22:02:03 GMT)
Full text and
rfc822 format available.
Message #14 received at 34517 <at> debbugs.gnu.org (full text, mbox):
>> > Touching the top menu items like “File” opens a file submenu nicely
>> > in tmm's *Completions* buffer.
>> >
>> > But touching menu items in its submenu like “New Window on Right”
>> > does nothing.
>>
>> I can reproduce this in the latest version 27 on GNU/Linux:
>> clicking with the mouse on menu items from M-` (tmm-menubar)
>> has the same effect, i.e. no effect.
>
> tmm-menubar is supposed to be for when there's no mouse at all, so why
> do we expect a mouse click to do anything in that case?
Smartphones translate screen touch events to click event, so this is
the only way to use menus. Also the help text of tmm menus says:
"Click on a completion to select it."
But now I see that tmm relies on completing-read-default
and inserts initial input that gets concatenated with
an item selected by clicking in the *Completions* buffer.
When initial input is deleted manually with e.g. <backspace>
before clicking on a menu item, then tmm works correctly.
So the bug is in completing-read-default and can be reproduced
with a simpler test case:
0. emacs -Q
1. ‘C-h f TAB’ displays a list of completions
2. type a nonexistent function name, i.e. some random text
in the minibuffer, e.g. “blabla”
3. click on an existing valid completion in the *Completions* buffer,
e.g. on “append”
4. instead of getting the selected item “append”, it fails with:
user-error: Symbol’s function definition is void: appendblabla
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#34517
; Package
emacs
.
(Wed, 27 Feb 2019 21:05:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 34517 <at> debbugs.gnu.org (full text, mbox):
Stefan, please advise shouldn't selecting a completion from the
*Completions* buffer clear the minibuffer's content before
inserting the selected completion?
>>> > Touching the top menu items like “File” opens a file submenu nicely
>>> > in tmm's *Completions* buffer.
>>> >
>>> > But touching menu items in its submenu like “New Window on Right”
>>> > does nothing.
>>>
>>> I can reproduce this in the latest version 27 on GNU/Linux:
>>> clicking with the mouse on menu items from M-` (tmm-menubar)
>>> has the same effect, i.e. no effect.
>>
>> tmm-menubar is supposed to be for when there's no mouse at all, so why
>> do we expect a mouse click to do anything in that case?
>
> Smartphones translate screen touch events to click event, so this is
> the only way to use menus. Also the help text of tmm menus says:
>
> "Click on a completion to select it."
>
> But now I see that tmm relies on completing-read-default
> and inserts initial input that gets concatenated with
> an item selected by clicking in the *Completions* buffer.
>
> When initial input is deleted manually with e.g. <backspace>
> before clicking on a menu item, then tmm works correctly.
>
> So the bug is in completing-read-default and can be reproduced
> with a simpler test case:
>
> 0. emacs -Q
>
> 1. ‘C-h f TAB’ displays a list of completions
>
> 2. type a nonexistent function name, i.e. some random text
> in the minibuffer, e.g. “blabla”
>
> 3. click on an existing valid completion in the *Completions* buffer,
> e.g. on “append”
>
> 4. instead of getting the selected item “append”, it fails with:
>
> user-error: Symbol’s function definition is void: appendblabla
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#34517
; Package
emacs
.
(Wed, 27 Feb 2019 22:11:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 34517 <at> debbugs.gnu.org (full text, mbox):
> Stefan, please advise shouldn't selecting a completion from the
> *Completions* buffer clear the minibuffer's content before
> inserting the selected completion?
No, for example when you complete file name "C-x C-f ~/.e TAB" the
*Completions* buffer will only show ".emacs" so we should clear the
minibuffer before inserting ".emacs" because that would lose the leading
"~/". There are other circumstances where trailing text needs to
be preserved.
The completion code handles this with `completion-base-position` which
holds the beginning and end of the text that should be replaced when you
choose an item in *Completions*.
>> 0. emacs -Q
>> 1. ‘C-h f TAB’ displays a list of completions
>> 2. type a nonexistent function name, i.e. some random text
>> in the minibuffer, e.g. “blabla”
The *Completions* content is now "out of date" compared to the minibuffer.
>> 3. click on an existing valid completion in the *Completions* buffer,
>> e.g. on “append”
completion-base-position was set at step (1) to cover the empty text
after the prompt, so this empty text (which is now right in front of
"blabla") is replaced with "append" resulting in "appendblabla".
Obviously, the result is not what we want.
Now sure how to change which part, tho. Maybe instead of
completion-base-position we should store the prefix and suffix strings,
so when you select an entry from *Completions* we just clear the
minibuffer and replace it with (concat prefix selection suffix)?
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#34517
; Package
emacs
.
(Thu, 28 Feb 2019 21:14:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 34517 <at> debbugs.gnu.org (full text, mbox):
> Maybe instead of completion-base-position we should store the prefix
> and suffix strings, so when you select an entry from *Completions* we
> just clear the minibuffer and replace it with (concat prefix selection
> suffix)?
The prefix and suffix strings might help. Not sure whether the
following idea will also work, but maybe using markers in the minibuffer
to keep positions of completion base would help. Inserting text to the
minibuffer will update these markers that could be used to find
completion base in choose-completion.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#34517
; Package
emacs
.
(Sun, 08 Sep 2019 20:31:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 34517 <at> debbugs.gnu.org (full text, mbox):
found 34517 26.1
fixed 34517 27.0.50
quit
> Touching the top menu items like “File” opens a file submenu nicely
> in tmm's *Completions* buffer.
>
> But touching menu items in its submenu like “New Window on Right”
> does nothing.
I noticed that mouse clicks fail even with xterm-mouse-mode,
so looked again at the problem and fixed it in master by
avoiding inserting initial value to the minibuffer.
Also moved the list of pre-populated menu items to the
list of default values for M-n. And due to the tradition
of reversing completions in tmm-km-list every release,
reversed it once more.
bug Marked as found in versions 26.1.
Request was from
Juri Linkov <juri <at> linkov.net>
to
control <at> debbugs.gnu.org
.
(Sun, 08 Sep 2019 20:31:02 GMT)
Full text and
rfc822 format available.
bug Marked as fixed in versions 27.0.50.
Request was from
Juri Linkov <juri <at> linkov.net>
to
control <at> debbugs.gnu.org
.
(Sun, 08 Sep 2019 20:31:02 GMT)
Full text and
rfc822 format available.
bug marked as fixed in version 27.0.50, send any further explanations to
34517 <at> debbugs.gnu.org and Juri Linkov <juri <at> linkov.net>
Request was from
Juri Linkov <juri <at> linkov.net>
to
control <at> debbugs.gnu.org
.
(Sun, 08 Sep 2019 20:35:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Mon, 07 Oct 2019 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 5 years and 33 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.