bug#14841: Frames created invisible have their visibility parameter set to t

bug#14841: Frames created invisible have their visibility parameter set to t

[Juanma Barranquero]

Package: emacs
Version: 20.7.3
X-Debbugs-CC: eliz@gnu.org


This is a very old bug, I see the same behavior since 20.7.3 (the
older binary I have) but it is likely there since the redisplay
rewriting in 20.1.

I don't know if this is Windows related. Could someone please test it
in a POSIX build?

Anyway, the bug: frames made invisible with set-frame-parameter,
modify-frame-parameters or make-frame-invisible have their visibility
parameter really set to nil. However, frames created already invisible
with (make-frame '((visibility . nil)), which *are* invisible, have
their visibility parameter set to t as soon as there's some redisplay.

ELISP> (setq f1 (make-frame '((visibility))))
#<frame emacs@ODIEONE 037b77e0>
ELISP> (frame-parameter f1 'visibility)
t
ELISP> (mapcar #'frame-visible-p (frame-list))
(t t)

ELISP> (make-frame-invisible f1)
nil
ELISP> (frame-parameter f1 'visibility)
nil
ELISP> (mapcar #'frame-visible-p (frame-list))
(nil t)

ELISP> (setq f2 (make-frame))
#<frame emacs@ODIEONE 0518b7d8>
ELISP> (set-frame-parameter f2 'visibility nil)
nil
ELISP> (frame-parameter f2 'visibility)
nil
ELISP> (mapcar #'frame-visible-p (frame-list))
(nil nil t)
ELISP> (let ((f3 (make-frame '((visibility)))))
         (frame-parameter f3 'visibility))
nil
ELISP> (mapcar #'frame-visible-p (frame-list))
(t nil nil t)

This could be related to this comment in frame.h

     On ttys and on Windows NT/9X, to avoid wasting effort updating
     visible frames that are actually completely obscured by other
     windows on the display, we bend the meaning of visible slightly:
     if equal to 2, then the frame is obscured - we still consider
     it to be "visible" as seen from lisp, but we don't bother
     updating it.  We must take care to garbage the frame when it
     ceases to be obscured though.  See SET_FRAME_VISIBLE below.  */
  unsigned visible : 2;

which would mean it is a Windows-specific display bug.

This affects the frame-restore functionality I'm testing, because many
frames are "restored" via (make-frame SOME-BIG-PARAMETER-LIST). I can
work around the bug by treating visibility specially, of course, but
still, it is a bug, because the affected frames are not "obscured",
they are invisible.

bug#14841: Frames created invisible have their visibility parameter set to t

[Eli Zaretskii]

> Cc: eliz@gnu.org
> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Thu, 11 Jul 2013 17:14:19 +0200
> 
> Anyway, the bug: frames made invisible with set-frame-parameter,
> modify-frame-parameters or make-frame-invisible have their visibility
> parameter really set to nil. However, frames created already invisible
> with (make-frame '((visibility . nil)), which *are* invisible, have
> their visibility parameter set to t as soon as there's some redisplay.
> [...]
> This could be related to this comment in frame.h
> 
>      On ttys and on Windows NT/9X, to avoid wasting effort updating
>      visible frames that are actually completely obscured by other
>      windows on the display, we bend the meaning of visible slightly:
>      if equal to 2, then the frame is obscured - we still consider
>      it to be "visible" as seen from lisp, but we don't bother
>      updating it.  We must take care to garbage the frame when it
>      ceases to be obscured though.  See SET_FRAME_VISIBLE below.  */
>   unsigned visible : 2;

I don't see how this is related to the bug you describe.  Can you
elaborate why you think it is?

bug#14841: Frames created invisible have their visibility parameter set to t

[Juanma Barranquero]

On Thu, Jul 11, 2013 at 5:33 PM, Eli Zaretskii <eliz@gnu.org> wrote:

>> This could be related to this comment in frame.h
>>
>>      On ttys and on Windows NT/9X, to avoid wasting effort updating
>>      visible frames that are actually completely obscured by other
>>      windows on the display, we bend the meaning of visible slightly:
>>      if equal to 2, then the frame is obscured - we still consider
>>      it to be "visible" as seen from lisp, but we don't bother
>>      updating it.  We must take care to garbage the frame when it
>>      ceases to be obscured though.  See SET_FRAME_VISIBLE below.  */
>>   unsigned visible : 2;

> I don't see how this is related to the bug you describe.  Can you
> elaborate why you think it is?

That's a trick question. I don't know, that's why I said "could be
related". Why did I think so? Because the comment clearly describes a
case where a frame is not "visible" (on the screen) and yet "visible"
(to lisp).

Also, because it does not seem a bug in make-frame (after make-frame,
the frame has visibility = nil as expected); it is only noticeable
after redisplay; or at least, after the command is finished, which
suggests that redisplay was likely triggered.

But I could be wrong, of course. It's known to happen every now and then ;-)

bug#14841: Frames created invisible have their visibility parameter set to t

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Thu, 11 Jul 2013 17:39:26 +0200
> Cc: 14841@debbugs.gnu.org
> 
> >>      On ttys and on Windows NT/9X, to avoid wasting effort updating
> >>      visible frames that are actually completely obscured by other
> >>      windows on the display, we bend the meaning of visible slightly:
> >>      if equal to 2, then the frame is obscured - we still consider
> >>      it to be "visible" as seen from lisp, but we don't bother
> >>      updating it.  We must take care to garbage the frame when it
> >>      ceases to be obscured though.  See SET_FRAME_VISIBLE below.  */
> >>   unsigned visible : 2;
> 
> > I don't see how this is related to the bug you describe.  Can you
> > elaborate why you think it is?
> 
> That's a trick question. I don't know, that's why I said "could be
> related". Why did I think so? Because the comment clearly describes a
> case where a frame is not "visible" (on the screen) and yet "visible"
> (to lisp).

But it doesn't say anything about frames created invisible.  It talks
about frames that are visible, but obscured.

> Also, because it does not seem a bug in make-frame (after make-frame,
> the frame has visibility = nil as expected); it is only noticeable
> after redisplay; or at least, after the command is finished, which
> suggests that redisplay was likely triggered.

Can you provide a recipe to reproduce this, starting with "emacs -Q"?

bug#14841: Frames created invisible have their visibility parameter set to t

[Juanma Barranquero]

On Thu, Jul 11, 2013 at 6:29 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> But it doesn't say anything about frames created invisible.  It talks
> about frames that are visible, but obscured.

Yes. The code that decides that a frame is "visible, but obscured"
could be interpreting a just created invisible frame as obscured.
That's what I though. Seems I was wrong.

> Can you provide a recipe to reproduce this, starting with "emacs -Q"?

My IELM example was from emacs -Q, but OK:

  emacs -Q
  M-: (make-frame '((visibility))) <RET>
  M-: (mapcar #'frame-visible-p (frame-list)) <RET>
  => (t t)
  M-: (make-frame-invisible (make-frame)) <RET>
  M-: (mapcar #'frame-visible-p (frame-list)) <RET>
  => (nil t t)
  M-: (setq f (make-frame)) <RET>

At this point, C-x 5 o does not take you to the previous frame.
Presumably, because Emacs gets confused that some previous frame,
which is invisible, is "visible" because its visibility parameter says
so. Then

  Select the initial frame.
  M-: (make-frame-invisible f) <RET>
  M-: (mapcar #'frame-visible-p (frame-list)) <RET>
  => (nil nil t t)

bug#14841: Frames created invisible have their visibility parameter set to t

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Thu, 11 Jul 2013 18:54:53 +0200
> Cc: 14841@debbugs.gnu.org
> 
>   emacs -Q
>   M-: (make-frame '((visibility))) <RET>
>   M-: (mapcar #'frame-visible-p (frame-list)) <RET>
>   => (t t)
>   M-: (make-frame-invisible (make-frame)) <RET>
>   M-: (mapcar #'frame-visible-p (frame-list)) <RET>
>   => (nil t t)
>   M-: (setq f (make-frame)) <RET>
> 
> At this point, C-x 5 o does not take you to the previous frame.
> Presumably, because Emacs gets confused that some previous frame,
> which is invisible, is "visible" because its visibility parameter says
> so. Then
> 
>   Select the initial frame.
>   M-: (make-frame-invisible f) <RET>
>   M-: (mapcar #'frame-visible-p (frame-list)) <RET>
>   => (nil nil t t)

I'm confused: what did you expect to happen instead?

bug#14841: Frames created invisible have their visibility parameter set to t

[Juanma Barranquero]

On Sun, Jul 14, 2013 at 6:52 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> I'm confused: what did you expect to happen instead?

After this, (nil t) instead of (t  t)

>>   emacs -Q
>>   M-: (make-frame '((visibility))) <RET>
>>   M-: (mapcar #'frame-visible-p (frame-list)) <RET>
>>   => (t t)

because:

 1) (make-frame '((visibility))) == (make-frame '((visibility . nil)))
 2) The frame *is* invisible
 3) If you do this instead:  M-: (progn (make-frame '((visibility)))
(mapcar #'frame-visible-p (frame-list))) <RET>, you get (nil t)

Is only after redisplay (I think), that the
just-created-invisible-frame becomes "visible" to elisp (though still
invisible to the user).

These first few lines in my report do show the bug; the rest of my
example was to explain how the alternative ways to make the frame
invisible didn't suffer the same problem.

HTH,

   J

bug#14841: Frames created invisible have their visibility parameter set to t

[Juanma Barranquero]

On Sun, Jul 14, 2013 at 7:02 PM, Juanma Barranquero <lekktu@gmail.com> wrote:

>  3) If you do this instead:  M-: (progn (make-frame '((visibility)))
> (mapcar #'frame-visible-p (frame-list))) <RET>, you get (nil t)

Curiously, this seem like two different bugs:

1) A frame created via (make-frame '((visibility . nil))) is
invisible, but elisp thinks it is visible.

2) frame-visible-p cannot be trusted until the frame has been
displayed, as shown by this different example:

ELISP> (progn (setq *f* (make-frame '((visibility . icon))))
(frame-visible-p *f*))
nil
ELISP> (frame-visible-p *f*)
icon

bug#14841: Frames created invisible have their visibility parameter set to t

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Fri, 19 Jul 2013 15:04:22 +0200
> Cc: 14841@debbugs.gnu.org
> 
> On Sun, Jul 14, 2013 at 7:02 PM, Juanma Barranquero <lekktu@gmail.com> wrote:
> 
> >  3) If you do this instead:  M-: (progn (make-frame '((visibility)))
> > (mapcar #'frame-visible-p (frame-list))) <RET>, you get (nil t)
> 
> Curiously, this seem like two different bugs:
> 
> 1) A frame created via (make-frame '((visibility . nil))) is
> invisible, but elisp thinks it is visible.

How do you see that?  The example below clearly says "nil", not "t".

> 2) frame-visible-p cannot be trusted until the frame has been
> displayed, as shown by this different example:
> 
> ELISP> (progn (setq *f* (make-frame '((visibility . icon))))
> (frame-visible-p *f*))
> nil
> ELISP> (frame-visible-p *f*)
> icon

I think this is to be expected (and unrelated to this bug).

bug#14841: Frames created invisible have their visibility parameter set to t

[Juanma Barranquero]

On Sat, Jul 20, 2013 at 2:56 PM, Eli Zaretskii <eliz@gnu.org> wrote:

>> 1) A frame created via (make-frame '((visibility . nil))) is
>> invisible, but elisp thinks it is visible.
>
> How do you see that?  The example below clearly says "nil", not "t".

I don't understand. This is exactly the original report:

emacs -Q
M-: (setq *f* (make-frame '((visibility . nil)))) <RET>
M-: (frame-visible-p *f*) <RET>
 => t


> I think this is to be expected (and unrelated to this bug).

I said "two different bugs", so yes, unrelated. As for being expected, why?

bug#14841: Frames created invisible have their visibility parameter set to t

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Sat, 20 Jul 2013 15:01:05 +0200
> Cc: 14841@debbugs.gnu.org
> 
> On Sat, Jul 20, 2013 at 2:56 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> >> 1) A frame created via (make-frame '((visibility . nil))) is
> >> invisible, but elisp thinks it is visible.
> >
> > How do you see that?  The example below clearly says "nil", not "t".
> 
> I don't understand. This is exactly the original report:
> 
> emacs -Q
> M-: (setq *f* (make-frame '((visibility . nil)))) <RET>
> M-: (frame-visible-p *f*) <RET>
>  => t

In your example, it said "nil", not "t":

  ELISP> (progn (setq *f* (make-frame '((visibility . icon))))
  (frame-visible-p *f*))
  nil

And that's what I get after the change mentioned previously.

> > I think this is to be expected (and unrelated to this bug).
> 
> I said "two different bugs", so yes, unrelated. As for being expected, why?

Because frame-visible-p makes no sense as long as the frame was not
displayed.  (In what sense is an un-displayed frame "visible"?)

bug#14841: Frames created invisible have their visibility parameter set to t

[Juanma Barranquero]

On Sat, Jul 20, 2013 at 3:39 PM, Eli Zaretskii <eliz@gnu.org> wrote:

>> emacs -Q
>> M-: (setq *f* (make-frame '((visibility . nil)))) <RET>
>> M-: (frame-visible-p *f*) <RET>
>>  => t
>
> In your example, it said "nil", not "t":
>
>   ELISP> (progn (setq *f* (make-frame '((visibility . icon))))
>   (frame-visible-p *f*))
>   nil
>
> And that's what I get after the change mentioned previously.

Allow me to recapitulate. Without your patch (that I haven't yet tested):

(1) M-: (progn (setq *f* (make-frame '((visibility . X))))
(frame-visible-p *f*)) <RET>
(2) M-: (frame-visible-p *f*) <RET>

 X      (1)   (2)
------ ----- ------
 t       t     t
 nil    nil    t
 icon   nil   icon

I think both the (1) and (2) columns show bugs.

In column (1), if t is the right value for visibility = t, because the
frame is already shown, and nil is the right value for visibility .
nil, because it is invisible, then the answer for visibility . icon
should be icon, because the frame is already iconified (and so,
"visible").

For column (2), the value t for visibility . nil is a bug, because the
frame is invisible.

> Because frame-visible-p makes no sense as long as the frame was not
> displayed.  (In what sense is an un-displayed frame "visible"?)

"Frame visibility" conflates two three things: whether and how the
user sees the frame, what does elisp think about the frame status, and
what the frame parameter of the frame says about its status. We use
frame-visible-p for the first two queries, or rather, for the second
one hoping that it matches the first one. If you disagree and think
that frame-visible-p should only answer the first query, then we need
a way to ask the second one, because sometimes you have to create a
frame and do things with it long before it is displayed ("long" in the
sense that many things happen between it being created and being
displayed). That's not a theoretical exercise, that's a bug that's
bitten me with desktop-restore-frames.

   J

bug#14841: Frames created invisible have their visibility parameter set to t

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Sat, 20 Jul 2013 16:54:05 +0200
> Cc: 14841@debbugs.gnu.org
> 
> (1) M-: (progn (setq *f* (make-frame '((visibility . X))))
> (frame-visible-p *f*)) <RET>
> (2) M-: (frame-visible-p *f*) <RET>
> 
>  X      (1)   (2)
> ------ ----- ------
>  t       t     t
>  nil    nil    t  <<<<<<<<< this is now nil
>  icon   nil   icon
> 
> I think both the (1) and (2) columns show bugs.

The last one seems like am artifact of how we implement iconified
frames on Windows.  I have no idea how to improve/fix that.

bug#14841: Frames created invisible have their visibility parameter set to t

[Eli Zaretskii]

> Date: Sat, 20 Jul 2013 18:48:32 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 14841@debbugs.gnu.org
> 
> >  X      (1)   (2)
> > ------ ----- ------
> >  t       t     t
> >  nil    nil    t  <<<<<<<<< this is now nil
> >  icon   nil   icon
> > 
> > I think both the (1) and (2) columns show bugs.
> 
> The last one seems like am artifact of how we implement iconified
> frames on Windows.  I have no idea how to improve/fix that.

Maybe like this:

=== modified file 'src/w32term.c'
--- src/w32term.c	2013-07-18 16:50:05 +0000
+++ src/w32term.c	2013-07-20 16:06:07 +0000
@@ -6129,6 +6131,9 @@ x_iconify_frame (struct frame *f)
   /* Simulate the user minimizing the frame.  */
   SendMessage (FRAME_W32_WINDOW (f), WM_SYSCOMMAND, SC_MINIMIZE, 0);
 
+  SET_FRAME_VISIBLE (f, 0);
+  SET_FRAME_ICONIFIED (f, 1);
+
   unblock_input ();
 }
 

bug#14841: Frames created invisible have their visibility parameter set to t

[Juanma Barranquero]

On Sat, Jul 20, 2013 at 6:09 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> Maybe like this:

> +  SET_FRAME_VISIBLE (f, 0);
> +  SET_FRAME_ICONIFIED (f, 1);

It certainly cures the symptom. I suggest you install it.

bug#14841: Frames created invisible have their visibility parameter set to t

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Sat, 20 Jul 2013 18:57:57 +0200
> Cc: 14841@debbugs.gnu.org
> 
> On Sat, Jul 20, 2013 at 6:09 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > Maybe like this:
> 
> > +  SET_FRAME_VISIBLE (f, 0);
> > +  SET_FRAME_ICONIFIED (f, 1);
> 
> It certainly cures the symptom. I suggest you install it.

I prefer waiting for a few days.  If I hear from you no new problems
were triggered by it, I will install it.

bug#14841: Frames created invisible have their visibility parameter set to t

[Juanma Barranquero]

On Sat, Jul 20, 2013 at 7:37 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> I prefer waiting for a few days.  If I hear from you no new problems
> were triggered by it, I will install it.

Do not install them yet, please. I had a problem with
modify-frame-parameters (I think; the symptom was duplicate frames in
desktop-restore-frames, which could be triggered by the frame reusing
code failing) that happens with these patches installed, but I haven't
yet had the time to check which one, or if it is a false alarm and the
problem is caused by other changes.

bug#14841: Frames created invisible have their visibility parameter set to t

[Juanma Barranquero]

On Sat, Jul 20, 2013 at 5:48 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>>  nil    nil    t  <<<<<<<<< this is now nil

Great.

> The last one seems like am artifact of how we implement iconified
> frames on Windows.  I have no idea how to improve/fix that.

Well, if we can agree that it is an unwanted behavior, I can file a
bug even if we're not going to fix it right now.

bug#14841: Frames created invisible have their visibility parameter set to t

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Sun, 14 Jul 2013 19:02:27 +0200
> Cc: 14841@debbugs.gnu.org
> 
> On Sun, Jul 14, 2013 at 6:52 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > I'm confused: what did you expect to happen instead?
> 
> After this, (nil t) instead of (t  t)
> 
> >>   emacs -Q
> >>   M-: (make-frame '((visibility))) <RET>
> >>   M-: (mapcar #'frame-visible-p (frame-list)) <RET>
> >>   => (t t)
> 
> because:
> 
>  1) (make-frame '((visibility))) == (make-frame '((visibility . nil)))
>  2) The frame *is* invisible
>  3) If you do this instead:  M-: (progn (make-frame '((visibility)))
> (mapcar #'frame-visible-p (frame-list))) <RET>, you get (nil t)

This happens because we get a WM_SIZE message, in response to which we
unconditionally set the frame as visible:

	case WM_SIZE:
	  f = x_window_to_frame (dpyinfo, msg.msg.hwnd);

	  /* Inform lisp of whether frame has been iconified etc. */
	  if (f)
	    {
	      switch (msg.msg.wParam)
		{
                ....
		case SIZE_MAXIMIZED:
		case SIZE_RESTORED:
		  {
		    bool iconified = FRAME_ICONIFIED_P (f);

		    SET_FRAME_VISIBLE (f, 1);   <<<<<<<<<<<<<<<<<<<<<
		    SET_FRAME_ICONIFIED (f, 0);

I'm out of my depth here, as I know close to nothing about the details
of these messages, and why are they sent to us, even though the frame
is created invisible.  But try the changes below for a few days, and
if they don't have any adverse effects, I will install them.

=== modified file 'src/w32term.c'
--- src/w32term.c	2013-07-18 16:50:05 +0000
+++ src/w32term.c	2013-07-20 12:41:06 +0000
@@ -4360,8 +4360,9 @@ w32_read_socket (struct terminal *termin
 		  SET_FRAME_VISIBLE (f, 1);
 		  SET_FRAME_ICONIFIED (f, 0);
 		  SET_FRAME_GARBAGED (f);
-		  DebPrint (("frame %p (%s) reexposed by WM_PAINT\n", f,
-			     SDATA (f->name)));
+		  if (!f->output_data.w32->asked_for_visible)
+		    DebPrint (("frame %p (%s) reexposed by WM_PAINT\n", f,
+			       SDATA (f->name)));
 
 		  /* WM_PAINT serves as MapNotify as well, so report
 		     visibility changes properly.  */
@@ -4819,7 +4820,8 @@ w32_read_socket (struct terminal *termin
 		  {
 		    bool iconified = FRAME_ICONIFIED_P (f);
 
-		    SET_FRAME_VISIBLE (f, 1);
+		    if (iconified)
+		      SET_FRAME_VISIBLE (f, 1);
 		    SET_FRAME_ICONIFIED (f, 0);
 
 		    /* wait_reading_process_output will notice this

bug#14841: Frames created invisible have their visibility parameter set to t

[Juanma Barranquero]

On Sat, Jul 20, 2013 at 2:53 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> But try the changes below for a few days, and
> if they don't have any adverse effects, I will install them.

OK. I'm hacking desktop.el right now, so the change will get a good testing.

I'll be back. Thanks,

   Juanma

bug#14841: Frames created invisible have their visibility parameter set to t

[Juanma Barranquero]

On Sat, Jul 20, 2013 at 2:53 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> I'm out of my depth here, as I know close to nothing about the details
> of these messages, and why are they sent to us, even though the frame
> is created invisible.  But try the changes below for a few days, and
> if they don't have any adverse effects, I will install them.

> -                 DebPrint (("frame %p (%s) reexposed by WM_PAINT\n", f,
> -                            SDATA (f->name)));
> +                 if (!f->output_data.w32->asked_for_visible)
> +                   DebPrint (("frame %p (%s) reexposed by WM_PAINT\n", f,
> +                              SDATA (f->name)));

> -                   SET_FRAME_VISIBLE (f, 1);
> +                   if (iconified)
> +                     SET_FRAME_VISIBLE (f, 1);

An easy to reproduce bug caused by this change:

 ;;; .emacs
 (let ((f (selected-frame)))
   (make-frame)
   (delete-frame f))
;;; .emacs ends here

 emacs

 =>

 Warning (initialization): An error occurred while loading
`c:/Devel/emacs/test/.emacs':

 error: Attempt to delete the sole visible or iconified frame

bug#14841: Frames created invisible have their visibility parameter set to t

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Wed, 24 Jul 2013 18:50:03 +0200
> Cc: 14841@debbugs.gnu.org
> 
> An easy to reproduce bug caused by this change:
> 
>  ;;; .emacs
>  (let ((f (selected-frame)))
>    (make-frame)
>    (delete-frame f))
> ;;; .emacs ends here
> 
>  emacs
> 
>  =>
> 
>  Warning (initialization): An error occurred while loading
> `c:/Devel/emacs/test/.emacs':
> 
>  error: Attempt to delete the sole visible or iconified frame

Is there a use case that fails like this and makes more sense than the
one you presented?  If not, I'd ignore this, as creating a frame in
.emacs just to delete it immediately afterwards makes no sense to me.

bug#14841: Frames created invisible have their visibility parameter set to t

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Wed, 24 Jul 2013 18:50:03 +0200
> Cc: 14841@debbugs.gnu.org
> 
>  ;;; .emacs
>  (let ((f (selected-frame)))
>    (make-frame)
>    (delete-frame f))
> ;;; .emacs ends here
> 
>  emacs
> 
>  =>
> 
>  Warning (initialization): An error occurred while loading
> `c:/Devel/emacs/test/.emacs':
> 
>  error: Attempt to delete the sole visible or iconified frame

Btw, this trivial modification will avoid the problem:

    (let ((f (selected-frame))
	  (f1 (make-frame)))
      (make-frame-visible f1)
      (delete-frame f))

as will this:

    (let ((f (selected-frame))
	  (f1 (make-frame)))
      (sit-for 0)
      (delete-frame f))

The problem here is that x-create-frame-with-faces does this:

  (setq parameters (x-handle-named-frame-geometry parameters))
  (let* ((params (copy-tree parameters))
	 (visibility-spec (assq 'visibility parameters))
	 (delayed-params '(foreground-color background-color font
			   border-color cursor-color mouse-color
			   visibility scroll-bar-foreground
			   scroll-bar-background))
	 frame success)
    (dolist (param delayed-params)
      (setq params (assq-delete-all param params)))
    (setq frame (x-create-frame `((visibility . nil) . ,params))) <<<<<<<<<
    (unwind-protect
	(progn
	  (x-setup-function-keys frame)
	  (x-handle-reverse-video frame parameters)
	  (frame-set-background-mode frame t)
	  (face-set-after-frame-default frame parameters)
	  (if (null visibility-spec)
	      (make-frame-visible frame)                            <<<<<<<
	    (modify-frame-parameters frame (list visibility-spec))) <<<<<<<

IOW, it first creates a frame that is invisible, and only then applies
the visibility spec.  So you must wait for the frame to come up before
you can delete the initial frame.

bug#14841: Frames created invisible have their visibility parameter set to t

[Juanma Barranquero]

On Thu, Jul 25, 2013 at 9:35 PM, Eli Zaretskii <eliz@gnu.org> wrote:


> Btw, this trivial modification will avoid the problem:
>
>     (let ((f (selected-frame))
>           (f1 (make-frame)))
>       (make-frame-visible f1)
>       (delete-frame f))

When desktop restores frames, it first creates the frames being
restored, and only then deletes the existing ones. And yet I see the
error.

> as will this:
>
>     (let ((f (selected-frame))
>           (f1 (make-frame)))
>       (sit-for 0)
>       (delete-frame f))

I can add a (sit-for 0). But then, we have exchanged one problem with
frames not being entirely up-to-date before redisplay with another
similar case.

> IOW, it first creates a frame that is invisible, and only then applies
> the visibility spec.  So you must wait for the frame to come up before
> you can delete the initial frame.

Yes, but this does not happen without your patch...

    J

bug#14841: Frames created invisible have their visibility parameter set to t

[Juanma Barranquero]

On Thu, Jul 25, 2013 at 10:17 PM, Juanma Barranquero <lekktu@gmail.com> wrote:

>> as will this:
>>
>>     (let ((f (selected-frame))
>>           (f1 (make-frame)))
>>       (sit-for 0)
>>       (delete-frame f))
>
> I can add a (sit-for 0).

Adding (sit-for 0 t) just before the frame-deletion loop fixes the
issue with your patch, and invisible frames do work as expected.

Thanks,

    Juanma

bug#14841: Frames created invisible have their visibility parameter set to t

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Fri, 26 Jul 2013 02:11:05 +0200
> Cc: 14841@debbugs.gnu.org
> 
> Adding (sit-for 0 t) just before the frame-deletion loop fixes the
> issue with your patch, and invisible frames do work as expected.

So can we decide that the patch can be committed?

Thanks.

bug#14841: Frames created invisible have their visibility parameter set to t

[Juanma Barranquero]

On Fri, Jul 26, 2013 at 8:32 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> So can we decide that the patch can be committed?

Yes, go ahead, please.

   J

bug#14841: Frames created invisible have their visibility parameter set to t

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Fri, 26 Jul 2013 11:37:46 +0200
> Cc: 14841@debbugs.gnu.org
> 
> On Fri, Jul 26, 2013 at 8:32 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > So can we decide that the patch can be committed?
> 
> Yes, go ahead, please.

Done as trunk revision 113555.

bug#14841: Frames created invisible have their visibility parameter set to t

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Fri, 26 Jul 2013 11:37:46 +0200
> Cc: 14841@debbugs.gnu.org
> 
> On Fri, Jul 26, 2013 at 8:32 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > So can we decide that the patch can be committed?
> 
> Yes, go ahead, please.

Done as trunk revision 113555.

Closing.

bug#14841: Frames created invisible have their visibility parameter set to t

[martin rudalics]

 > Done as trunk revision 113555.

Apparently this breaks my longstanding .emacs idiosyncrasy

(add-hook 'window-setup-hook
	  (lambda ()
	    ;; Maximize frame.
	    (w32-send-sys-command 61488)))

stopping it to maximize my initial frame.

Any ideas for a workaround?

Thanks, martin

bug#14841: Frames created invisible have their visibility parameter set to t

[Eli Zaretskii]

> Date: Sat, 27 Jul 2013 14:43:02 +0200
> From: martin rudalics <rudalics@gmx.at>
> 
>  > Done as trunk revision 113555.
> 
> Apparently this breaks my longstanding .emacs idiosyncrasy
> 
> (add-hook 'window-setup-hook
> 	  (lambda ()
> 	    ;; Maximize frame.
> 	    (w32-send-sys-command 61488)))
> 
> stopping it to maximize my initial frame.
> 
> Any ideas for a workaround?

Add '(fullscreen . fullboth) to initial-frame-alist, as God intended?
There's no longer a need to use window-setup-hook for this on the
trunk.

bug#14841: Frames created invisible have their visibility parameter set to t

[martin rudalics]

 > Add '(fullscreen . fullboth) to initial-frame-alist, as God intended?

'(fullscreen . maximized) seems to work.

 > There's no longer a need to use window-setup-hook for this on the
 > trunk.

My .emacs has to work for older versions too ;-)

Thanks for the advice, martin

bug#14841: Frames created invisible have their visibility parameter set to t

[Eli Zaretskii]

> Date: Sat, 27 Jul 2013 15:30:36 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 14841@debbugs.gnu.org, lekktu@gmail.com
> 
>  > Add '(fullscreen . fullboth) to initial-frame-alist, as God intended?
> 
> '(fullscreen . maximized) seems to work.
> 
>  > There's no longer a need to use window-setup-hook for this on the
>  > trunk.
> 
> My .emacs has to work for older versions too ;-)

Then use the old way with older versions.

bug#14841: Frames created invisible have their visibility parameter set to t

[martin rudalics]

 > Then use the old way with older versions.

I obviously do that now.  But I still wonder whether a user can have her
desktop link to runemacs.exe have it run in a maximized window.  Here on
Windows XP this seems (no longer?) possible.

martin

bug#14841: Frames created invisible have their visibility parameter set to t

[Eli Zaretskii]

> Date: Sun, 28 Jul 2013 10:40:04 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 14841@debbugs.gnu.org, lekktu@gmail.com
> 
> I still wonder whether a user can have her desktop link to
> runemacs.exe have it run in a maximized window.  Here on Windows XP
> this seems (no longer?) possible.

How about using -mm or -fs option in the Target property of the
Shortcut Properties of the desktop icon?

You cannot do this via the "Run: Maximized" property, since emacs.exe
is a console program, and therefore its only window runemacs can
control is the console window (which it hides, that being the very
purpose of runemacs's existence).

bug#14841: Frames created invisible have their visibility parameter set to t

[martin rudalics]

 >> I still wonder whether a user can have her desktop link to
 >> runemacs.exe have it run in a maximized window.  Here on Windows XP
 >> this seems (no longer?) possible.
 >
 > How about using -mm or -fs option in the Target property of the
 > Shortcut Properties of the desktop icon?

-mm is only an approximation of maximizing since it doesn't hide the
window borders.  Apart from that it should work.

 > You cannot do this via the "Run: Maximized" property, since emacs.exe
 > is a console program, and therefore its only window runemacs can
 > control is the console window (which it hides, that being the very
 > purpose of runemacs's existence).

So it apparently never worked and that's why I used the
`w32-send-sys-command' solution.  Seems the correct solution is to have
runemacs pass the size of the console window to emacs.

martin

bug#14841: Frames created invisible have their visibility parameter set to t

[Eli Zaretskii]

> Date: Mon, 29 Jul 2013 09:54:52 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 14841@debbugs.gnu.org, lekktu@gmail.com
> 
>  >> I still wonder whether a user can have her desktop link to
>  >> runemacs.exe have it run in a maximized window.  Here on Windows XP
>  >> this seems (no longer?) possible.
>  >
>  > How about using -mm or -fs option in the Target property of the
>  > Shortcut Properties of the desktop icon?
> 
> -mm is only an approximation of maximizing since it doesn't hide the
> window borders.

It should do exactly what (fullscreen . maximized) frame parameter
does, so I guess you are already used to the above issue?

>  > You cannot do this via the "Run: Maximized" property, since emacs.exe
>  > is a console program, and therefore its only window runemacs can
>  > control is the console window (which it hides, that being the very
>  > purpose of runemacs's existence).
> 
> So it apparently never worked and that's why I used the
> `w32-send-sys-command' solution.  Seems the correct solution is to have
> runemacs pass the size of the console window to emacs.

You mean, the solution is for emacs to _take_ the dimensions of its
frame from its console window, yes?  Because without that, runemacs
can pass whatever it wants, and no one will notice.

Assuming the above is possible (having the window both hidden _and_
maximized), patches are welcome.

bug#14841: Frames created invisible have their visibility parameter set to t

[martin rudalics]

 >> -mm is only an approximation of maximizing since it doesn't hide the
 >> window borders.
 >
 > It should do exactly what (fullscreen . maximized) frame parameter
 > does, so I guess you are already used to the above issue?

For some reason, using -mm gives me a frame _with_ outer borders while
adding (fullscreen . maximized) to `initial-frame-alist' gets me a frame
_without_ outer borders.  What do you get?

 > You mean, the solution is for emacs to _take_ the dimensions of its
 > frame from its console window, yes?  Because without that, runemacs
 > can pass whatever it wants, and no one will notice.

Indeed.  That's the wording I should have used.

 > Assuming the above is possible (having the window both hidden _and_
 > maximized), patches are welcome.

On the Web you can find a quite remarkable number of proposals how to
get an initially maximized frame (not only on Windows, IIUC).  So I
think that we should provide a canonical solution.

martin

bug#14841: Frames created invisible have their visibility parameter set to t

[Eli Zaretskii]

> Date: Mon, 29 Jul 2013 18:58:47 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 14841@debbugs.gnu.org, lekktu@gmail.com
> 
>  >> -mm is only an approximation of maximizing since it doesn't hide the
>  >> window borders.
>  >
>  > It should do exactly what (fullscreen . maximized) frame parameter
>  > does, so I guess you are already used to the above issue?
> 
> For some reason, using -mm gives me a frame _with_ outer borders while
> adding (fullscreen . maximized) to `initial-frame-alist' gets me a frame
> _without_ outer borders.  What do you get?

I get the same effect with both, which is a frame _with_ outer
borders.  But this is XP, and I think I saw a frame without borders on
Windows 7.  Will check.

>  > Assuming the above is possible (having the window both hidden _and_
>  > maximized), patches are welcome.
> 
> On the Web you can find a quite remarkable number of proposals how to
> get an initially maximized frame (not only on Windows, IIUC).

Maximized _and_ hidden?  Any pointers?

bug#14841: Frames created invisible have their visibility parameter set to t

[martin rudalics]

 >> For some reason, using -mm gives me a frame _with_ outer borders while
 >> adding (fullscreen . maximized) to `initial-frame-alist' gets me a frame
 >> _without_ outer borders.  What do you get?
 >
 > I get the same effect with both, which is a frame _with_ outer
 > borders.  But this is XP, and I think I saw a frame without borders on
 > Windows 7.  Will check.

I'm on XP and I've never seen another application that shows the sizing
borders for a maximized window.  Do you?

 >> On the Web you can find a quite remarkable number of proposals how to
 >> get an initially maximized frame (not only on Windows, IIUC).
 >
 > Maximized _and_ hidden?  Any pointers?

Just maximized.

martin

bug#14841: Frames created invisible have their visibility parameter set to t

[Eli Zaretskii]

> Date: Tue, 30 Jul 2013 11:12:22 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 14841@debbugs.gnu.org, lekktu@gmail.com
> 
>  >> For some reason, using -mm gives me a frame _with_ outer borders while
>  >> adding (fullscreen . maximized) to `initial-frame-alist' gets me a frame
>  >> _without_ outer borders.  What do you get?
>  >
>  > I get the same effect with both, which is a frame _with_ outer
>  > borders.  But this is XP, and I think I saw a frame without borders on
>  > Windows 7.  Will check.
> 
> I'm on XP and I've never seen another application that shows the sizing
> borders for a maximized window.  Do you?

I think what you call "maximized" for other applications, Emacs calls
"fullboth".

bug#14841: Frames created invisible have their visibility parameter set to t

[martin rudalics]

 > I think what you call "maximized" for other applications, Emacs calls
 > "fullboth".

No.  "fullboth" gets me a frame with no decorations, no title bar and no
sizing borders.  That's the usual F11 behavior with other applications
and is handled as such by Emacs here.

 From http://msdn.microsoft.com/en-us/library/windows/desktop/ms632599%28v=vs.85%29.aspx#min_max

    A maximized window is a window that has the WS_MAXIMIZE style. By
    default, the system enlarges a maximized window so that it fills the
    screen or, in the case of a child window, the parent window's client
    area. Although a window's size can be set to the same size of a
    maximized window, a maximized window is slightly different. The
    system automatically moves the window's title bar to the top of the
    screen or to the top of the parent window's client area. Also, the
    system disables the window's sizing border and the window-positioning
    capability of the title bar (so that the user cannot move the window
    by dragging the title bar).

This is how applications like Firefox and Thunderbird maximize windows
here.

martin

bug#14841: Frames created invisible have their visibility parameter set to t

[martin rudalics]

 >> For some reason, using -mm gives me a frame _with_ outer borders while
 >> adding (fullscreen . maximized) to `initial-frame-alist' gets me a frame
 >> _without_ outer borders.  What do you get?
 >
 > I get the same effect with both, which is a frame _with_ outer
 > borders.  But this is XP, and I think I saw a frame without borders on
 > Windows 7.  Will check.

The reason why I'm getting a maximized frame is that I still have

	    (w32-send-sys-command 61488)))

in my .emacs which, in connection with the `initial-frame-alist' setting
gets me a maximized frame.  Without that I'm getting a frame with sizing
borders and the maximize button enabled.  This means that (fullscreen
. maximized) or -mm produce a normal frame that just happens to have the
size of a maximized frame.

I suppose I now also understand the problems Juanma and Angelo (IIRC)
described.  The only way toget a maximized frame on Windows
programmatically seems still to use (w32-send-sys-command 61488).

martin

bug#14841: Frames created invisible have their visibility parameter set to t

[Eli Zaretskii]

> Date: Tue, 30 Jul 2013 16:11:46 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 14841@debbugs.gnu.org, lekktu@gmail.com
> 
> I suppose I now also understand the problems Juanma and Angelo (IIRC)
> described.  The only way toget a maximized frame on Windows
> programmatically seems still to use (w32-send-sys-command 61488).

Sounds like a bug: Emacs previously did the equivalent of the above
when a full-screen frame was requested, but that was changed recently.

bug#14841: Frames created invisible have their visibility parameter set to t

[martin rudalics]

 > Sounds like a bug: Emacs previously did the equivalent of the above
 > when a full-screen frame was requested, but that was changed recently.

The patch below fixes it for me.

martin


=== modified file 'src/w32term.c'
--- src/w32term.c	2013-07-30 05:56:18 +0000
+++ src/w32term.c	2013-07-31 08:11:24 +0000
@@ -5717,7 +5717,9 @@
        w32_fullscreen_rect (hwnd, f->want_fullscreen,
                             FRAME_NORMAL_PLACEMENT (f).rcNormalPosition, &rect);
        FRAME_PREV_FSMODE (f) = f->want_fullscreen;
-      if (f->want_fullscreen == FULLSCREEN_BOTH)
+      if (f->want_fullscreen == FULLSCREEN_MAXIMIZED)
+	PostMessage (FRAME_W32_WINDOW (f), WM_SYSCOMMAND, 0xf030, 0);
+      else if (f->want_fullscreen == FULLSCREEN_BOTH)
          {
            SetWindowLong (hwnd, GWL_STYLE, dwStyle & ~WS_OVERLAPPEDWINDOW);
            SetWindowPos (hwnd, HWND_TOP, rect.left, rect.top,

bug#14841: Frames created invisible have their visibility parameter set to t

[martin rudalics]

> The patch below fixes it for me.

Any objections to install?

martin

bug#14841: Frames created invisible have their visibility parameter set to t

[Juanma Barranquero]

>> > So can we decide that the patch can be committed?
>>
>> Yes, go ahead, please.
>
> Done as trunk revision 113555.

Unfortunately, this patch causes another bug that I didn't detect at the time.

  emacs -Q --eval "(setq initial-frame-alist '((minibuffer)))" -f
toggle-debug-on-quit

Not always, but in most cases this will loop. Interrupting with Ctrl-G
produces this backtrace:

Debugger entered--Lisp error: (quit)
  sleep-for(1)
  frame-notice-user-settings()
  #[0 "\306 ... "]()
  funcall(#[0 "\306 ... "])
  normal-top-level()

bug#14841: Frames created invisible have their visibility parameter set to t

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Mon, 29 Jul 2013 00:08:52 +0200
> Cc: 14841@debbugs.gnu.org
> 
> >> > So can we decide that the patch can be committed?
> >>
> >> Yes, go ahead, please.
> >
> > Done as trunk revision 113555.
> 
> Unfortunately, this patch causes another bug that I didn't detect at the time.
> 
>   emacs -Q --eval "(setq initial-frame-alist '((minibuffer)))" -f
> toggle-debug-on-quit
> 
> Not always, but in most cases this will loop. Interrupting with Ctrl-G
> produces this backtrace:
> 
> Debugger entered--Lisp error: (quit)
>   sleep-for(1)
>   frame-notice-user-settings()
>   #[0 "\306 ... "]()
>   funcall(#[0 "\306 ... "])
>   normal-top-level()

It's the same problem as the previous one, and is solved in the same
way.  Please try the latest trunk.

bug#14841: Frames created invisible have their visibility parameter set to t

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Thu, 25 Jul 2013 22:17:19 +0200
> Cc: 14841@debbugs.gnu.org
> 
> >     (let ((f (selected-frame))
> >           (f1 (make-frame)))
> >       (sit-for 0)
> >       (delete-frame f))
> 
> I can add a (sit-for 0). But then, we have exchanged one problem with
> frames not being entirely up-to-date before redisplay with another
> similar case.

I don't think it's similar.  In the above, we simply wait for the
frame to become _really_ live when the window manager does its thing.

> > IOW, it first creates a frame that is invisible, and only then applies
> > the visibility spec.  So you must wait for the frame to come up before
> > you can delete the initial frame.
> 
> Yes, but this does not happen without your patch...

But my patch solves another problem...

bug#14841: Frames created invisible have their visibility parameter set to t

[Juanma Barranquero]

On Fri, Jul 26, 2013 at 8:31 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> But my patch solves another problem...

True enough.

bug#14841: Frames created invisible have their visibility parameter set to t

[Glenn Morris]

Juanma Barranquero wrote:

> I don't know if this is Windows related. Could someone please test it
> in a POSIX build?

Not reproducible in GNU/Linux w. XFCE 4.8, 24.3 or trunk, Gtk2 or Lucid
toolkits.

bug#14841: Frames created invisible have their visibility parameter set to t

[Juanma Barranquero]

On Thu, Jul 11, 2013 at 6:54 PM, Glenn Morris <rgm@gnu.org> wrote:

> Not reproducible in GNU/Linux w. XFCE 4.8, 24.3 or trunk, Gtk2 or Lucid
> toolkits.

So it is Windows-specific. Thanks.