GNU bug report logs - #18347
24.3.93; Incomplete splash screen display on Cygwin-w32 build

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 18347 in the body.
You can then email your comments to 18347 AT debbugs.gnu.org in the normal way.

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

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

From: Ken Brown <kbrown <at> cornell.edu>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.93; Incomplete splash screen display on Cygwin-w32 build
Date: Thu, 28 Aug 2014 17:51:06 -0400

When I start up the Cygwin-w32 build of emacs, the image at the top of 
the splash screen often fails to display.  The following patch fixes it:

=== modified file 'lisp/startup.el'
--- lisp/startup.el     2014-07-08 09:17:09 +0000
+++ lisp/startup.el     2014-08-28 20:07:20 +0000
@@ -1812,7 +1812,7 @@
   (let (chosen-frame)
     ;; MS-Windows needs this to have a chance to make the initial
     ;; frame visible.
-    (if (eq system-type 'windows-nt)
+    (if (eq window-system 'w32)
        (sit-for 0 t))
     (dolist (frame (append (frame-list) (list (selected-frame))))
       (if (and (frame-visible-p frame)

Is this still OK for the native Windows build?  If so, is it OK to 
install it in the release branch?


In GNU Emacs 24.3.93.2 (x86_64-unknown-cygwin)
 of 2014-08-28 on moufang
Repository revision: 117464 rgm <at> gnu.org-20140828191824-o5hn2x503w527yhn
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --with-w32 --enable-checking=yes,glyphs 'CFLAGS=-g3 -O0''

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ken Brown <kbrown <at> cornell.edu>
Cc: 18347 <at> debbugs.gnu.org
Subject: Re: bug#18347: 24.3.93;
 Incomplete splash screen display on Cygwin-w32 build
Date: Fri, 29 Aug 2014 09:25:01 +0300

> Date: Thu, 28 Aug 2014 17:51:06 -0400
> From: Ken Brown <kbrown <at> cornell.edu>
> 
> --- lisp/startup.el     2014-07-08 09:17:09 +0000
> +++ lisp/startup.el     2014-08-28 20:07:20 +0000
> @@ -1812,7 +1812,7 @@
>     (let (chosen-frame)
>       ;; MS-Windows needs this to have a chance to make the initial
>       ;; frame visible.
> -    (if (eq system-type 'windows-nt)
> +    (if (eq window-system 'w32)
>          (sit-for 0 t))
>       (dolist (frame (append (frame-list) (list (selected-frame))))
>         (if (and (frame-visible-p frame)

It is fundamentally wrong to use window-system the variable in such
circumstances (or almost any other).  Please use the function instead.

> Is this still OK for the native Windows build?  If so, is it OK to 
> install it in the release branch?

Yes and yes.  Although I'd urge you to try to figure out why this is
needed in the cygwin-w32 build (the native-build problem which led to
this code manifested itself in a rather different way, see bug#16014).

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

From: Ken Brown <kbrown <at> cornell.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 18347 <at> debbugs.gnu.org
Subject: Re: bug#18347: 24.3.93; Incomplete splash screen display on Cygwin-w32
 build
Date: Fri, 29 Aug 2014 11:08:21 -0400

On 8/29/2014 2:25 AM, Eli Zaretskii wrote:
>> Date: Thu, 28 Aug 2014 17:51:06 -0400
>> From: Ken Brown <kbrown <at> cornell.edu>
>>
>> --- lisp/startup.el     2014-07-08 09:17:09 +0000
>> +++ lisp/startup.el     2014-08-28 20:07:20 +0000
>> @@ -1812,7 +1812,7 @@
>>      (let (chosen-frame)
>>        ;; MS-Windows needs this to have a chance to make the initial
>>        ;; frame visible.
>> -    (if (eq system-type 'windows-nt)
>> +    (if (eq window-system 'w32)
>>           (sit-for 0 t))
>>        (dolist (frame (append (frame-list) (list (selected-frame))))
>>          (if (and (frame-visible-p frame)
>
> It is fundamentally wrong to use window-system the variable in such
> circumstances (or almost any other).  Please use the function instead.

OK.  But could you explain why?  TIA.

>> Is this still OK for the native Windows build?  If so, is it OK to
>> install it in the release branch?
>
> Yes and yes.  Although I'd urge you to try to figure out why this is
> needed in the cygwin-w32 build (the native-build problem which led to
> this code manifested itself in a rather different way, see bug#16014).

Actually, the visual symptom I'm describing (failure of the logo to 
appear) is identical to what Juanma reported in that bug.  Your message 
in that bug discussion says, "It's again that timing thing with making 
the initial frame visible."  The "again" suggests that there is an 
earlier bug report or discussion about that.  Can you give me a 
reference or just explain what you meant by that?

Ken

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ken Brown <kbrown <at> cornell.edu>
Cc: 18347 <at> debbugs.gnu.org
Subject: Re: bug#18347: 24.3.93;
 Incomplete splash screen display on Cygwin-w32 build
Date: Fri, 29 Aug 2014 22:41:58 +0300

> Date: Fri, 29 Aug 2014 11:08:21 -0400
> From: Ken Brown <kbrown <at> cornell.edu>
> CC: 18347 <at> debbugs.gnu.org
> 
> On 8/29/2014 2:25 AM, Eli Zaretskii wrote:
> >> Date: Thu, 28 Aug 2014 17:51:06 -0400
> >> From: Ken Brown <kbrown <at> cornell.edu>
> >>
> >> --- lisp/startup.el     2014-07-08 09:17:09 +0000
> >> +++ lisp/startup.el     2014-08-28 20:07:20 +0000
> >> @@ -1812,7 +1812,7 @@
> >>      (let (chosen-frame)
> >>        ;; MS-Windows needs this to have a chance to make the initial
> >>        ;; frame visible.
> >> -    (if (eq system-type 'windows-nt)
> >> +    (if (eq window-system 'w32)
> >>           (sit-for 0 t))
> >>        (dolist (frame (append (frame-list) (list (selected-frame))))
> >>          (if (and (frame-visible-p frame)
> >
> > It is fundamentally wrong to use window-system the variable in such
> > circumstances (or almost any other).  Please use the function instead.
> 
> OK.  But could you explain why?  TIA.

Because we don't want to risk assigning it a value.  Also, the
function can accept a frame argument, thus giving you a chance to
inquire about a specific frame (different frames can have different
window-system values).

And if you use window-system as a predicate (not in this case,
obviously), you should use the various display-*-p predicates instead.

> >> Is this still OK for the native Windows build?  If so, is it OK to
> >> install it in the release branch?
> >
> > Yes and yes.  Although I'd urge you to try to figure out why this is
> > needed in the cygwin-w32 build (the native-build problem which led to
> > this code manifested itself in a rather different way, see bug#16014).
> 
> Actually, the visual symptom I'm describing (failure of the logo to 
> appear) is identical to what Juanma reported in that bug.

OK, but that's not what your original description said.

> Your message in that bug discussion says, "It's again that timing
> thing with making the initial frame visible."  The "again" suggests
> that there is an earlier bug report or discussion about that.  Can
> you give me a reference or just explain what you meant by that?

Bug#14841, I think.

Basically, since creating a frame on w32 takes some time until the OS
sets up the message pump for the new frame, Lisp code that creates a
frame and immediately proceeds with manipulating the new frame might
sometimes need sit-for to let the dust settle.

Message #19 received at 18347-done <at> debbugs.gnu.org (full text, mbox):

From: Ken Brown <kbrown <at> cornell.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 18347-done <at> debbugs.gnu.org
Subject: Re: bug#18347: 24.3.93; Incomplete splash screen display on Cygwin-w32
 build
Date: Fri, 29 Aug 2014 18:17:18 -0400

Version: 24.3.94

> Basically, since creating a frame on w32 takes some time until the OS
> sets up the message pump for the new frame, Lisp code that creates a
> frame and immediately proceeds with manipulating the new frame might
> sometimes need sit-for to let the dust settle.

So it seems that the current bug probably has the same cause as 
bug#16014.  I've installed the fix (but using the window-system 
function) in the release branch as bzr revision 117465.

Ken

Previous Next

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