GNU bug report logs -
#52809
28.0.90; X11 modeline context menu grows offscreen unreadable on smaller screen of two screen display
Previous Next
Reported by: Van Ly <van.ly <at> sdf.org>
Date: Sun, 26 Dec 2021 17:42:02 UTC
Severity: normal
Found in version 28.0.90
Done: Po Lu <luangruo <at> yahoo.com>
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 52809 in the body.
You can then email your comments to 52809 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#52809; Package
emacs.
(Sun, 26 Dec 2021 17:42:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Van Ly <van.ly <at> sdf.org>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Sun, 26 Dec 2021 17:42:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hello,
On the modeline, on the "Major mode" keyword, for example
"Fundamental", mouse button 1 and 3 cause a context menu to show
overlapping the modeline.
On a two screen display of uneven size, on the smaller of those two
screens, when the X11 frame for emacs is maximised fullscreen after
using the F11 key for toggle-frame-fullscreen, that context menu
grows offscreen and unreadable.
Similary, on the smaller screen, an X11 frame for emacs with the
bottom of the frame put near to the bottom of the smaller screen,
that context menu grows offscreen and unreadable.
# steps to reproduce
## maximised X11 frame for emacs on smaller of two screens
1. start emacs by "emacs -Q"
2. move the emacs X11 frame to the smaller screen of a two screen
GNU/Linux LXDE
3. press F11 for toggle-frame-fullscreen
4. press button mouse-1 or mouse-3 on the "Major mode" keyword for
context menu
## not maximised X11 frame for emacs on smaller of two screens
1. start emacs by "emacs -Q"
2. move the emacs X11 frame to the smaller screen of a two screen
GNU/Linux LXDE
3. move the bottom of emacs X11 frame to bottom of the screen
4. press button mouse-1 or mouse-3 on the "Major mode" keyword for
context menu
# observed behavior
The context menu grows offscreen and unreadable.
# expected behavior
The context menu "floats" as it grows, showing all the rows on the
context menu.
--
vl
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52809; Package
emacs.
(Mon, 27 Dec 2021 06:31:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 52809 <at> debbugs.gnu.org (full text, mbox):
Van Ly <van.ly <at> sdf.org> writes:
> The context menu grows offscreen and unreadable.
>
> # expected behavior
> The context menu "floats" as it grows, showing all the rows on the
> context menu.
What toolkit is your Emacs built with? Is it GTK+? And if so, what
version of GTK+ is it?
In the future, please use report-emacs-bug to report this kind of bug.
It avoids having to ask these questions.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52809; Package
emacs.
(Mon, 27 Dec 2021 10:26:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 52809 <at> debbugs.gnu.org (full text, mbox):
On Mon, 27 Dec 2021, Po Lu wrote:
To be clear, the primary larger screen where the taskbar/app-launcher
is pinned behaves as expected for emac's modeline context menu. The
problem is on the smaller secondary screen.
>> The context menu grows offscreen and unreadable.
>>
>> # expected behavior
>> The context menu "floats" as it grows, showing all the rows on the
>> context menu.
>
> What toolkit is your Emacs built with? Is it GTK+? And if so, what
> version of GTK+ is it?
The x-toolkit is "lucid". Here is the clip from the config.log in
the build directory.
'''
$ /b/b/b/Blah/Projects/X/emacs/configure
--prefix=/b/b/b/Blah/Applications/emacs-2021-12-04
--with-x-toolkit=lucid --without-toolkit-scroll-bars --without-xft
--with-native-compilation --without-compress-install
'''
The GTK values are not set in config.log
'''
ac_cv_env_GTK_CFLAGS_set=
ac_cv_env_GTK_CFLAGS_value=
ac_cv_env_GTK_LIBS_set=
ac_cv_env_GTK_LIBS_value=
GTK_CFLAGS=''
GTK_LIBS=''
GTK_OBJ=''
'''
> In the future, please use report-emacs-bug to report this kind of bug.
> It avoids having to ask these questions.
I don't have emacs configured for email and worry the mechanism might
misfire. Sorry about that. I just discovered the config.log file is
1Mb long and decided not to include that in the attachment.
These are all the libraries associated with the emacs binary. I want
a skeleton thin build for my basic need but don't really know what to
exclude. Hope this helps.
'''
$ readelf -d b/b/Blah/bin/emacs | fgrep -n NEED
4: 0x0000000000000001 (NEEDED) Shared library:
[libtiff.so.5]
5: 0x0000000000000001 (NEEDED) Shared library:
[libjpeg.so.62]
6: 0x0000000000000001 (NEEDED) Shared library:
[libpng16.so.16]
7: 0x0000000000000001 (NEEDED) Shared library:
[libz.so.1]
8: 0x0000000000000001 (NEEDED) Shared library:
[libgif.so.7]
9: 0x0000000000000001 (NEEDED) Shared library:
[libXpm.so.4]
10: 0x0000000000000001 (NEEDED) Shared library:
[libXaw3d.so.6]
11: 0x0000000000000001 (NEEDED) Shared library:
[libXmu.so.6]
12: 0x0000000000000001 (NEEDED) Shared library:
[libXt.so.6]
13: 0x0000000000000001 (NEEDED) Shared library:
[libSM.so.6]
14: 0x0000000000000001 (NEEDED) Shared library:
[libICE.so.6]
15: 0x0000000000000001 (NEEDED) Shared library:
[libXext.so.6]
16: 0x0000000000000001 (NEEDED) Shared library:
[libX11.so.6]
17: 0x0000000000000001 (NEEDED) Shared library:
[libXrender.so.1]
18: 0x0000000000000001 (NEEDED) Shared library:
[libasound.so.2]
19: 0x0000000000000001 (NEEDED) Shared library:
[librsvg-2.so.2]
20: 0x0000000000000001 (NEEDED) Shared library:
[libm.so.6]
21: 0x0000000000000001 (NEEDED) Shared library:
[libgio-2.0.so.0]
22: 0x0000000000000001 (NEEDED) Shared library:
[libgdk_pixbuf-2.0.so.0]
23: 0x0000000000000001 (NEEDED) Shared library:
[libgobject-2.0.so.0]
24: 0x0000000000000001 (NEEDED) Shared library:
[libglib-2.0.so.0]
25: 0x0000000000000001 (NEEDED) Shared library:
[libcairo.so.2]
26: 0x0000000000000001 (NEEDED) Shared library:
[libacl.so.1]
27: 0x0000000000000001 (NEEDED) Shared library:
[librt.so.1]
28: 0x0000000000000001 (NEEDED) Shared library:
[libdbus-1.so.3]
29: 0x0000000000000001 (NEEDED) Shared library:
[libXrandr.so.2]
30: 0x0000000000000001 (NEEDED) Shared library:
[libXinerama.so.1]
31: 0x0000000000000001 (NEEDED) Shared library:
[libXfixes.so.3]
32: 0x0000000000000001 (NEEDED) Shared library:
[libxml2.so.2]
33: 0x0000000000000001 (NEEDED) Shared library:
[libgpm.so.2]
34: 0x0000000000000001 (NEEDED) Shared library:
[libtinfo.so.6]
35: 0x0000000000000001 (NEEDED) Shared library:
[libselinux.so.1]
36: 0x0000000000000001 (NEEDED) Shared library:
[libfreetype.so.6]
37: 0x0000000000000001 (NEEDED) Shared library:
[libfontconfig.so.1]
38: 0x0000000000000001 (NEEDED) Shared library:
[libharfbuzz.so.0]
39: 0x0000000000000001 (NEEDED) Shared library:
[libotf.so.0]
40: 0x0000000000000001 (NEEDED) Shared library:
[libm17n-core.so.0]
41: 0x0000000000000001 (NEEDED) Shared library:
[libm17n-flt.so.0]
42: 0x0000000000000001 (NEEDED) Shared library:
[libgnutls.so.30]
43: 0x0000000000000001 (NEEDED) Shared library:
[libpthread.so.0]
44: 0x0000000000000001 (NEEDED) Shared library:
[libanl.so.1]
45: 0x0000000000000001 (NEEDED) Shared library:
[liblcms2.so.2]
46: 0x0000000000000001 (NEEDED) Shared library:
[libdl.so.2]
47: 0x0000000000000001 (NEEDED) Shared library:
[libsystemd.so.0]
48: 0x0000000000000001 (NEEDED) Shared library:
[libgmp.so.10]
49: 0x0000000000000001 (NEEDED) Shared library:
[libgccjit.so.0]
50: 0x0000000000000001 (NEEDED) Shared library:
[libc.so.6]
71: 0x000000006ffffffe (VERNEED) 0xd730
72: 0x000000006fffffff (VERNEEDNUM) 18
'''
Thanks in advance.
--
vl
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52809; Package
emacs.
(Mon, 27 Dec 2021 14:46:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 52809 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 27 Dec 2021 10:25:22 +0000 (UTC)
> From: Van Ly <van.ly <at> sdf.org>
> Cc: 52809 <at> debbugs.gnu.org
>
> On Mon, 27 Dec 2021, Po Lu wrote:
>
> > In the future, please use report-emacs-bug to report this kind of bug.
> > It avoids having to ask these questions.
>
> I don't have emacs configured for email and worry the mechanism might
> misfire.
There's no need to be afraid of that. report-emacs-bug first prepares
a buffer with all the data, and then waits for you to invoke a command
to send that as email (after adding the specifics of the problem). So
you can just copy the information it prepares to your MUA and discard
the buffer afterwards.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52809; Package
emacs.
(Tue, 28 Dec 2021 00:43:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 52809 <at> debbugs.gnu.org (full text, mbox):
Van Ly <van.ly <at> sdf.org> writes:
> The x-toolkit is "lucid". Here is the clip from the config.log in the
> build directory.
Thanks, I will look into this.
> '''
> $ /b/b/b/Blah/Projects/X/emacs/configure
> --prefix=/b/b/b/Blah/Applications/emacs-2021-12-04
> --with-x-toolkit=lucid --without-toolkit-scroll-bars --without-xft
> --with-native-compilation --without-compress-install
> '''
>
> The GTK values are not set in config.log
>
> '''
> ac_cv_env_GTK_CFLAGS_set=
> ac_cv_env_GTK_CFLAGS_value=
> ac_cv_env_GTK_LIBS_set=
> ac_cv_env_GTK_LIBS_value=
> GTK_CFLAGS=''
> GTK_LIBS=''
> GTK_OBJ=''
> '''
I'm afraid using the contents of config.log to determine Emacs
configuration usually causes a great deal of trouble to both of us: you
really ought to use `report-emacs-bug'.
> I don't have emacs configured for email and worry the mechanism might
> misfire. Sorry about that. I just discovered the config.log file is
> 1Mb long and decided not to include that in the attachment.
You don't have to send it from Emacs, you can copy the report into your
favorite mailer and send it to bug-gnu-emacs <at> gnu.org.
> '''
> $ readelf -d b/b/Blah/bin/emacs | fgrep -n NEED
> 4: 0x0000000000000001 (NEEDED) Shared library:
> [libtiff.so.5]
> 5: 0x0000000000000001 (NEEDED) Shared library:
> [libjpeg.so.62]
> 6: 0x0000000000000001 (NEEDED) Shared library:
> [libpng16.so.16]
> 7: 0x0000000000000001 (NEEDED) Shared library: [libz.so.1]
> 8: 0x0000000000000001 (NEEDED) Shared library:
> [libgif.so.7]
> 9: 0x0000000000000001 (NEEDED) Shared library:
> [libXpm.so.4]
> 10: 0x0000000000000001 (NEEDED) Shared library:
> [libXaw3d.so.6]
> 11: 0x0000000000000001 (NEEDED) Shared library:
> [libXmu.so.6]
> 12: 0x0000000000000001 (NEEDED) Shared library:
> [libXt.so.6]
> 13: 0x0000000000000001 (NEEDED) Shared library:
> [libSM.so.6]
> 14: 0x0000000000000001 (NEEDED) Shared library:
> [libICE.so.6]
> 15: 0x0000000000000001 (NEEDED) Shared library:
> [libXext.so.6]
> 16: 0x0000000000000001 (NEEDED) Shared library:
> [libX11.so.6]
> 17: 0x0000000000000001 (NEEDED) Shared library:
> [libXrender.so.1]
> 18: 0x0000000000000001 (NEEDED) Shared library:
> [libasound.so.2]
> 19: 0x0000000000000001 (NEEDED) Shared library:
> [librsvg-2.so.2]
> 20: 0x0000000000000001 (NEEDED) Shared library:
> [libm.so.6]
> 21: 0x0000000000000001 (NEEDED) Shared library:
> [libgio-2.0.so.0]
> 22: 0x0000000000000001 (NEEDED) Shared library:
> [libgdk_pixbuf-2.0.so.0]
> 23: 0x0000000000000001 (NEEDED) Shared library:
> [libgobject-2.0.so.0]
> 24: 0x0000000000000001 (NEEDED) Shared library:
> [libglib-2.0.so.0]
> 25: 0x0000000000000001 (NEEDED) Shared library:
> [libcairo.so.2]
> 26: 0x0000000000000001 (NEEDED) Shared library:
> [libacl.so.1]
> 27: 0x0000000000000001 (NEEDED) Shared library:
> [librt.so.1]
> 28: 0x0000000000000001 (NEEDED) Shared library:
> [libdbus-1.so.3]
> 29: 0x0000000000000001 (NEEDED) Shared library:
> [libXrandr.so.2]
> 30: 0x0000000000000001 (NEEDED) Shared library:
> [libXinerama.so.1]
> 31: 0x0000000000000001 (NEEDED) Shared library:
> [libXfixes.so.3]
> 32: 0x0000000000000001 (NEEDED) Shared library:
> [libxml2.so.2]
> 33: 0x0000000000000001 (NEEDED) Shared library:
> [libgpm.so.2]
> 34: 0x0000000000000001 (NEEDED) Shared library:
> [libtinfo.so.6]
> 35: 0x0000000000000001 (NEEDED) Shared library:
> [libselinux.so.1]
> 36: 0x0000000000000001 (NEEDED) Shared library:
> [libfreetype.so.6]
> 37: 0x0000000000000001 (NEEDED) Shared library:
> [libfontconfig.so.1]
> 38: 0x0000000000000001 (NEEDED) Shared library:
> [libharfbuzz.so.0]
> 39: 0x0000000000000001 (NEEDED) Shared library:
> [libotf.so.0]
> 40: 0x0000000000000001 (NEEDED) Shared library:
> [libm17n-core.so.0]
> 41: 0x0000000000000001 (NEEDED) Shared library:
> [libm17n-flt.so.0]
> 42: 0x0000000000000001 (NEEDED) Shared library:
> [libgnutls.so.30]
> 43: 0x0000000000000001 (NEEDED) Shared library:
> [libpthread.so.0]
> 44: 0x0000000000000001 (NEEDED) Shared library:
> [libanl.so.1]
> 45: 0x0000000000000001 (NEEDED) Shared library:
> [liblcms2.so.2]
> 46: 0x0000000000000001 (NEEDED) Shared library:
> [libdl.so.2]
> 47: 0x0000000000000001 (NEEDED) Shared library:
> [libsystemd.so.0]
> 48: 0x0000000000000001 (NEEDED) Shared library:
> [libgmp.so.10]
> 49: 0x0000000000000001 (NEEDED) Shared library:
> [libgccjit.so.0]
> 50: 0x0000000000000001 (NEEDED) Shared library:
> [libc.so.6]
> 71: 0x000000006ffffffe (VERNEED) 0xd730
> 72: 0x000000006fffffff (VERNEEDNUM) 18
> '''
That rarely helpes as well, especially in this case, because the Lucid
toolkit is builtin to Emacs and not dynamically linked.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52809; Package
emacs.
(Tue, 28 Dec 2021 02:55:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 52809 <at> debbugs.gnu.org (full text, mbox):
Po Lu <luangruo <at> yahoo.com> writes:
> Thanks, I will look into this.
It should be fixed on master now, please test.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52809; Package
emacs.
(Tue, 28 Dec 2021 10:54:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 52809 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> Po Lu <luangruo <at> yahoo.com> writes:
>
> It should be fixed on master now, please test.
The bug is gone. The full context menu displays within bounds on all
screens of the display. Attached is the bug-gnu-emacs report on host
characteristics building off master.
The ELC+ELN stage of the build doesn't make use of multicores. If it
could detect there are 4 cores and do something like 'make -j4' that
would be an improvement on time to build completion.
--
vl
[bug-gnu-emacs.text (text/plain, attachment)]
Reply sent
to
Po Lu <luangruo <at> yahoo.com>:
You have taken responsibility.
(Tue, 28 Dec 2021 10:56:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Van Ly <van.ly <at> sdf.org>:
bug acknowledged by developer.
(Tue, 28 Dec 2021 10:56:02 GMT)
Full text and
rfc822 format available.
Message #28 received at 52809-done <at> debbugs.gnu.org (full text, mbox):
Van Ly <van.ly <at> sdf.org> writes:
> The bug is gone. The full context menu displays within bounds on all
> screens of the display. Attached is the bug-gnu-emacs report on host
> characteristics building off master.
Great, I'm closing this bug report.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52809; Package
emacs.
(Tue, 28 Dec 2021 13:10:01 GMT)
Full text and
rfc822 format available.
Message #31 received at 52809 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 28 Dec 2021 10:53:22 +0000 (UTC)
> From: Van Ly <van.ly <at> sdf.org>
> Cc: 52809 <at> debbugs.gnu.org
>
> The ELC+ELN stage of the build doesn't make use of multicores. If it
> could detect there are 4 cores and do something like 'make -j4' that
> would be an improvement on time to build completion.
You mean, during building Emacs? If you say "make -j4", there will be
4 ELC+ELN compilations running in parallel. So I'm not sure I
understand the complaint.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52809; Package
emacs.
(Tue, 28 Dec 2021 14:14:01 GMT)
Full text and
rfc822 format available.
Message #34 received at 52809 <at> debbugs.gnu.org (full text, mbox):
On Tue, 28 Dec 2021, Eli Zaretskii wrote:
>> Date: Tue, 28 Dec 2021 10:53:22 +0000 (UTC)
>> From: Van Ly <van.ly <at> sdf.org>
>> Cc: 52809 <at> debbugs.gnu.org
>>
>> The ELC+ELN stage of the build doesn't make use of multicores. If it
>> could detect there are 4 cores and do something like 'make -j4' that
>> would be an improvement on time to build completion.
>
> You mean, during building Emacs? If you say "make -j4", there will be
> 4 ELC+ELN compilations running in parallel. So I'm not sure I
> understand the complaint.
>
Yes, during the Emacs build. I haven't experimented to see if "make
-j4" will allow 4 parallel lanes of ELC+ELN compilations. That would
be nice. I'm saying "make bootstrap" detects there are multiple
cores and suggests or defaults to using them all in parallel whee
possible.
--
vl
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52809; Package
emacs.
(Tue, 28 Dec 2021 14:18:02 GMT)
Full text and
rfc822 format available.
Message #37 received at 52809 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 28 Dec 2021 14:13:01 +0000 (UTC)
> From: Van Ly <van.ly <at> sdf.org>
> cc: luangruo <at> yahoo.com, 52809 <at> debbugs.gnu.org
>
> Yes, during the Emacs build. I haven't experimented to see if "make
> -j4" will allow 4 parallel lanes of ELC+ELN compilations. That would
> be nice.
Then please do use "make -jN bootstrap", where N is the number of
execution units you have on that system. That's how you request
parallel Emacs builds.
> I'm saying "make bootstrap" detects there are multiple cores and
> suggests or defaults to using them all in parallel whee possible.
The way we natively-compile Lisp files during a build was
intentionally made serial, so that the Make command could control how
much parallelism is in use. Because otherwise, we could easily
overwhelm the CPU, because the inherent built-in parallelism of the
async native-compilation doesn't care about the system load, so
invoking "make -j8" would give you 8 compilation jobs, each one of
which could use 4 cores.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52809; Package
emacs.
(Tue, 28 Dec 2021 16:01:01 GMT)
Full text and
rfc822 format available.
Message #40 received at 52809 <at> debbugs.gnu.org (full text, mbox):
On Tue, 28 Dec 2021, Eli Zaretskii wrote:
> Then please do use "make -jN bootstrap", where N is the number of
> execution units you have on that system. That's how you request
> parallel Emacs builds.
Thanks, I will do that the next time.
>> I'm saying "make bootstrap" detects there are multiple cores and
>> suggests or defaults to using them all in parallel whee possible.
>
> The way we natively-compile Lisp files during a build was
> intentionally made serial, so that the Make command could control how
> much parallelism is in use. Because otherwise, we could easily
> overwhelm the CPU, because the inherent built-in parallelism of the
> async native-compilation doesn't care about the system load, so
> invoking "make -j8" would give you 8 compilation jobs, each one of
> which could use 4 cores.
>
Thank you for taking the time to explain this. I was seeing one of
the CPU bars 100% and the three other ones idle.
--
vl
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Wed, 26 Jan 2022 12:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 140 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.