GNU bug report logs - #31169
Emacs 26.1 RC1 (gtk) display issues over SSH/X11 with xming/vcxsrv due to double-buffering

Previous Next

To reply to this bug, email your comments to 31169 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: charlie hemlock <charliehemlock <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 26.1;
 Emacs 26.1 RC1 (gtk) display issues over SSH/X11 with xming/vcxsrv
Date: Sun, 15 Apr 2018 20:09:42 -0400

[Message part 1 (text/plain, inline)]

1. Build emacs 26 RC1 with --with-x-toolkit=gtk3
     a. confirm builds and runs ok when run local
2. Login to windows box, launch ssh -X putty session to linux host with
emacs 26 installed.  (windows xserver: vcxsrv or xming)
3. emacs -Q
4. Emacs does not display correctly. Missing minibuffer, & can't type in
buffer.  Compare to attached screenshot.

I can compile Emacs 26.1 RC1 ok, and use it locally on the host fine.

However, when attempting to ssh -X to host via PuTTY 0.70 and launch  the
Emacs gui  (emacs -Q), emacs is not displaying correctly. Using Windows
xserver program VcXsrv (1.19.6.3).

See attached screenshot - no default welcome screen, and missing minibuffer
too.

I suspect this issue is related to some combination of GTK and
Xming/VcXsrv, however the behavior does change between Emacs 25.3 and 26.1
RC1, see table below:

I'ved tried the follow commits, and only 25.3 is ok over PuTTY/SSH/X11 &
xming/vcxsrv
 emacs-25.3 bd299e7       # Sep 12, 2017  # good
 emacs-26.0.90  906224    # Oct 11, 2017  # bad
 emacs-26.0.91 752fba99   # Jan 13, 2018  # bad
 emacs-26.1-rc1 c2674216  # Apr 9, 2018   # bad


The following ./configure options are desired:
--with-x-toolkit=gtk3 --with-xwidgets  --with-modules --with-mailutils
Where gtk3 is required for xwidgets, so other x-toolkits are not the best
solution.
Also --with-x-toolkit=gtk2  has same issues.

Similiar information posted here:
 - https://emacs.stackexchange.com/questions/41021/emacs-26-
1-rc1-display-issues-over-ssh-x11-with-xming-vcxsrv
Possibly related posts:
 - https://emacs.stackexchange.com/questions/40990/emacs-
aborted-core-dumped-centos-7-0-emacs-25-3-please-help
 - https://bugs.launchpad.net/elementaryos/+bug/1355274
 - https://bugzilla.gnome.org/show_bug.cgi?id=85715

Also attempted on CentOS 7 / GTK+ Version 3.22.10 with similar behavior.
Thanks,
CH


In GNU Emacs 26.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.20.10)
 of 2018-04-10 built on atlas
Windowing system distributor 'The X.Org Foundation', version 11.0.11803000
System Description:    openSUSE Leap 42.3

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Making completion list...

Configured using:
 'configure --with-x-toolkit=gtk3 --with-xwidgets --with-modules
 --with-mailutils --prefix=/home/brian/sandbox/emacs_26.1'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND DBUS GSETTINGS NOTIFY
GNUTLS LIBXML2 FREETYPE XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 MODULES
THREADS XWIDGETS LCMS2

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-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
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: 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 rmail-loaddefs mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils elec-pair time-date
mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode elisp-mode lisp-mode prog-mode register page menu-bar
rfn-eshadow isearch timer select scroll-bar 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 dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting xwidget-internal
move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 95213 9039)
 (symbols 48 20393 2)
 (miscs 40 74 143)
 (strings 32 28418 1528)
 (string-bytes 1 751586)
 (vectors 16 14028)
 (vector-slots 8 493536 10574)
 (floats 8 49 68)
 (intervals 56 229 0)
 (buffers 992 12)
 (heap 1024 41537 1116))

[Message part 2 (text/html, inline)]

[emacs26_PuTTY.png (image/png, attachment)]

Message #8 received at 31169 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: charlie hemlock <charliehemlock <at> gmail.com>
Cc: 31169 <at> debbugs.gnu.org
Subject: Re: bug#31169: 26.1;
 Emacs 26.1 RC1 (gtk) display issues over SSH/X11 with xming/vcxsrv
Date: Mon, 16 Apr 2018 20:40:30 +0300

> From: charlie hemlock <charliehemlock <at> gmail.com>
> Date: Sun, 15 Apr 2018 20:09:42 -0400
> 
> 1. Build emacs 26 RC1 with --with-x-toolkit=gtk3
>      a. confirm builds and runs ok when run local
> 2. Login to windows box, launch ssh -X putty session to linux host with
> emacs 26 installed.  (windows xserver: vcxsrv or xming) 
> 3. emacs -Q
> 4. Emacs does not display correctly. Missing minibuffer, & can't type in buffer.  Compare to attached
> screenshot.

Is this all you see in the Emacs frame?  It looks like a part of a
frame, did you clip the image, perhaps?  If so, please show all of the
frame.

> I can compile Emacs 26.1 RC1 ok, and use it locally on the host fine.
> 
> However, when attempting to ssh -X to host via PuTTY 0.70 and launch  the Emacs gui  (emacs -Q), emacs
> is not displaying correctly. Using Windows xserver program VcXsrv (1.19.6.3).
> 
> See attached screenshot - no default welcome screen, and missing minibuffer too. 

It sounds like Emacs is hung or infloops somewhere.  Does it eat CPU
cycles?  Can you exit it with "C-x C-c" or do you have to kill it by a
signal?  Can you attach GDB to it (on the GNU/Linux side) and show a C
backtrace?  Please do this several times, restarting Emacs each time,
to make sure the backtrace points to the same place.

> I suspect this issue is related to some combination of GTK and
> Xming/VcXsrv, however the behavior does change between Emacs 25.3 and 26.1 RC1, see table below:

To make sure this is related to GTK, could you try building with a
different toolkit, just to see if that build starts as expected?

> Possibly related posts:
>  -
> https://emacs.stackexchange.com/questions/40990/emacs-aborted-core-dumped-centos-7-0-emacs-25-3-please-help
> 
>  - https://bugs.launchpad.net/elementaryos/+bug/1355274
>  - https://bugzilla.gnome.org/show_bug.cgi?id=85715

These don't look related to me, because the problems they describe
existed before Emacs 25, which you say worked OK for you.

Thanks.

Message #11 received at 31169 <at> debbugs.gnu.org (full text, mbox):

From: charlie hemlock <charliehemlock <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 31169 <at> debbugs.gnu.org
Subject: Re: bug#31169: 26.1; Emacs 26.1 RC1 (gtk) display issues over SSH/X11
 with xming/vcxsrv
Date: Mon, 16 Apr 2018 19:37:44 -0400

[Message part 1 (text/plain, inline)]

 > Is this all you see in the Emacs frame?  It looks like a part of a
> frame , did you clip the image, perhaps?  If so, please show all of the
frame.

That was all the frame. Including new attachment [emacs26_gtk3.png] for
clarity. (show a little of background and putty window). I tried resizing
window and same result.

> To make sure this is related to GTK, could you try building with a
> different toolkit, just to see if that build starts as expected?

Attached with "motif" x-toolkit screenshot. [emacs26_motif.png].
Appears OK,  but I can't ./configure --with-xwidgets

  > Does it eat CPU cycles?
No - just looked a 'top' output.

> Can you exit it with "C-x C-c" or do you have to kill it by a
signal?
C-x C-x works.

> Can you attach GDB to it (on the GNU/Linux side) and show a C
backtrace?

I attempted to do GDB backtrace even though its starting to get beyond my
comfort zone.
Results attached for CentOS7 and Leap 42.3.  Likely I didn't do this
correctly to be useful - please advise.

Thanks!
CH



On Mon, Apr 16, 2018 at 1:40 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: charlie hemlock <charliehemlock <at> gmail.com>
> > Date: Sun, 15 Apr 2018 20:09:42 -0400
> >
> > 1. Build emacs 26 RC1 with --with-x-toolkit=gtk3
> >      a. confirm builds and runs ok when run local
> > 2. Login to windows box, launch ssh -X putty session to linux host with
> > emacs 26 installed.  (windows xserver: vcxsrv or xming)
> > 3. emacs -Q
> > 4. Emacs does not display correctly. Missing minibuffer, & can't type in
> buffer.  Compare to attached
> > screenshot.
>
> Is this all you see in the Emacs frame?  It looks like a part of a
> frame, did you clip the image, perhaps?  If so, please show all of the
> frame.
>
> > I can compile Emacs 26.1 RC1 ok, and use it locally on the host fine.
> >
> > However, when attempting to ssh -X to host via PuTTY 0.70 and launch
> the Emacs gui  (emacs -Q), emacs
> > is not displaying correctly. Using Windows xserver program VcXsrv
> (1.19.6.3).
> >
> > See attached screenshot - no default welcome screen, and missing
> minibuffer too.
>
> It sounds like Emacs is hung or infloops somewhere.  Does it eat CPU
> cycles?  Can you exit it with "C-x C-c" or do you have to kill it by a
> signal?  Can you attach GDB to it (on the GNU/Linux side) and show a C
> backtrace?  Please do this several times, restarting Emacs each time,
> to make sure the backtrace points to the same place.
>
> > I suspect this issue is related to some combination of GTK and
> > Xming/VcXsrv, however the behavior does change between Emacs 25.3 and
> 26.1 RC1, see table below:
>
> To make sure this is related to GTK, could you try building with a
> different toolkit, just to see if that build starts as expected?
>
> > Possibly related posts:
> >  -
> > https://emacs.stackexchange.com/questions/40990/emacs-
> aborted-core-dumped-centos-7-0-emacs-25-3-please-help
> >
> >  - https://bugs.launchpad.net/elementaryos/+bug/1355274
> >  - https://bugzilla.gnome.org/show_bug.cgi?id=85715
>
> These don't look related to me, because the problems they describe
> existed before Emacs 25, which you say worked OK for you.
>
> Thanks.
>

[Message part 2 (text/html, inline)]

[centos7.txt (text/plain, attachment)]

[emacs26_gtk3.png (image/png, attachment)]

[emacs26_motif.png (image/png, attachment)]

[leap43.2.txt (text/plain, attachment)]

Message #14 received at 31169 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: charlie hemlock <charliehemlock <at> gmail.com>
Cc: 31169 <at> debbugs.gnu.org
Subject: Re: bug#31169: 26.1; Emacs 26.1 RC1 (gtk) display issues over SSH/X11
 with xming/vcxsrv
Date: Tue, 17 Apr 2018 05:34:58 +0300

> From: charlie hemlock <charliehemlock <at> gmail.com>
> Date: Mon, 16 Apr 2018 19:37:44 -0400
> Cc: 31169 <at> debbugs.gnu.org
> 
> > Is this all you see in the Emacs frame?  It looks like a part of a
> > frame , did you clip the image, perhaps?  If so, please show all of the frame. 
> 
> That was all the frame. Including new attachment [emacs26_gtk3.png] for clarity. (show a little of background
> and putty window). I tried resizing window and same result.
> 
> > To make sure this is related to GTK, could you try building with a
> > different toolkit, just to see if that build starts as expected? 
> 
> Attached with "motif" x-toolkit screenshot. [emacs26_motif.png].
> Appears OK,  but I can't ./configure --with-xwidgets 

The Motif frame looks better, but still not entirely normal: what's
that empty space to the right of the window?

Is that similar to what you see locally on the GNU/Linux box?

>   > Does it eat CPU cycles?  
> No - just looked a 'top' output.
> 
> > Can you exit it with "C-x C-c" or do you have to kill it by a
> signal?  
> C-x C-x works.

If "C-x C-c" works, then does "M-x redraw-display RET" redraw the
frame to its normal appearance?

What about "C-x 5 b RET" -- does it create a new frame, and does that
frame look correctly?

Thanks.

Message #17 received at 31169 <at> debbugs.gnu.org (full text, mbox):

From: charlie hemlock <charliehemlock <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 31169 <at> debbugs.gnu.org
Subject: Re: bug#31169: 26.1; Emacs 26.1 RC1 (gtk) display issues over SSH/X11
 with xming/vcxsrv
Date: Tue, 17 Apr 2018 20:30:33 -0400

[Message part 1 (text/plain, inline)]

 > The Motif frame looks better, but still not entirely normal: what's that
empty space to the right of the  window? Is that similar  to what you see
locally on the GNU/Linux box?

That empty narrow space looks similar as locally launched Emacs. That
narrow area is where line wrap indicators show up.


> If "C-x C-c" works, then does  "M-x redraw-display RET" redraw the frame
to its normal appearance?

No.

> What about "C-x 5 b  RET" -- does it create a new frame, and does that
frame look correctly?

Creates new frame. Does not look correct - same as first.

C-x 2   does split frame. But still missing minibuffer and can't type in
either buffer.

I also clicked the "File" button on menu bar, and got several errors below,
and the File Menu did not display:
However, Clicking the Open File icon did open the file browser .
Related to this menu issue:
 - https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1700319
 - https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1700319
 - Can't say if these are related to the original display issues discussed
here or entire separate issue

% ~/release/emacs_26.1/bin/emacs -Q

(emacs:3612): Gtk-CRITICAL **: gtk_widget_get_preferred_height_for_width:
assertion 'width >= 0' failed

[[removed several repeats]]

(emacs:3612): Gtk-CRITICAL **: gtk_widget_get_preferred_height_for_width:
assertion 'width >= 0' failed
*** BUG ***
In pixman_region32_init_rect: Invalid rectangle passed
Set a breakpoint on '_pixman_log_error' to debug

*** BUG ***
In pixman_region32_init_rect: Invalid rectangle passed
Set a breakpoint on '_pixman_log_error' to debug

(emacs:3612): Gtk-WARNING **: Negative content width -7 (allocation 1,
extents 4x4) while allocating gadget (node arrow, owner GtkMenu)

(emacs:3612): Gtk-WARNING **: Negative content width -7 (allocation 1,
extents 4x4) while allocating gadget (node arrow, owner GtkMenu)
*** BUG ***
In pixman_region32_init_rect: Invalid rectangle passed
Set a breakpoint on '_pixman_log_error' to debug

(emacs:3612): Gtk-WARNING **: Negative content width -11 (allocation 1,
extents 6x6) while allocating gadget (node menuitem, owner GtkMenuItem)

(emacs:3612): Gtk-WARNING **: Negative content height -7 (allocation 1,
extents 4x4) while allocating gadget (node menuitem, owner GtkMenuItem)

[[removed several repeats]]


In my original post - I forgot to mention with xming 6.9.0.31 (not vcxsrv)
I get different emacs behavior (the test combinations are growing) .
The emacs gui launches and appears ok, but core dumps as soon as I attempt
anything else.
% ~/release/emacs_26.1/bin/emacs -Q
# click anywhere
X protocol error: BadRequest (invalid request code or no such operation) on
protocol request 130
When compiled with GTK, Emacs cannot recover from X disconnects.
This is a GTK bug: https://bugzilla.gnome.org/show_bug.cgi?id=85715
For details, see etc/PROBLEMS.
Fatal error 6: Aborted

But I did include that bug link
<https://bugzilla.gnome.org/show_bug.cgi?id=85715>in original post.   I
can't say if these are closely or distantly or not related.

Anyone else experiencing or able to replicate?
Thanks!

On Mon, Apr 16, 2018 at 10:34 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: charlie hemlock <charliehemlock <at> gmail.com>
> > Date: Mon, 16 Apr 2018 19:37:44 -0400
> > Cc: 31169 <at> debbugs.gnu.org
> >
> > > Is this all you see in the Emacs frame?  It looks like a part of a
> > > frame , did you clip the image, perhaps?  If so, please show all of
> the frame.
> >
> > That was all the frame. Including new attachment [emacs26_gtk3.png] for
> clarity. (show a little of background
> > and putty window). I tried resizing window and same result.
> >
> > > To make sure this is related to GTK, could you try building with a
> > > different toolkit, just to see if that build starts as expected?
> >
> > Attached with "motif" x-toolkit screenshot. [emacs26_motif.png].
> > Appears OK,  but I can't ./configure --with-xwidgets
>
> The Motif frame looks better, but still not entirely normal: what's
> that empty space to the right of the window?
>
> Is that similar to what you see locally on the GNU/Linux box?
>
> >   > Does it eat CPU cycles?
> > No - just looked a 'top' output.
> >
> > > Can you exit it with "C-x C-c" or do you have to kill it by a
> > signal?
> > C-x C-x works.
>
> If "C-x C-c" works, then does "M-x redraw-display RET" redraw the
> frame to its normal appearance?
>
> What about "C-x 5 b RET" -- does it create a new frame, and does that
> frame look correctly?
>
> Thanks.
>

[Message part 2 (text/html, inline)]

Message #20 received at 31169 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: charlie hemlock <charliehemlock <at> gmail.com>
Cc: 31169 <at> debbugs.gnu.org
Subject: Re: bug#31169: 26.1; Emacs 26.1 RC1 (gtk) display issues over SSH/X11
 with xming/vcxsrv
Date: Wed, 18 Apr 2018 16:20:24 +0300

> From: charlie hemlock <charliehemlock <at> gmail.com>
> Date: Tue, 17 Apr 2018 20:30:33 -0400
> Cc: 31169 <at> debbugs.gnu.org
> 
> > The Motif frame looks better, but still not entirely normal: what's that empty space to the right of the 
> window? Is that similar  to what you see locally on the GNU/Linux box?
> 
> That empty narrow space looks similar as locally launched Emacs. That narrow area is where line wrap
> indicators show up.

That's the fringe.  And that's already bad: why isn't it being
displayed?  The fringe on the left displays correctly.  Do you see
anything in the *Messages* buffer that could hint on the problem?

Maybe the Motif build bit-rotted.  Is it possible for you to try
building with Lucid instead?  If the Lucid build shows the same
problem when run locally, I think the local display problems need to
be investigated first, but I wonder how come no one else sees these
display problems, they are pretty apparent and cannot be missed.

> I also clicked the "File" button on menu bar, and got several errors below, and the File Menu did not display:
> However, Clicking the Open File icon did open the file browser .
> Related to this menu issue:
>  - https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1700319
>  - https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1700319
>  - Can't say if these are related to the original display issues discussed here or entire separate issue

This bug says the problem is fixed in GTK+ 3.22.25.  Can you try that
version of GTK+?

> % ~/release/emacs_26.1/bin/emacs -Q
> 
> (emacs:3612): Gtk-CRITICAL **: gtk_widget_get_preferred_height_for_width: assertion 'width >= 0' failed
> 
> [[removed several repeats]]
> 
> (emacs:3612): Gtk-CRITICAL **: gtk_widget_get_preferred_height_for_width: assertion 'width >= 0' failed
> *** BUG ***
> In pixman_region32_init_rect: Invalid rectangle passed
> Set a breakpoint on '_pixman_log_error' to debug
> 
> *** BUG ***
> In pixman_region32_init_rect: Invalid rectangle passed
> Set a breakpoint on '_pixman_log_error' to debug
> 
> (emacs:3612): Gtk-WARNING **: Negative content width -7 (allocation 1, extents 4x4) while allocating gadget
> (node arrow, owner GtkMenu)
> 
> (emacs:3612): Gtk-WARNING **: Negative content width -7 (allocation 1, extents 4x4) while allocating gadget
> (node arrow, owner GtkMenu)
> *** BUG ***
> In pixman_region32_init_rect: Invalid rectangle passed
> Set a breakpoint on '_pixman_log_error' to debug
> 
> (emacs:3612): Gtk-WARNING **: Negative content width -11 (allocation 1, extents 6x6) while allocating
> gadget (node menuitem, owner GtkMenuItem)
> 
> (emacs:3612): Gtk-WARNING **: Negative content height -7 (allocation 1, extents 4x4) while allocating gadget
> (node menuitem, owner GtkMenuItem)

And Emacs 25, which works for you in the same setup, uses the same
version of GTK+ as the 26.1RC1 build?

> The emacs gui launches and appears ok, but core dumps as soon as I attempt anything else.
> % ~/release/emacs_26.1/bin/emacs -Q
> # click anywhere
> X protocol error: BadRequest (invalid request code or no such operation) on protocol request 130
> When compiled with GTK, Emacs cannot recover from X disconnects.
> This is a GTK bug: https://bugzilla.gnome.org/show_bug.cgi?id=85715
> For details, see etc/PROBLEMS.
> Fatal error 6: Aborted
> 
> But I did include that bug link in original post.   I can't say if these are closely or distantly or not related.

Those are for Emacs 23, 24, and 25, whereas you said Emacs 25 worked
for you.  So how can those be the same problems?  And if they are the
same problem, clearly the solution should be in GTK+, not in Emacs,
right?

Message #23 received at 31169 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: charlie hemlock <charliehemlock <at> gmail.com>
Cc: 31169 <at> debbugs.gnu.org
Subject: Re: bug#31169: 26.1;
 Emacs 26.1 RC1 (gtk) display issues over SSH/X11 with xming/vcxsrv
Date: Wed, 18 Apr 2018 20:42:21 -0400

charlie hemlock <charliehemlock <at> gmail.com> writes:

> 1. Build emacs 26 RC1 with --with-x-toolkit=gtk3
>      a. confirm builds and runs ok when run local
> 2. Login to windows box, launch ssh -X putty session to linux host with
> emacs 26 installed.  (windows xserver: vcxsrv or xming) 
> 3. emacs -Q
> 4. Emacs does not display correctly. Missing minibuffer, & can't type in buffer.  Compare to attached screenshot.
>
> I can compile Emacs 26.1 RC1 ok, and use it locally on the host fine.
>
> However, when attempting to ssh -X to host via PuTTY 0.70 and launch
> the Emacs gui (emacs -Q), emacs is not displaying correctly. Using
> Windows xserver program VcXsrv (1.19.6.3).
>
> See attached screenshot - no default welcome screen, and missing minibuffer too. 

This looks similar to Bug#25474, does adding

    (modify-frame-parameters nil '((inhibit-double-buffering . t)))

to your init.el as suggested there help?

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25474

Message #26 received at 31169 <at> debbugs.gnu.org (full text, mbox):

From: charlie hemlock <charliehemlock <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 31169 <at> debbugs.gnu.org
Subject: Re: bug#31169: 26.1; Emacs 26.1 RC1 (gtk) display issues over SSH/X11
 with xming/vcxsrv
Date: Wed, 18 Apr 2018 20:58:10 -0400

[Message part 1 (text/plain, inline)]

 > That's the fringe.  And that's already bad: why isn't it being
> displayed?  The fringe on the left displays correctly.

Ah ok.  I suspect this could be a vcxsrv issue. As if I resize the emacs
window it can go away. See 2 attachments build with lucid.
Only change is resizing window.


> Do you see anything in the *Messages* buffer that could hint on the
problem?

No messages. Note I can't see it in gtk builds - but I can save the
messages buffer to file and confirm its just the default message.
"For information about GNU Emacs and the GNU system, type C-h C-a."


> Maybe the Motif build bit-rotted.  Is it possible for you to try
> building with Lucid instead? If the Lucid build shows the same
> problem when run locally, I think the local display problems need to
> be investigated first, but I wonder how come no one else sees these
> display problems, they are pretty apparent and cannot be missed.

See attachments (remote display emacs lucid).  I don't believe I have any
local display issues.


Sorry for the repeated links for the gtk menu bugs (long day), they should
have been:
- https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1700319
- https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/992464


> This bug says the problem is fixed in GTK+ 3.22.25.  Can you try that
version of GTK+?
See table below.

> Those are for Emacs 23, 24, and 25, whereas you said Emacs 25 workedf or
you.  So how can those be the same problems?  And if they are the
> same problem, clearly the solution should be in GTK+, not in Emacs,right?

So Emacs 25.3 gtk3 displayed via *xming* also core dumps.  Like I said the
# of combinations is growing.
Also feels like there we're dealing with more than one bug here.
I'd feel a lot better if someone else could replicate.

An attempt to recap (xming 6.9.0.31, VcXsrv  1.19.6.3)

CentOS7, gtk: 2.24.31,  gtk3: 3.22.10
| emacs      | Xming     | VcXsrv                 |
+------------+-----------+------------------------+
| 25.3  gtk2 | ok        | ok                     |
| 25.3  gtk3 | core dump | display ok, menus bad  |
| 26.1  gtk2 | ok        | bad, but menus ok      |
| 26.1  gtk3 | core dump | bad, menus bad         |

OpenSUSE Leap 42.3 , gtk2: 2.24.31,  gtk3: 3.22.10
| emacs      | Xming     | VcXsrv             |
+------------+-----------+--------------------+
| 25.3  gtk2 | ok        | ok                 |
| 25.3  gtk3 | core dump | ok                 |
| 26.1  gtk2 | ok        | bad, but menus ok  |
| 26.1  gtk3 | core dump | bad, but menus ok  |


OpenSUSE Tumbleweed, gtk2: 2.24.32,  gtk3: 3.22.29
| emacs      | Xming     | VcXsrv
+------------+-----------+---------------------------+
| 25.3  gtk2 | ok        | ok                        |
| 25.3  gtk3 | ok        | ok                        |
| 26.1  gtk2 | ok        | sometimes bad?!, menus ok |
| 26.1  gtk3 | ok        | bad, but menus ok         |

core dump references https://bugzilla.gnome.org/show_bug.cgi?id=85715
bad = bad display of minibuffer and main buffer.
menu ok = refers to clicking File Menu and buttons.

(tumbleweed and centos are VMs)

Thanks,
CH


On Wed, Apr 18, 2018 at 9:20 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: charlie hemlock <charliehemlock <at> gmail.com>
> > Date: Tue, 17 Apr 2018 20:30:33 -0400
> > Cc: 31169 <at> debbugs.gnu.org
> >
> > > The Motif frame looks better, but still not entirely normal: what's
> that empty space to the right of the
> > window? Is that similar  to what you see locally on the GNU/Linux box?
> >
> > That empty narrow space looks similar as locally launched Emacs. That
> narrow area is where line wrap
> > indicators show up.
>
> That's the fringe.  And that's already bad: why isn't it being
> displayed?  The fringe on the left displays correctly.  Do you see
> anything in the *Messages* buffer that could hint on the problem?
>
> Maybe the Motif build bit-rotted.  Is it possible for you to try
> building with Lucid instead?  If the Lucid build shows the same
> problem when run locally, I think the local display problems need to
> be investigated first, but I wonder how come no one else sees these
> display problems, they are pretty apparent and cannot be missed.
>
> > I also clicked the "File" button on menu bar, and got several errors
> below, and the File Menu did not display:
> > However, Clicking the Open File icon did open the file browser .
> > Related to this menu issue:
> >  - https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1700319
> >  - https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1700319
> >  - Can't say if these are related to the original display issues
> discussed here or entire separate issue
>
> This bug says the problem is fixed in GTK+ 3.22.25.  Can you try that
> version of GTK+?
>
> > % ~/release/emacs_26.1/bin/emacs -Q
> >
> > (emacs:3612): Gtk-CRITICAL **: gtk_widget_get_preferred_height_for_width:
> assertion 'width >= 0' failed
> >
> > [[removed several repeats]]
> >
> > (emacs:3612): Gtk-CRITICAL **: gtk_widget_get_preferred_height_for_width:
> assertion 'width >= 0' failed
> > *** BUG ***
> > In pixman_region32_init_rect: Invalid rectangle passed
> > Set a breakpoint on '_pixman_log_error' to debug
> >
> > *** BUG ***
> > In pixman_region32_init_rect: Invalid rectangle passed
> > Set a breakpoint on '_pixman_log_error' to debug
> >
> > (emacs:3612): Gtk-WARNING **: Negative content width -7 (allocation 1,
> extents 4x4) while allocating gadget
> > (node arrow, owner GtkMenu)
> >
> > (emacs:3612): Gtk-WARNING **: Negative content width -7 (allocation 1,
> extents 4x4) while allocating gadget
> > (node arrow, owner GtkMenu)
> > *** BUG ***
> > In pixman_region32_init_rect: Invalid rectangle passed
> > Set a breakpoint on '_pixman_log_error' to debug
> >
> > (emacs:3612): Gtk-WARNING **: Negative content width -11 (allocation 1,
> extents 6x6) while allocating
> > gadget (node menuitem, owner GtkMenuItem)
> >
> > (emacs:3612): Gtk-WARNING **: Negative content height -7 (allocation 1,
> extents 4x4) while allocating gadget
> > (node menuitem, owner GtkMenuItem)
>
> And Emacs 25, which works for you in the same setup, uses the same
> version of GTK+ as the 26.1RC1 build?
>
> > The emacs gui launches and appears ok, but core dumps as soon as I
> attempt anything else.
> > % ~/release/emacs_26.1/bin/emacs -Q
> > # click anywhere
> > X protocol error: BadRequest (invalid request code or no such operation)
> on protocol request 130
> > When compiled with GTK, Emacs cannot recover from X disconnects.
> > This is a GTK bug: https://bugzilla.gnome.org/show_bug.cgi?id=85715
> > For details, see etc/PROBLEMS.
> > Fatal error 6: Aborted
> >
> > But I did include that bug link in original post.   I can't say if these
> are closely or distantly or not related.
>
> Those are for Emacs 23, 24, and 25, whereas you said Emacs 25 worked
> for you.  So how can those be the same problems?  And if they are the
> same problem, clearly the solution should be in GTK+, not in Emacs,
> right?
>

[Message part 2 (text/html, inline)]

[emacs26.1_lucid.PNG (image/png, attachment)]

[emacs26.1_lucid2.PNG (image/png, attachment)]

Message #29 received at 31169 <at> debbugs.gnu.org (full text, mbox):

From: charlie hemlock <charliehemlock <at> gmail.com>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: 31169 <at> debbugs.gnu.org
Subject: Re: bug#31169: 26.1; Emacs 26.1 RC1 (gtk) display issues over SSH/X11
 with xming/vcxsrv
Date: Wed, 18 Apr 2018 21:18:15 -0400

[Message part 1 (text/plain, inline)]

 > This looks similar to Bug#25474, does adding

    (modify-frame-parameters nil '((inhibit-double-buffering . t)))

> to your init.el as suggested there help?

> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25474
<https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25474>


I quickly tested this in tumbleweed, leap 42.3, and centos 7 and appears to
help :)
Wow, Thanks!

I don't get the emacs logo - just plain text welcome, but at least I can
see minibuffer and type.

*However*, in Centos7 (with vcxsrv), the file menus don't appear OK when
clicked as previously reported (see gtk errors in previous posts)
A different issue?

Thanks!


On Wed, Apr 18, 2018 at 8:42 PM, Noam Postavsky <npostavs <at> gmail.com> wrote:

> charlie hemlock <charliehemlock <at> gmail.com> writes:
>
> > 1. Build emacs 26 RC1 with --with-x-toolkit=gtk3
> >      a. confirm builds and runs ok when run local
> > 2. Login to windows box, launch ssh -X putty session to linux host with
> > emacs 26 installed.  (windows xserver: vcxsrv or xming)
> > 3. emacs -Q
> > 4. Emacs does not display correctly. Missing minibuffer, & can't type in
> buffer.  Compare to attached screenshot.
> >
> > I can compile Emacs 26.1 RC1 ok, and use it locally on the host fine.
> >
> > However, when attempting to ssh -X to host via PuTTY 0.70 and launch
> > the Emacs gui (emacs -Q), emacs is not displaying correctly. Using
> > Windows xserver program VcXsrv (1.19.6.3).
> >
> > See attached screenshot - no default welcome screen, and missing
> minibuffer too.
>
> This looks similar to Bug#25474, does adding
>
>     (modify-frame-parameters nil '((inhibit-double-buffering . t)))
>
> to your init.el as suggested there help?
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25474
>

[Message part 2 (text/html, inline)]

Message #32 received at 31169 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: charlie hemlock <charliehemlock <at> gmail.com>
Cc: 31169 <at> debbugs.gnu.org
Subject: Re: bug#31169: 26.1;
 Emacs 26.1 RC1 (gtk) display issues over SSH/X11 with xming/vcxsrv
Date: Wed, 18 Apr 2018 21:27:40 -0400

charlie hemlock <charliehemlock <at> gmail.com> writes:

> However, in Centos7 (with vcxsrv), the file menus don't appear OK when
> clicked as previously reported (see gtk errors in previous posts) A
> different issue?

Yeah, the other bug specifically mentions that menus work fine, so it
sounds like you're hitting some other issue as well.

Message #35 received at 31169 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: charlie hemlock <charliehemlock <at> gmail.com>
Cc: 31169 <at> debbugs.gnu.org, Daniel Colascione <dancol <at> dancol.org>,
 npostavs <at> gmail.com
Subject: Re: bug#31169: 26.1;
 Emacs 26.1 RC1 (gtk) display issues over SSH/X11 with xming/vcxsrv
Date: Thu, 19 Apr 2018 09:43:53 +0300

retitle 31169 Emacs 26.1 RC1 (gtk) display issues over SSH/X11 with xming/vcxsrv due to	double-buffering
thanks

> From: charlie hemlock <charliehemlock <at> gmail.com>
> Date: Wed, 18 Apr 2018 21:18:15 -0400
> Cc: 31169 <at> debbugs.gnu.org
> 
> > This looks similar to Bug#25474, does adding
> 
>     (modify-frame-parameters nil '((inhibit-double-buffering . t)))
> 
> > to your init.el as suggested there help?
> 
> > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25474 
> 
> I quickly tested this in tumbleweed, leap 42.3, and centos 7 and appears to help :)
> Wow, Thanks!
> 
> I don't get the emacs logo - just plain text welcome, but at least I can see minibuffer and type.

Great, thanks to Noam for reminding the double-buffering issues.

I hope Daniel (CC'ed) will be able to look at those problems some time
soon.

Message #38 received at 31169 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: 31169 <at> debbugs.gnu.org, charliehemlock <at> gmail.com
Subject: Re: bug#31169: 26.1;
 Emacs 26.1 RC1 (gtk) display issues over SSH/X11 with xming/vcxsrv
Date: Thu, 19 Apr 2018 09:47:02 +0300

> From: Noam Postavsky <npostavs <at> gmail.com>
> Date: Wed, 18 Apr 2018 21:27:40 -0400
> Cc: 31169 <at> debbugs.gnu.org
> 
> charlie hemlock <charliehemlock <at> gmail.com> writes:
> 
> > However, in Centos7 (with vcxsrv), the file menus don't appear OK when
> > clicked as previously reported (see gtk errors in previous posts) A
> > different issue?
> 
> Yeah, the other bug specifically mentions that menus work fine, so it
> sounds like you're hitting some other issue as well.

And according to the table you show, those menu problems are resolved
in a later version of GTK+, is that right?

Message #43 received at 31169 <at> debbugs.gnu.org (full text, mbox):

From: charlie hemlock <charliehemlock <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 31169 <at> debbugs.gnu.org, Noam Postavsky <npostavs <at> gmail.com>
Subject: Re: bug#31169: 26.1; Emacs 26.1 RC1 (gtk) display issues over SSH/X11
 with xming/vcxsrv
Date: Thu, 19 Apr 2018 19:41:33 -0400

[Message part 1 (text/plain, inline)]

> And according to the table you show, those menu problems are resolved
> in a later version of GTK+, is that right?

I believe so, CentOS 7 still has menu issues.
& I did see other oddness -  but still definitely better with
inhibit-double-buffering


loading with init.el that only contains:
modify-frame-parameters nil '((inhibit-double-buffering . t)))

emacs -q -l ./init.el


CentOS7, gtk: 2.24.31,  gtk3: 3.22.10
| emacs      | VcXsrv                           |
| 25.3  gtk2 | ok                               |
| 25.3  gtk3 | ok, no emacs logo, menus no show |
| 26.1  gtk2 | ok                               |
| 26.1  gtk3 | ok, no emacs logo, menus no show |

OpenSUSE Leap 42.3 , gtk2: 2.24.31,  gtk3: 3.22.10
| emacs      | VcXsrv                    |
| 25.3  gtk2 | ok                        |
| 25.3  gtk3 | ok, but no emacs logo (1) |
| 26.1  gtk2 | ok                        |
| 26.1  gtk3 | ok, but no emacs logo (1) |


OpenSUSE Tumbleweed, gtk2: 2.24.32,  gtk3: 3.22.29
| emacs      | VcXsrv                    |
| 25.3  gtk2 | ok                        |
| 25.3  gtk3 | ok, but no emacs logo (2) |
| 26.1  gtk2 | ok                        |
| 26.1  gtk3 | ok, but no emacs logo (2) |

(1)  "About GNU" launches external browser when in ssh
remote session. But "M-x eww gnu.org" will display in eww mode.
Additionally, local emacs session uses Eww mode for the about pages, and
displays emacs logo.

(2) "About GNU" launches non-emacs text editor of .html when in ssh
remote session. But "M-x eww gnu.org" will display in eww mode.
Additionally, local emacs session does use Eww mode for About GNU.
but also opens the .html into non-emacs text editor (gedit), and does not
display emacs logo at startup.

On Thu, Apr 19, 2018 at 2:47 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Noam Postavsky <npostavs <at> gmail.com>
> > Date: Wed, 18 Apr 2018 21:27:40 -0400
> > Cc: 31169 <at> debbugs.gnu.org
> >
> > charlie hemlock <charliehemlock <at> gmail.com> writes:
> >
> > > However, in Centos7 (with vcxsrv), the file menus don't appear OK when
> > > clicked as previously reported (see gtk errors in previous posts) A
> > > different issue?
> >
> > Yeah, the other bug specifically mentions that menus work fine, so it
> > sounds like you're hitting some other issue as well.
>
> And according to the table you show, those menu problems are resolved
> in a later version of GTK+, is that right?
>

[Message part 2 (text/html, inline)]

Message #46 received at 31169 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: charlie hemlock <charliehemlock <at> gmail.com>
Cc: 31169 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#31169: 26.1;
 Emacs 26.1 RC1 (gtk) display issues over SSH/X11 with xming/vcxsrv
Date: Thu, 19 Apr 2018 20:06:32 -0400

[Message part 1 (text/plain, inline)]

charlie hemlock <charliehemlock <at> gmail.com> writes:

> does not display emacs logo at startup.

So, there is something a bit strange with the startup screen, but it
seems it's a separate issue.  I have Emacs windows set to popup in a
different workspace.  If I quickly switch to the target workspace before
Emacs manages to startup, then Emacs shows a screen containing a logo
(see attached emacs-logo.png).  If I wait for Emacs to start, and then
switch to the workspace, Emacs shows a screen without a logo (and all
monospace font).  This difference doesn't happen with Emacs 25.

[emacs-logo.png (image/png, attachment)]

[emacs-nologo.png (image/png, attachment)]

Message #49 received at 31169 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: 31169 <at> debbugs.gnu.org, charliehemlock <at> gmail.com
Subject: Re: bug#31169: 26.1;
 Emacs 26.1 RC1 (gtk) display issues over SSH/X11 with xming/vcxsrv
Date: Fri, 20 Apr 2018 09:54:00 +0300

> From: Noam Postavsky <npostavs <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  31169 <at> debbugs.gnu.org
> Date: Thu, 19 Apr 2018 20:06:32 -0400
> 
> So, there is something a bit strange with the startup screen, but it
> seems it's a separate issue.  I have Emacs windows set to popup in a
> different workspace.  If I quickly switch to the target workspace before
> Emacs manages to startup, then Emacs shows a screen containing a logo
> (see attached emacs-logo.png).  If I wait for Emacs to start, and then
> switch to the workspace, Emacs shows a screen without a logo (and all
> monospace font).  This difference doesn't happen with Emacs 25.

The logic that determines which startup screen to display is in
use-fancy-splash-screens-p.  Something there causes Emacs to decide
the second situation cannot handle the fancy splash screen.

Message #52 received at 31169 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 31169 <at> debbugs.gnu.org, charliehemlock <at> gmail.com
Subject: Re: bug#31169: 26.1;
 Emacs 26.1 RC1 (gtk) display issues over SSH/X11 with xming/vcxsrv
Date: Fri, 20 Apr 2018 08:05:12 -0400

Eli Zaretskii <eliz <at> gnu.org> writes:

> The logic that determines which startup screen to display is in
> use-fancy-splash-screens-p.  Something there causes Emacs to decide
> the second situation cannot handle the fancy splash screen.

Ah, `fancy-splash-frame' checks `frame-visible-p', which, for my window
manager, depends on when I switch to the workspace.  So it's the removal
of the wait for visibility changes again (related to bugs #24091,
#25521, and #29095).  Although setting x-wait-for-event-timeout doesn't
seem to affect this, maybe that's a bug.

I guess for OP's case, the remote X display is just a bit slow, so the
frame doesn't become visible in time.

Message #55 received at 31169 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: 31169 <at> debbugs.gnu.org, charliehemlock <at> gmail.com
Subject: Re: bug#31169: 26.1;
 Emacs 26.1 RC1 (gtk) display issues over SSH/X11 with xming/vcxsrv
Date: Fri, 20 Apr 2018 16:04:30 +0300

> From: Noam Postavsky <npostavs <at> gmail.com>
> Cc: 31169 <at> debbugs.gnu.org,  charliehemlock <at> gmail.com
> Date: Fri, 20 Apr 2018 08:05:12 -0400
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > The logic that determines which startup screen to display is in
> > use-fancy-splash-screens-p.  Something there causes Emacs to decide
> > the second situation cannot handle the fancy splash screen.
> 
> Ah, `fancy-splash-frame' checks `frame-visible-p', which, for my window
> manager, depends on when I switch to the workspace.

Is that a necessary test?  What happens if you use the selected frame,
when no frame is found to be visible?

Message #58 received at 31169 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 31169 <at> debbugs.gnu.org, charliehemlock <at> gmail.com
Subject: Re: bug#31169: 26.1;
 Emacs 26.1 RC1 (gtk) display issues over SSH/X11 with xming/vcxsrv
Date: Fri, 20 Apr 2018 09:11:51 -0400

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Ah, `fancy-splash-frame' checks `frame-visible-p', which, for my window
>> manager, depends on when I switch to the workspace.
>
> Is that a necessary test?  What happens if you use the selected frame,
> when no frame is found to be visible?

Seems to be unnecessary: if I comment out the frame-visible-p check, I
get the fancy splash regardless of when I switch workspace, and I see no
bad side effects.

Maybe that means this part would also be unneeded:

  (defun fancy-splash-frame ()
    [...]
    ;; MS-Windows needs this to have a chance to make the initial
    ;; frame visible.
    (if (eq (window-system) 'w32)
        (sit-for 0 t))

Message #61 received at 31169 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: 31169 <at> debbugs.gnu.org, charliehemlock <at> gmail.com
Subject: Re: bug#31169: 26.1;
 Emacs 26.1 RC1 (gtk) display issues over SSH/X11 with xming/vcxsrv
Date: Fri, 20 Apr 2018 17:17:32 +0300

> From: Noam Postavsky <npostavs <at> gmail.com>
> Cc: 31169 <at> debbugs.gnu.org,  charliehemlock <at> gmail.com
> Date: Fri, 20 Apr 2018 09:11:51 -0400
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> Ah, `fancy-splash-frame' checks `frame-visible-p', which, for my window
> >> manager, depends on when I switch to the workspace.
> >
> > Is that a necessary test?  What happens if you use the selected frame,
> > when no frame is found to be visible?
> 
> Seems to be unnecessary: if I comment out the frame-visible-p check, I
> get the fancy splash regardless of when I switch workspace, and I see no
> bad side effects.

So I guess we could simply fall back to the selected frame if no frame
is visible.  I wouldn't remove the test or fancy-splash-frame
entirely, because there could be several frames to choose from, and
this same code runs when the user invokes about-emacs in the middle of
a session.

> Maybe that means this part would also be unneeded:
> 
>   (defun fancy-splash-frame ()
>     [...]
>     ;; MS-Windows needs this to have a chance to make the initial
>     ;; frame visible.
>     (if (eq (window-system) 'w32)
>         (sit-for 0 t))

If we were removing the visibility test, yes.

Message #64 received at 31169 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 31169 <at> debbugs.gnu.org, charliehemlock <at> gmail.com
Subject: Re: bug#31169: 26.1;
 Emacs 26.1 RC1 (gtk) display issues over SSH/X11 with xming/vcxsrv
Date: Mon, 18 Jun 2018 20:16:50 -0400

merge 25474 31169
quit

Eli Zaretskii <eliz <at> gnu.org> writes:

> So I guess we could simply fall back to the selected frame if no frame
> is visible.  I wouldn't remove the test or fancy-splash-frame
> entirely, because there could be several frames to choose from, and
> this same code runs when the user invokes about-emacs in the middle of
> a session.

Ah, I had indeed missed that this function can be called in the middle
of a session.  I added the selected frame as a fallback in master [1:
91ebbbfa10], and I'm merging this bug to #25474.

[1: 91ebbbfa10]: 2018-06-18 20:02:03 -0400
  Default to splash on current frame, if none visible (Bug#31169)
  https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=91ebbbfa107c60db84e09d54d952ffd969821ccb

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.