From: "J. Scott Berg" <jsberg-bnl@outlook.com>
Cc: "44002@debbugs.gnu.org" <44002@debbugs.gnu.org>
Subject: bug#44002: 27.1; Small window height with VcXsrv X server when built with gtk3 toolkit
Date: Fri, 16 Oct 2020 14:47:46 +0000 [thread overview]
Message-ID: <MN2PR12MB4606951D68960E1D3AA9DDEC9A030@MN2PR12MB4606.namprd12.prod.outlook.com> (raw)
In-Reply-To: <83d01iwrsa.fsf@gnu.org>
I don't believe there are any gtk settings that would apply; I can make this happen on a very minimal Arch install without any desktop environment, as well as more complete installs of Arch and a RHEL7 clone with KDE/GNOME desktops installed.
Below I've shown the a the adjust_fram_size breaks. Just before the call with new_width=1280, new_height=1, a full window with the correct size, a menu bar, and otherwise a white background is visible. After that call, the window retains the same size, but below the menu there is a single text line (white) buffer, the status line, and a single text line (white) minibuffer; the remainder of the window below that is black. I showed the backtrace for that call. After the subsequent call, the window size jumps to approximately 5 text lines, keeping the same buffer/status/minibuffer as before, and the last two-ish text lines are black. After the subsequent call, I have an ordinary-looking emacs window except for the fact that the main buffer is only 3 lines long.
Thread 1 "emacs" hit Breakpoint 1, adjust_frame_size (f=0x555555c35e50, new_width=10, new_height=9, inhibit=5, pretend=false,
parameter=0x3c60) at frame.c:597
597 {
(gdb) c
Continuing.
Thread 1 "emacs" hit Breakpoint 1, adjust_frame_size (f=f@entry=0x555556034200, new_width=160, new_height=340,
inhibit=inhibit@entry=5, pretend=pretend@entry=true, parameter=parameter@entry=0xee50) at frame.c:597
597 {
(gdb) c
Continuing.
Thread 1 "emacs" hit Breakpoint 1, adjust_frame_size (f=f@entry=0x555556034200, new_width=new_width@entry=-1,
new_height=new_height@entry=-1, inhibit=1, pretend=pretend@entry=false, parameter=parameter@entry=0xcde0) at frame.c:597
597 {
(gdb) c
Continuing.
Thread 1 "emacs" hit Breakpoint 1, adjust_frame_size (f=0x555556034200, new_width=-1, new_height=-1, inhibit=3, pretend=false,
parameter=0xbf40) at frame.c:597
597 {
(gdb) c
Continuing.
Thread 1 "emacs" hit Breakpoint 1, adjust_frame_size (f=0x555556034200, new_width=-1, new_height=-1, inhibit=3, pretend=false,
parameter=0xbee0) at frame.c:597
597 {
(gdb)
Continuing.
Thread 1 "emacs" hit Breakpoint 1, adjust_frame_size (f=f@entry=0x555556034200, new_width=new_width@entry=-1,
new_height=new_height@entry=-1, inhibit=inhibit@entry=2, pretend=pretend@entry=false, parameter=parameter@entry=0x96c0)
at frame.c:597
597 {
(gdb)
Continuing.
Thread 1 "emacs" hit Breakpoint 1, adjust_frame_size (f=f@entry=0x555556034200, new_width=1280, new_height=1224,
inhibit=inhibit@entry=0, pretend=pretend@entry=true, parameter=parameter@entry=0xee80) at frame.c:597
597 {
(gdb)
Continuing.
Thread 1 "emacs" hit Breakpoint 1, adjust_frame_size (f=f@entry=0x555556034200, new_width=new_width@entry=1280,
new_height=new_height@entry=1224, inhibit=inhibit@entry=5, pretend=pretend@entry=false, parameter=parameter@entry=0xf270)
at frame.c:597
597 {
(gdb)
Continuing.
Thread 1 "emacs" hit Breakpoint 1, adjust_frame_size (f=0x555556034200, new_width=1280, new_height=1, inhibit=5, pretend=false,
parameter=0x3c60) at frame.c:597
597 {
(gdb) where
#0 adjust_frame_size (f=0x555556034200, new_width=1280, new_height=1, inhibit=5, pretend=false, parameter=0x3c60) at frame.c:597
#1 0x00005555555a9fe3 in change_frame_size_1
(pixelwise=<optimized out>, safe=false, delay=false, pretend=false, new_height=<optimized out>, new_width=<optimized out>, f=<optimized out>) at lisp.h:1033
#2 change_frame_size
(pixelwise=<optimized out>, safe=false, delay=false, pretend=false, new_height=<optimized out>, new_width=<optimized out>, f=<optimized out>) at dispnew.c:5830
#3 do_pending_window_change (safe=safe@entry=false) at dispnew.c:5756
#4 0x00005555555e275f in message3_nolog (m=<optimized out>) at xdisp.c:11019
#5 0x00005555555e29e8 in message3 (m=m@entry=0x555555ff32a4) at xdisp.c:10950
#6 0x00005555556f3d90 in Fmessage (args=0x7fffffffccb0, nargs=<optimized out>) at editfns.c:2891
#7 Fmessage (nargs=<optimized out>, args=0x7fffffffccb0) at editfns.c:2859
#8 0x00005555556fcb6b in Ffuncall (nargs=3, args=args@entry=0x7fffffffcca8) at lisp.h:2110
#9 0x00005555557350c8 in exec_byte_code
(bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at bytecode.c:633
#10 0x00005555556fcaa7 in Ffuncall (nargs=1, args=args@entry=0x7fffffffd020) at eval.c:2809
#11 0x00005555557350c8 in exec_byte_code
(bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at bytecode.c:633
#12 0x00005555556fcaa7 in Ffuncall (nargs=2, args=args@entry=0x7fffffffd828) at eval.c:2809
#13 0x00005555557350c8 in exec_byte_code
(bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at bytecode.c:633
#14 0x00005555556fcaa7 in Ffuncall (nargs=1, args=args@entry=0x7fffffffe1e0) at eval.c:2809
#15 0x00005555557350c8 in exec_byte_code
(bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at bytecode.c:633
#16 0x00005555556ffd3d in apply_lambda (fun=0x7ffff285eb25, args=<optimized out>, count=4) at eval.c:2927
#17 0x00005555556fedd6 in eval_sub (form=<optimized out>) at eval.c:2349
#18 0x00005555557008d9 in Feval (form=0x7ffff29bb68b, lexical=<optimized out>) at eval.c:2103
#19 0x00005555556fbcd7 in internal_condition_case
(bfun=bfun@entry=0x555555680ac0 <top_level_2>, handlers=handlers@entry=0x90, hfun=hfun@entry=0x555555686300 <cmd_error>)
at eval.c:1356
#20 0x00005555556819a6 in top_level_1 (ignore=ignore@entry=0x0) at lisp.h:1033
#21 0x00005555556fbc31 in internal_catch (tag=tag@entry=0xd500, func=func@entry=0x555555681980 <top_level_1>, arg=arg@entry=0x0)
at eval.c:1117
#22 0x0000555555680a48 in command_loop () at lisp.h:1033
#23 0x0000555555685f16 in recursive_edit_1 () at keyboard.c:714
#24 0x0000555555686242 in Frecursive_edit () at keyboard.c:786
#25 0x00005555555a00f7 in main (argc=2, argv=<optimized out>) at emacs.c:2062
(gdb) c
Continuing.
Thread 1 "emacs" hit Breakpoint 1, adjust_frame_size (f=f@entry=0x555556034200, new_width=new_width@entry=-1,
new_height=new_height@entry=-1, inhibit=inhibit@entry=2, pretend=pretend@entry=false, parameter=parameter@entry=0xd350)
at frame.c:597
597 {
(gdb) c
Continuing.
Thread 1 "emacs" hit Breakpoint 1, adjust_frame_size (f=0x555556034200, new_width=1280, new_height=170, inhibit=5, pretend=false,
parameter=0x3c60) at frame.c:597
597 {
(gdb) c
Continuing.
> -----Original Message-----
> From: Eli Zaretskii <eliz@gnu.org>
> Sent: Friday, October 16, 2020 3:32 AM
> To: J. Scott Berg <jsberg-bnl@outlook.com>
> Cc: 44002@debbugs.gnu.org
> Subject: Re: bug#44002: 27.1; Small window height with VcXsrv X server when
> built with gtk3 toolkit
>
> > From: "J. Scott Berg" <jsberg-bnl@outlook.com>
> > Date: Thu, 15 Oct 2020 01:55:44 +0000
> >
> > Run "emacs -Q" on a remote machine, the local X server is VcXsrv on
> Windows
> > The window that opens will only have 5 lines.
> > This occurs when emacs is built to use the gtk3 toolkit
> > Everything is fine on the local display of the Linux machine
> > Everything is fine if emacs is built to use the gtk2 toolkit
>
> Do you have any GTK settings that could affect this, like font
> selection or window dimensions?
>
> If that doesn't give any clue, is it possible to you to run Emacs
> under GDB, put a breakpoint in adjust_frame_size, and tell when and by
> which code are these small dimensions specified during startup?
>
> Thanks.
next prev parent reply other threads:[~2020-10-16 14:47 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-15 1:55 bug#44002: 27.1; Small window height with VcXsrv X server when built with gtk3 toolkit J. Scott Berg
2020-10-16 7:31 ` Eli Zaretskii
2020-10-16 14:47 ` J. Scott Berg [this message]
2020-10-16 19:08 ` Eli Zaretskii
2020-10-16 19:47 ` J. Scott Berg
2020-10-16 23:29 ` J. Scott Berg
2020-10-17 7:52 ` Eli Zaretskii
2020-10-17 9:32 ` martin rudalics
2020-10-17 9:34 ` Eli Zaretskii
2020-10-17 9:40 ` martin rudalics
2020-10-17 17:32 ` Eli Zaretskii
2020-10-18 17:52 ` Robert Pluim
2020-10-18 17:56 ` Eli Zaretskii
2020-10-19 8:15 ` Robert Pluim
2021-02-25 20:04 ` Glenn Morris
2021-02-25 20:28 ` J. Scott Berg
2021-02-25 20:38 ` Eli Zaretskii
2020-10-19 14:02 ` J. Scott Berg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=MN2PR12MB4606951D68960E1D3AA9DDEC9A030@MN2PR12MB4606.namprd12.prod.outlook.com \
--to=jsberg-bnl@outlook.com \
--cc=44002@debbugs.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).