bug#16923: 24.3.50; reression: `set-frame-size' loses mode line

bug#16923: 24.3.50; reression: `set-frame-size' loses mode line

[Drew Adams]

I've been looking at this regression for a while now. I've tried to
investigate.  I just spent a couple of days on it, without success.

The symptom, with my setup (and it is not clear just which parts of that
setup are minimally required to repro the bug), is this:

When `set-frame-size' is called for the current frame (it doesn't matter
what the WIDTH and HEIGHT args are, and PIXELWISE is nil) in some Info
nodes (I see the problem only in Info nodes, and not most of them), the
mode line disappears altogether.

That is, in place of the mode line I see only blank space with the same
color as the frame background.  The space seems to be there for a mode
line, but none is shown.

Forcing redisplay using C-l or M-: (force-mode-line-update 'all) has no
effect.  But calling `set-frame-size' (e.g., using `M-:') can bring
back the mode line.  It does not do so if I call it with the same width
and height (a no-op in terms of size change):

(set-frame-size nil
                (frame-parameter nil 'width)
                (frame-parameter nil 'height))

But it does do so if I use a width or height that is even slightly
different from the current value, e.g.:

(set-frame-size nil
                (1+ (frame-parameter nil 'width))
                (frame-parameter nil 'height))

I'm guessing that perhaps the Emacs code detects that there is no
size change and so does nothing.  And not that the particular size
where no mode line is shown is somehow problematic.

Support for that guess comes also from the fact that if I thumbify
and then dethumbify the frame, which changes its size and other
parameters and then changing them back to what they were, also restores
the mode line. IOW, the frame is shown with the same width and height
parameters (and other parameters the same also), and with the mode line
present.

I was able to narrow down the time frame when this regression was
introduced: This build, from 2013-12-14 does not have the regression:

In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2013-12-14 on ODIEONE
Bzr revision: 115521 rudalics@gmx.at-20131214110600-euy4wbseyg78zh72
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/Devel/emacs/binary --enable-checking=yes,glyphs
 'CFLAGS=-O0 -g3' LDFLAGS=-Lc:/Devel/emacs/lib
 CPPFLAGS=-Ic:/Devel/emacs/include'

And this build, from 2013-12-16 has the regression (as do all subsequent
builds):

In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2013-12-16 on ODIEONE
Bzr revision: 115543 rudalics@gmx.at-20131216095844-lbjh5yerk6ff0tm7
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/Devel/emacs/binary --enable-checking=yes,glyphs
 'CFLAGS=-O0 -g3' LDFLAGS=-Lc:/Devel/emacs/lib
 CPPFLAGS=-Ic:/Devel/emacs/include'

I am sorry that I cannot provide more info, at least at this point.  I
have spent a *lot* of time trying to debug this already.  At this point
I am hoping that something in the info above will prove helpful.

I do not expect that you will be able to repro this easily, but perhaps
something above will ring a bell for you.  It is lucky, at least, that
the build window here is so short: two days.  I tried looking through
some of the development changes during that 2-day period, but I was not
successful in finding what might be the culprit.


In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2014-02-28 on ODIEONE
Bzr revision: 116606 rudalics@gmx.at-20140228091055-seve9n9l9hg8dn2j
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/Devel/emacs/binary --enable-checking=yes,glyphs
 'CFLAGS=-O0 -g3' LDFLAGS=-Lc:/Devel/emacs/lib
 CPPFLAGS=-Ic:/Devel/emacs/include'

bug#16923: 24.3.50; reression: `set-frame-size' loses mode line

[Eli Zaretskii]

> Date: Sun, 2 Mar 2014 12:05:17 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> 
> When `set-frame-size' is called for the current frame (it doesn't matter
> what the WIDTH and HEIGHT args are, and PIXELWISE is nil) in some Info
> nodes (I see the problem only in Info nodes, and not most of them), the
> mode line disappears altogether.

Does the problem go away if you set Info-use-header-line to nil?

bug#16923: 24.3.50; reression: `set-frame-size' loses mode line

[Drew Adams]

> > When `set-frame-size' is called for the current frame (it doesn't matter
> > what the WIDTH and HEIGHT args are, and PIXELWISE is nil) in some Info
> > nodes (I see the problem only in Info nodes, and not most of them), the
> > mode line disappears altogether.
> 
> Does the problem go away if you set Info-use-header-line to nil?

No.  But part of my setup involves info+.el.  That hooks in the
automatic frame resizing.  It does not do anything special with
`Info-use-header-line', however - does just what vanilla `info.el'
does with it.

bug#16923: 24.3.50; reression: `set-frame-size' loses mode line

[martin rudalics]

 > I was able to narrow down the time frame when this regression was
 > introduced: This build, from 2013-12-14 does not have the regression:
 >
 > In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 >  of 2013-12-14 on ODIEONE
 > Bzr revision: 115521 rudalics@gmx.at-20131214110600-euy4wbseyg78zh72
 > Windowing system distributor `Microsoft Corp.', version 6.1.7601
 > Configured using:
 >  `configure --prefix=/c/Devel/emacs/binary --enable-checking=yes,glyphs
 >  'CFLAGS=-O0 -g3' LDFLAGS=-Lc:/Devel/emacs/lib
 >  CPPFLAGS=-Ic:/Devel/emacs/include'
 >
 > And this build, from 2013-12-16 has the regression (as do all subsequent
 > builds):
 >
 > In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 >  of 2013-12-16 on ODIEONE
 > Bzr revision: 115543 rudalics@gmx.at-20131216095844-lbjh5yerk6ff0tm7
 > Windowing system distributor `Microsoft Corp.', version 6.1.7601
 > Configured using:
 >  `configure --prefix=/c/Devel/emacs/binary --enable-checking=yes,glyphs
 >  'CFLAGS=-O0 -g3' LDFLAGS=-Lc:/Devel/emacs/lib
 >  CPPFLAGS=-Ic:/Devel/emacs/include'

So I suppose that the regression is already here if in the build from
2013-12-14 you set `w32-enable-frame-resize-hack' to t.

If this is the case then we are back at the subject of the Windows-only
bugs 1348 and 16028.

martin

bug#16923: 24.3.50; reression: `set-frame-size' loses mode line

[Drew Adams]

> I suppose that the regression is already here if in the build from
> 2013-12-14 you set `w32-enable-frame-resize-hack' to t.

Bingo!  Thank you, Martin.  I had completely forgotten about that
variable.

So it seems that with the code after 2013-12-14 a nil value has
the same effect as a non-nil value (?).  Is there anything I can
set now, to fix or work around this problem?

> If this is the case then we are back at the subject of the
> Windows-only bugs 1348 and 16028.

bug#16923: 24.3.50; reression: `set-frame-size' loses mode line

[Eli Zaretskii]

> Date: Mon, 03 Mar 2014 09:29:16 +0100
> From: martin rudalics <rudalics@gmx.at>
> Cc: 16923@debbugs.gnu.org
> 
> So I suppose that the regression is already here if in the build from
> 2013-12-14 you set `w32-enable-frame-resize-hack' to t.
> 
> If this is the case then we are back at the subject of the Windows-only
> bugs 1348 and 16028.

Only if you are thinking of reverting that change.  I'd rather we
tried to fix this regression without re-introducing the old ones.

bug#16923: 24.3.50; reression: `set-frame-size' loses mode line

[martin rudalics]

 > So it seems that with the code after 2013-12-14 a nil value has
 > the same effect as a non-nil value (?).

No.  The only difference is that the default value has changed.

 > Is there anything I can
 > set now, to fix or work around this problem?

Hardly.  If you set this to nil you will experience the earlier problem
with your thumbnail frames.

But you could make sure that (1) the bug is here with 2013-12-14 when
you set `w32-enable-frame-resize-hack' to t and (2) the bug is not here
with 2013-12-16 when you set `w32-enable-frame-resize-hack' to nil

BTW: Does Info still display a header line when the mode line is lost?

martin

bug#16923: 24.3.50; reression: `set-frame-size' loses mode line

[Drew Adams]

>  > So it seems that with the code after 2013-12-14 a nil value has
>  > the same effect as a non-nil value (?).
> 
> No.  The only difference is that the default value has changed.

I meant wrt this latest reported problem.  Neither t nor nil fixes that.

>  > Is there anything I can set now, to fix or work around this problem?
> 
> Hardly.  If you set this to nil you will experience the earlier problem
> with your thumbnail frames.
> 
> But you could make sure that (1) the bug is here with 2013-12-14 when
> you set `w32-enable-frame-resize-hack' to t and (2) the bug is not here
> with 2013-12-16 when you set `w32-enable-frame-resize-hack' to nil

Not sure what you mean. Which bug, the thumbnail frame problem or the
current problem?  Please clarify what you would like me to try/test.
 
> BTW: Does Info still display a header line when the mode line is lost?

Yes.

bug#16923: 24.3.50; reression: `set-frame-size' loses mode line

[martin rudalics]

 >>  > So it seems that with the code after 2013-12-14 a nil value has
 >>  > the same effect as a non-nil value (?).
 >>
 >> No.  The only difference is that the default value has changed.
 >
 > I meant wrt this latest reported problem.  Neither t nor nil fixes that.

That seems to contradict my guess.

 >> But you could make sure that (1) the bug is here with 2013-12-14 when
 >> you set `w32-enable-frame-resize-hack' to t and (2) the bug is not here
 >> with 2013-12-16 when you set `w32-enable-frame-resize-hack' to nil
 >
 > Not sure what you mean. Which bug, the thumbnail frame problem or the
 > current problem?  Please clarify what you would like me to try/test.

The current mode line problem.  Please try once more.  If setting this
variable doesn't change anything, it can't be the cause and we have to
look elsewhere.

 >> BTW: Does Info still display a header line when the mode line is lost?
 >
 > Yes.

Strange.

martin

bug#16923: 24.3.50; reression: `set-frame-size' loses mode line

[Drew Adams]

>  >>  > So it seems that with the code after 2013-12-14 a nil value has
>  >>  > the same effect as a non-nil value (?).
>  >>
>  >> No.  The only difference is that the default value has changed.
>  >
>  > I meant wrt this latest reported problem.  Neither t nor nil fixes that.
> 
> That seems to contradict my guess.

I'm sorry; my bad.  Setting it to nil fixes this problem but brings back
the thumbnail frame problem (which is much more important for me).

>  >> But you could make sure that (1) the bug is here with 2013-12-14 when
>  >> you set `w32-enable-frame-resize-hack' to t and (2) the bug is not here
>  >> with 2013-12-16 when you set `w32-enable-frame-resize-hack' to nil
>  >
>  > Not sure what you mean. Which bug, the thumbnail frame problem or the
>  > current problem?  Please clarify what you would like me to try/test.
> 
> The current mode line problem.  Please try once more.  If setting this
> variable doesn't change anything, it can't be the cause and we have to
> look elsewhere.

I thought I already answered that.  Anyway, yes: if I set the var to t
in the 2013-12-14 build then I get the mode-line problem.  And if I set
it to nil in the 2013-12-16 build then that prevents the mode-line problem.

>  >> BTW: Does Info still display a header line when the mode line is lost?
>  >
>  > Yes.
> 
> Strange.

I can reconfirm that this is the case, however strange it may seem.
But this might be because of differences due to info+.el.  What is the
reason that you expect the header line to be lost along with the mode
line?

bug#16923: 24.3.50; reression: `set-frame-size' loses mode line

[martin rudalics]

 > I can reconfirm that this is the case, however strange it may seem.
 > But this might be because of differences due to info+.el.  What is the
 > reason that you expect the header line to be lost along with the mode
 > line?

Because the header line gets drawn immediately after the mode line.  Are
you displaying something special in the mode line?  Maybe you can try to
display the same string in the header line too and see whether it fails
displaying/updating as well.

martin

bug#16923: 24.3.50; reression: `set-frame-size' loses mode line

[Drew Adams]

>  > I can reconfirm that this is the case, however strange it may seem.
>  > But this might be because of differences due to info+.el.  What is the
>  > reason that you expect the header line to be lost along with the mode
>  > line?
> 
> Because the header line gets drawn immediately after the mode line.  Are
> you displaying something special in the mode line?  Maybe you can try to
> display the same string in the header line too and see whether it fails
> displaying/updating as well.

Yes, by default I put the breadcrumbs in the mode line.  However, turning
this off (and so restoring the usual mode line for Info) does not change
things: the header line is still visible even when the mode line disappears.
The header line has never disappeared.  (And I do not change the Info header
line.)

bug#16923: 24.3.50; reression: `set-frame-size' loses mode line

[martin rudalics]

 > Yes, by default I put the breadcrumbs in the mode line.  However, turning
 > this off (and so restoring the usual mode line for Info) does not change
 > things: the header line is still visible even when the mode line disappears.
 > The header line has never disappeared.  (And I do not change the Info header
 > line.)

Does the problem appear when you make a new frame or when you resize an
existing one that was already visible before?  Is it a standalone frame
without minibuffer?  What happens when you split the frame or give it
its own minibuffer window?  Does the modeline reappear when you change
to another Info node?

martin

bug#16923: 24.3.50; reression: `set-frame-size' loses mode line

[Drew Adams]

>  > Yes, by default I put the breadcrumbs in the mode line.  However, turning
>  > this off (and so restoring the usual mode line for Info) does not change
>  > things: the header line is still visible even when the mode line
>  > disappears.  The header line has never disappeared.  (And I do not
>  > change the Info header line.)
> 
> Does the problem appear when you make a new frame or when you resize an
> existing one that was already visible before?  Is it a standalone frame
> without minibuffer?  What happens when you split the frame or give it
> its own minibuffer window?  Does the modeline reappear when you change
> to another Info node?

The Info frame already exists. It has no minibuffer, and it shows only
buffer *info*.

If I split the window in the frame then there is no problem, but
for the simple reason that no frame fitting is done (no call to
`set-frame-size').

I tried to give the (single-window) frame a minibuffer but was
unsuccessful. I tried both
M-: (set-frame-parameter nil 'minibuffer t) and
M-: (modify-frame-parameters nil '((minibuffer . t))).

Neither had any effect: the value of parameter `minibuffer' remained
nil.  (Am I missing something here?  Is that another bug?)

bug#16923: 24.3.50; reression: `set-frame-size' loses mode line

[Juanma Barranquero]

On Wed, Mar 5, 2014 at 4:43 PM, Drew Adams <drew.adams@oracle.com> wrote:

> I tried to give the (single-window) frame a minibuffer but was
> unsuccessful. I tried both
> M-: (set-frame-parameter nil 'minibuffer t) and
> M-: (modify-frame-parameters nil '((minibuffer . t))).
>
> Neither had any effect: the value of parameter `minibuffer' remained
> nil.  (Am I missing something here?  Is that another bug?)

AFAIK, you cannot change a frame's minibuffer state once it has been
created. It's not very clearly documented, or I couldn't find it, but
at least info node "(elisp)Minibuffers and Frames" tells

     However, you can also create a frame with no minibuffer.  Such a
  frame must use the minibuffer window of some other frame.  When you
  create the frame, you can explicitly specify the minibuffer window to
  use (in some other frame).  If you don't, then the minibuffer is found
  in the frame which is the value of the variable
  `default-minibuffer-frame'.  Its value should be a frame that does have
  a minibuffer.

and no reference is done to changing it afterwards.

bug#16923: 24.3.50; reression: `set-frame-size' loses mode line

[martin rudalics]

 > The Info frame already exists. It has no minibuffer, and it shows only
 > buffer *info*.

And it has a mode line and you switch to another Info node and you want
to adjust the frame to the size of its page but in fact the page size
did not change but the mode line disappears?

martin

bug#16923: 24.3.50; reression: `set-frame-size' loses mode line

[Drew Adams]

>  > The Info frame already exists. It has no minibuffer, and it shows
>  > only buffer *info*.
> 
> And it has a mode line and you switch to another Info node and you want
> to adjust the frame to the size of its page but in fact the page size
> did not change but the mode line disappears?

I'm not sure what the question is.  But yes, except for the last part.

It is not the case in general that the page size does not change when
the mode line disappears. IOW, I think you are guessing that the newly
visited node has the same page size as the last-visited one, whenever
the mode line disappears. That is not the case.  IOW2: Frame resizing
may well change the frame size when the mode line disappears.

I see no connection between the occurrence of losing the mode line
and whether or not frame fitting actually changes the frame size.
And in any case, even when the size might end up being exactly the
same, `set-frame-size' is called.

bug#16923: 24.3.50; reression: `set-frame-size' loses mode line

[martin rudalics]

 >> And it has a mode line and you switch to another Info node and you want
 >> to adjust the frame to the size of its page but in fact the page size
 >> did not change but the mode line disappears?
 >
 > I'm not sure what the question is.

It was an attempt to describe what happened.

 > But yes, except for the last part.
 >
 > It is not the case in general that the page size does not change when
 > the mode line disappears. IOW, I think you are guessing that the newly
 > visited node has the same page size as the last-visited one, whenever
 > the mode line disappears. That is not the case.  IOW2: Frame resizing
 > may well change the frame size when the mode line disappears.
 >
 > I see no connection between the occurrence of losing the mode line
 > and whether or not frame fitting actually changes the frame size.
 > And in any case, even when the size might end up being exactly the
 > same, `set-frame-size' is called.

`set-frame-size' returns earlier when no change of the size is called
for.  But if you say that it does not depend on whether a size change
occurred there's no sense pursuing this track any further.

Anyway - the two puzzling aspects are that the mode line apparently gets
erased (who can do such a thing to the mode line?) while the header line
remains unharmed.

martin

bug#16923: 24.3.50; reression: `set-frame-size' loses mode line

[Drew Adams]

> Anyway - the two puzzling aspects are that the mode line apparently gets
> erased (who can do such a thing to the mode line?) while the header line
> remains unharmed.

Wrt the mode line, let me correct something I said earlier.

I thought that the space was there for the mode line, but without
the mode line text, faces, mouseover etc., i.e., as if there were
an extra blank buffer line.  I was wrong about that.

Checking again, I see that the buffer text extends to the bottom frame
border, just as it does when frame parameter `modeline' has value nil.
IOW, the mode line is apparently just not there; it is not just that it
is displayed wrong.  However, `frame-parameters' shows the `mode-line'
parameter value to be `t'.

bug#16923: 24.3.50; reression: `set-frame-size' loses mode line

[martin rudalics]

 >> Anyway - the two puzzling aspects are that the mode line apparently gets
 >> erased (who can do such a thing to the mode line?) while the header line
 >> remains unharmed.
 >
 > Wrt the mode line, let me correct something I said earlier.
 >
 > I thought that the space was there for the mode line, but without
 > the mode line text, faces, mouseover etc., i.e., as if there were
 > an extra blank buffer line.  I was wrong about that.
 >
 > Checking again, I see that the buffer text extends to the bottom frame
 > border, just as it does when frame parameter `modeline' has value nil.
 > IOW, the mode line is apparently just not there; it is not just that it
 > is displayed wrong.  However, `frame-parameters' shows the `mode-line'
 > parameter value to be `t'.

This is a completely different situation.  In addition, it probably
happens only when you want to enlarge the frame.  A timing problem,
likely.  Does the frame have at least an external border at the bottom?

martin

bug#16923: 24.3.50; reression: `set-frame-size' loses mode line

[Eli Zaretskii]

> Date: Wed, 05 Mar 2014 20:28:47 +0100
> From: martin rudalics <rudalics@gmx.at>
> Cc: 16923@debbugs.gnu.org
> 
> Anyway - the two puzzling aspects are that the mode line apparently gets
> erased (who can do such a thing to the mode line?) while the header line
> remains unharmed.

If someone could post a recipe for reproducing this, perhaps I could
help with answering these questions.

bug#16923: 24.3.50; reression: `set-frame-size' loses mode line

[Drew Adams]

> > Anyway - the two puzzling aspects are that the mode line apparently gets
> > erased (who can do such a thing to the mode line?) while the header line
> > remains unharmed.
> 
> If someone could post a recipe for reproducing this, perhaps I could
> help with answering these questions.

See my initial post - to repro, the setup needed is too complex.
I spent a lot of time trying to narrow things down, but was not
successful.  I can repro it with my complete setup, at least, so
I can test things etc.

(One thing I perhaps did not mention: the problem exists regardless
of the value of `Info-use-header-line'.)

bug#16923: 24.3.50; reression: `set-frame-size' loses mode line

[Drew Adams]

>  > Wrt the mode line, let me correct something I said earlier.
>  >
>  > I thought that the space was there for the mode line, but without
>  > the mode line text, faces, mouseover etc., i.e., as if there were
>  > an extra blank buffer line.  I was wrong about that.
>  >
>  > Checking again, I see that the buffer text extends to the bottom frame
>  > border, just as it does when frame parameter `modeline' has value nil.
>  > IOW, the mode line is apparently just not there; it is not just that it
>  > is displayed wrong.  However, `frame-parameters' shows the `mode-line'
>  > parameter value to be `t'.
> 
> This is a completely different situation.  In addition, it probably
> happens only when you want to enlarge the frame.  A timing problem,
> likely.  Does the frame have at least an external border at the bottom?

Looking again, I realize I must have been mistaken in what I said
earlier today.  It seems now that the mode line disappears only when
the node does not change (fit-frame is called anyway).  So yes, the
node text size is the same.

I was pretty sure that the mode line also disappears in some cases
when moving to a different node.  But I definitely do not see that
now, so I guess I was mistaken about that.

And yes, the frame always has its borders, including the bottom border.

Sorry for the confusion.

---

Actually, now I can repro it more simply, without using Info.  In my
setup, if I do M-: (fit-frame) more than once in the same frame, the
mode line sometimes disappears.  For most buffers/frames, it disappears.
But not always.  It does not disappear for `list-faces-display', for
some reason.  (It does disappear for `list-colors-display'.)

I still don't have a minimal recipe for this.  Perhaps tonight I will
try again to narrow things down, given this knowledge.  I thought this
was specific to Info.

bug#16923: 24.3.50; reression: `set-frame-size' loses mode line

[Eli Zaretskii]

> Date: Wed, 5 Mar 2014 13:02:07 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: drew.adams@oracle.com, 16923@debbugs.gnu.org
> 
> (One thing I perhaps did not mention: the problem exists regardless
> of the value of `Info-use-header-line'.)

You did mention this fact.

bug#16923: 24.3.50; reression: `set-frame-size' loses mode line

[martin rudalics]

 > Looking again, I realize I must have been mistaken in what I said
 > earlier today.  It seems now that the mode line disappears only when
 > the node does not change (fit-frame is called anyway).  So yes, the
 > node text size is the same.
 >
 > I was pretty sure that the mode line also disappears in some cases
 > when moving to a different node.  But I definitely do not see that
 > now, so I guess I was mistaken about that.
 >
 > And yes, the frame always has its borders, including the bottom border.

Once more:

(1) The mode line disappears only when the frame size remains the same.
     Check this please via the arguments you pass (to `set-frame-size' or
     whatever you use).

(2) Everything else is drawn correctly, there's no area with background
     space only, as you claimed earlier.

Is that correct (from your experience, so far)?  You might want to
attach a screenshot.

 > Actually, now I can repro it more simply, without using Info.  In my
 > setup, if I do M-: (fit-frame) more than once in the same frame, the
 > mode line sometimes disappears.  For most buffers/frames, it disappears.
 > But not always.  It does not disappear for `list-faces-display', for
 > some reason.  (It does disappear for `list-colors-display'.)

Add the following function to your .emacs ...

(defun window--resize-root-window (window delta horizontal ignore pixelwise)
   "Resize root window WINDOW vertically by DELTA lines.
HORIZONTAL non-nil means resize root window WINDOW horizontally
by DELTA columns.

IGNORE non-nil means ignore any restrictions imposed by fixed
size windows, `window-min-height' or `window-min-width' settings.

This function is only called by the frame resizing routines.  It
resizes windows proportionally and never deletes any windows."
   (when (and (windowp window) (numberp delta))
     (let ((pixel-delta
	   (if pixelwise
	       delta
	     (window--size-to-pixel window delta horizontal))))
       (when (window-sizable-p window pixel-delta horizontal ignore t)
	(window--resize-reset (window-frame window) horizontal)
	(window--resize-this-window
	 window pixel-delta horizontal ignore t)
	(window--dump-frame (window-frame window))))))

... and post the contents of the buffer *window-frame-dump* after a
fatal resize operation here (but make sure to not resize any frame again
_before_ getting hold of that buffer's contents!!!).

martin

bug#16923: 24.3.50; reression: `set-frame-size' loses mode line

[Drew Adams]

>  > I was pretty sure that the mode line also disappears in some cases
>  > when moving to a different node.  But I definitely do not see that
>  > now, so I guess I was mistaken about that.
> 
> (1) The mode line disappears only when the frame size remains the same.
>      Check this please via the arguments you pass (to `set-frame-size' or
>      whatever you use).
> 
> (2) Everything else is drawn correctly, there's no area with background
>      space only, as you claimed earlier.
> 
> Is that correct (from your experience, so far)?  You might want to
> attach a screenshot.

Yes, that is what I was saying.  However, testing by printing the sizes
as messages shows that I was wrong (once again).  The mode line can
disappear, it seems, either when the size is the same or when it
increases.

Here are some debug messages, where ====== means the size was not changed
and /////// means that it was changed.  The old and new sizes are also
noted.

These resizings were not associated with losing the mode line:

CUR: (81 63)
NEW: (76 63)
//////////////////////
CUR: (76 61)
NEW: (81 63)
//////////////////////

These, immediately after those, were:

CUR: (81 61)
NEW: (81 63)
//////////////////////
CUR: (81 63)
NEW: (81 63)
====================

That is, the mode line was lost when the height changed from 61 to 63,
and it remained lost when the size was not changed, on the next call
to `set-frame-size'.

In the following sequence of resizings, starting with a visible mode
line, only this change caused the mode line to disappear.  And it
reappeared at the next resizing.

   CUR: (72 20)
   NEW: (72 22)

----------------

CUR: (81 63)
NEW: (72 63)
//////////////////////
CUR: (72 61)
NEW: (72 53)
//////////////////////
CUR: (72 51)
NEW: (72 62)
//////////////////////
CUR: (72 60)
NEW: (72 63)
//////////////////////
CUR: (72 61)
NEW: (72 22)
//////////////////////
CUR: (72 20)
NEW: (72 22)
//////////////////////
CUR: (72 22)
NEW: (72 47)
//////////////////////

---------------

That was using Info.  Note that though the `height' parameter value was
slightly increased when the mode line was lost, I saw no apparent change
in the frame size.  Dunno what that means.

>  > Actually, now I can repro it more simply, without using Info.  In my
>  > setup, if I do M-: (fit-frame) more than once in the same frame, the
>  > mode line sometimes disappears.  For most buffers/frames, it disappears.
>  > But not always.  It does not disappear for `list-faces-display', for
>  > some reason.  (It does disappear for `list-colors-display'.)

With this test of repeating M-: (fit-frame), this is what I see.  The
(240 2) messages are from inputting (fit-frame) into the minibuffer frame,
for M-:. The minibuffer frame is 240 chars wide and 2 chars high.

Evaluating...
CUR: (95 62)
NEW: (95 73)
//////////////////////
Buffer `*Pp Eval Output*' is in mode `Emacs-Lisp'.   For info on the mode: `C-h m'.
nil
CUR: (240 2)
NEW: (240 2)
====================
Evaluating...
CUR: (95 71)
NEW: (95 73)
//////////////////////
Buffer `*Pp Eval Output*' is in mode `Emacs-Lisp'.   For info on the mode: `C-h m'.
nil

Again, there was no apparent change in the frame height, in spite of the
change in `height' parameter value.  The first frame-fit, from height 62
to 73, did represent a size change.  The second, from 71 to 73, did not
show any size change.  The only change I noticed was the mode line
disappearing.

> Add the following function to your .emacs ...
> 
> (defun window--resize-root-window 
>    (window delta horizontal ignore pixelwise)
>    ...)
> 
> ... and post the contents of the buffer *window-frame-dump* after a
> fatal resize operation here (but make sure to not resize any frame again
> _before_ getting hold of that buffer's contents!!!).

I tried that, but buffer *window-frame-dump* never was filled with any
text.  And I never saw any "fatal resize".  IOW, evaluating that defun
did not have any effect that I noticed.  I did still continue to
observe the behavior I have recorded above, however.  IOW, the mode line
continued to disappear in the same way, with no changes that I could
see.

Do I need to do something more than just evaluate that defun?  Do
I need to restart Emacs and do that first or something?  (You mentioned
putting it in .emacs, instead of just evaluating it.  I just evaluated
it.)

bug#16923: 24.3.50; reression: `set-frame-size' loses mode line

[martin rudalics]

 > I tried that, but buffer *window-frame-dump* never was filled with any
 > text.  And I never saw any "fatal resize".  IOW, evaluating that defun
 > did not have any effect that I noticed.  I did still continue to
 > observe the behavior I have recorded above, however.  IOW, the mode line
 > continued to disappear in the same way, with no changes that I could
 > see.
 >
 > Do I need to do something more than just evaluate that defun?  Do
 > I need to restart Emacs and do that first or something?  (You mentioned
 > putting it in .emacs, instead of just evaluating it.  I just evaluated
 > it.)

No.  I forgot that this function is not called unless the frame has at
least two windows.  You could eval (window--dump-frame) immediately in
the minibuffer window once before (saving the contents of the buffer
elsewhere) and once immediately after a bad resize.

martin

bug#16923: 24.3.50; reression: `set-frame-size' loses mode line

[Drew Adams]

> No.  I forgot that this function is not called unless the frame has at
> least two windows.  You could eval (window--dump-frame) immediately in
> the minibuffer window once before (saving the contents of the buffer
> elsewhere) and once immediately after a bad resize.

I tried that. This is what I got in *window-frame-dump*, FWIW:

frame pixel: 728 x 876   cols/lines: 104 x 73   units: 7 x 12
frame text pixel: 707 x 876   cols/lines: 101 x 73
tool: 0  scroll: 21  fringe: 0  border: 0  right: 2  bottom: 2

#<window 16 on throw-fit-frm.el>   parent: nil
pixel left: 0   top: 0   size: 728 x 876   new: 0
char left: 0   top: 0   size: 104 x 73   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 707 x 862   char: 101 x 71
width left fringe: 0  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 21  divider: 0
height header-line: 0  mode-line: 14  divider: 0

bug#16923: 24.3.50; reression: `set-frame-size' loses mode line

[martin rudalics]

 > height header-line: 0  mode-line: 14  divider: 0

Is this in a frame without mode line?

martin

bug#16923: 24.3.50; reression: `set-frame-size' loses mode line

[Drew Adams]

>  > height header-line: 0  mode-line: 14  divider: 0
> 
> Is this in a frame without mode line?

This is the frame that I tested the mode-line disappearance for.
Isn't that what you had in mind?

The frame had a mode line.  I used M-: (fit-frame) twice, which
removed the mode line.  I used (window--dump-frame), then reported
the contents of buffer *window-frame-dump*.

bug#16923: 24.3.50; reression: `set-frame-size' loses mode line

[martin rudalics]

 >>  > height header-line: 0  mode-line: 14  divider: 0
 >>
 >> Is this in a frame without mode line?
 >
 > This is the frame that I tested the mode-line disappearance for.
 > Isn't that what you had in mind?
 >
 > The frame had a mode line.  I used M-: (fit-frame) twice, which
 > removed the mode line.  I used (window--dump-frame), then reported
 > the contents of buffer *window-frame-dump*.

So the window code calculated 14 pixels for the mode line which
subsequently either got lost in the display engine or was cut off by the
window manager.  It would be still interesting to see a high resolution
screenshot of the lower part of your frame.

A list of things you can try:

(1) You have set frame parameters for right and bottom dividers.  Maybe
     they interfere, so try without them.

(2) Set the `border-width' and/or `internal-border-width' parameter of
     your frame to some number and look whether a border stays visible at
     the bottom of a frame whose window lost its mode line.

(3) Try to enhance `window--dump-frame' in a way that it does not erase
     its buffer and call it several times, immediately before and after
     you ask for a frame size change in `fit-frame'.  Moreover, you could
     add two lines to it with a suitable informatory text to display the
     values returned by

     (w32-frame-rect frame)
     (w32-frame-rect frame t)

     These are Windows specific so I can't include them in the
     `window--dump-frame' version that comes with Emacs.

In any case, if setting `w32-enable-frame-resize-hack' does make a
difference, I doubt that we can really do anything about this.  It looks
like a timing error where Emacs and Windows have different conceptions
about the size of the Emacs frame.  Maybe locally binding
`w32-enable-frame-resize-hack' to nil around the `fit-frame' calls would
help.

martin

bug#16923: 24.3.50; reression: `set-frame-size' loses mode line

[Drew Adams]

[-- Attachment #1: Type: text/plain, Size: 3618 bytes --]

> So the window code calculated 14 pixels for the mode line which
> subsequently either got lost in the display engine or was cut off by the
> window manager.  It would be still interesting to see a high resolution
> screenshot of the lower part of your frame.

Attached.

> A list of things you can try:
> 
> (1) You have set frame parameters for right and bottom dividers.  Maybe
>      they interfere, so try without them.

OK, I tried that. It changed nothing.

> (2) Set the `border-width' and/or `internal-border-width' parameter of
>      your frame to some number and look whether a border stays visible at
>      the bottom of a frame whose window lost its mode line.

I set border-width to 10 and internal to 15.  First, some of the times
when the mode line would have disappeared it did not do so.  Second,
it did still do so sometimes - almost disappeared, that is.  In the
latter case, what I saw (attached) was that, instead, part of the mode
line disappeared, and there was no bottom border.

It seems we're getting somewhere now.

> (3) Try to enhance `window--dump-frame' in a way that it does not erase
>      its buffer and call it several times, immediately before and after
>      you ask for a frame size change in `fit-frame'.  Moreover, you could
>      add two lines to it with a suitable informatory text to display the
>      values returned by
> 
>      (w32-frame-rect frame)
>      (w32-frame-rect frame t)
> 
>      These are Windows specific so I can't include them in the
>      `window--dump-frame' version that comes with Emacs.

Attached also.  When fit-frame was called, it printed ------------.
Then it called `window--dump-frame' 3 times.  Then it fit the frame.
Then it called `window--dump-frame' 3 times again. `window--dump-frame'
inserted a form feed, then the data.

So each `fit-frame' call starts with ------------.  It is followed
by 6 sets of data printed by `window--dump-frame', each introduced
with a form feed.

> In any case, if setting `w32-enable-frame-resize-hack' does make a
> difference, I doubt that we can really do anything about this.

I certainly hope you can, though this is not a critical bug.

(It is a regression, in any case.  It should be *possible* to remove
it, since at one time it was not there. ;-)  Of course, that does not
mean that it must be easy to remove it or that removing it and possibly
sacrificin other benefits is TRT.)

> It looks like a timing error where Emacs and Windows have different
> conceptions about the size of the Emacs frame.  Maybe locally binding
> `w32-enable-frame-resize-hack' to nil around the `fit-frame' calls
> would help.

Actually, that does seem to help.  It seems to solve the problem.
Let me know, after looking over all of this information, whether you
think something can be or needs to be fixed on the Emacs side for
this bug, or whether I should just wrap such a binding around the
body of `fit-frame'.

FWIW: Dunno whether it is related, but I have also seen this recently:
Library pp-c-l.el shows a form-feed char in a pretty way, as shown here:
http://www.emacswiki.org/cgi-bin/wiki/PrettyControlL.  This is
still the case in general, but sometimes when a file with form feeds
is first visited they appear normally, i.e., as ^L.  Even hitting `C-l'
does not cause their proper display.  Eventually they are displayed OK.

Perhaps Emacs redisplay is now happening less than was the case before?

Dunno whether this is at all related to bug #16923 (which does not
regain the proper display of the mode line at all).


[-- Attachment #2: throw-emacs-bug-16923.png --]
[-- Type: image/png, Size: 49026 bytes --]

[-- Attachment #3: throw-emacs-bug-16923-w-borders.png --]
[-- Type: image/png, Size: 19374 bytes --]

[-- Attachment #4: throw-emacs-bug-16923.txt --]
[-- Type: text/plain, Size: 24754 bytes --]

------------
\f
frame pixel: 627 x 832   cols/lines: 75 x 57   units: 8 x 14
frame text pixel: 576 x 802   cols/lines: 72 x 57
tool: 0  scroll: 21  fringe: 0  border: 15  right: 2  bottom: 2
w32-rect: (0 0 635 912), (0 0 627 832)
#<window 24 on *info*>   parent: nil
pixel left: 0   top: 0   size: 597 x 802   new: 0
char left: 0   top: 0   size: 74 x 57   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 576 x 772   char: 72 x 55
width left fringe: 0  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 21  divider: 0
height header-line: 14  mode-line: 16  divider: 0


\f
frame pixel: 627 x 832   cols/lines: 75 x 57   units: 8 x 14
frame text pixel: 576 x 802   cols/lines: 72 x 57
tool: 0  scroll: 21  fringe: 0  border: 15  right: 2  bottom: 2
w32-rect: (0 0 635 912), (0 0 627 832)
#<window 24 on *info*>   parent: nil
pixel left: 0   top: 0   size: 597 x 802   new: 0
char left: 0   top: 0   size: 74 x 57   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 576 x 772   char: 72 x 55
width left fringe: 0  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 21  divider: 0
height header-line: 14  mode-line: 16  divider: 0


\f
frame pixel: 627 x 832   cols/lines: 75 x 57   units: 8 x 14
frame text pixel: 576 x 802   cols/lines: 72 x 57
tool: 0  scroll: 21  fringe: 0  border: 15  right: 2  bottom: 2
w32-rect: (0 0 635 912), (0 0 627 832)
#<window 24 on *info*>   parent: nil
pixel left: 0   top: 0   size: 597 x 802   new: 0
char left: 0   top: 0   size: 74 x 57   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 576 x 772   char: 72 x 55
width left fringe: 0  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 21  divider: 0
height header-line: 14  mode-line: 16  divider: 0


\f
frame pixel: 627 x 856   cols/lines: 75 x 59   units: 8 x 14
frame text pixel: 576 x 826   cols/lines: 72 x 59
tool: 0  scroll: 21  fringe: 0  border: 15  right: 2  bottom: 2
w32-rect: (0 0 635 912), (0 0 627 832)
#<window 24 on *info*>   parent: nil
pixel left: 0   top: 0   size: 597 x 826   new: 0
char left: 0   top: 0   size: 74 x 59   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 576 x 796   char: 72 x 56
width left fringe: 0  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 21  divider: 0
height header-line: 14  mode-line: 16  divider: 0


\f
frame pixel: 627 x 856   cols/lines: 75 x 59   units: 8 x 14
frame text pixel: 576 x 826   cols/lines: 72 x 59
tool: 0  scroll: 21  fringe: 0  border: 15  right: 2  bottom: 2
w32-rect: (0 0 635 912), (0 0 627 832)
#<window 24 on *info*>   parent: nil
pixel left: 0   top: 0   size: 597 x 826   new: 0
char left: 0   top: 0   size: 74 x 59   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 576 x 796   char: 72 x 56
width left fringe: 0  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 21  divider: 0
height header-line: 14  mode-line: 16  divider: 0


\f
frame pixel: 627 x 856   cols/lines: 75 x 59   units: 8 x 14
frame text pixel: 576 x 826   cols/lines: 72 x 59
tool: 0  scroll: 21  fringe: 0  border: 15  right: 2  bottom: 2
w32-rect: (0 0 635 912), (0 0 627 832)
#<window 24 on *info*>   parent: nil
pixel left: 0   top: 0   size: 597 x 826   new: 0
char left: 0   top: 0   size: 74 x 59   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 576 x 796   char: 72 x 56
width left fringe: 0  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 21  divider: 0
height header-line: 14  mode-line: 16  divider: 0

------------
\f
frame pixel: 627 x 748   cols/lines: 75 x 51   units: 8 x 14
frame text pixel: 576 x 718   cols/lines: 72 x 51
tool: 0  scroll: 21  fringe: 0  border: 15  right: 2  bottom: 2
w32-rect: (0 0 635 828), (0 0 627 748)
#<window 24 on *info*>   parent: nil
pixel left: 0   top: 0   size: 597 x 718   new: 0
char left: 0   top: 0   size: 74 x 51   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 576 x 688   char: 72 x 49
width left fringe: 0  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 21  divider: 0
height header-line: 14  mode-line: 16  divider: 0


\f
frame pixel: 627 x 748   cols/lines: 75 x 51   units: 8 x 14
frame text pixel: 576 x 718   cols/lines: 72 x 51
tool: 0  scroll: 21  fringe: 0  border: 15  right: 2  bottom: 2
w32-rect: (0 0 635 828), (0 0 627 748)
#<window 24 on *info*>   parent: nil
pixel left: 0   top: 0   size: 597 x 718   new: 0
char left: 0   top: 0   size: 74 x 51   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 576 x 688   char: 72 x 49
width left fringe: 0  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 21  divider: 0
height header-line: 14  mode-line: 16  divider: 0


\f
frame pixel: 627 x 748   cols/lines: 75 x 51   units: 8 x 14
frame text pixel: 576 x 718   cols/lines: 72 x 51
tool: 0  scroll: 21  fringe: 0  border: 15  right: 2  bottom: 2
w32-rect: (0 0 635 828), (0 0 627 748)
#<window 24 on *info*>   parent: nil
pixel left: 0   top: 0   size: 597 x 718   new: 0
char left: 0   top: 0   size: 74 x 51   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 576 x 688   char: 72 x 49
width left fringe: 0  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 21  divider: 0
height header-line: 14  mode-line: 16  divider: 0


\f
frame pixel: 627 x 856   cols/lines: 75 x 59   units: 8 x 14
frame text pixel: 576 x 826   cols/lines: 72 x 59
tool: 0  scroll: 21  fringe: 0  border: 15  right: 2  bottom: 2
w32-rect: (0 0 635 912), (0 0 627 832)
#<window 24 on *info*>   parent: nil
pixel left: 0   top: 0   size: 597 x 826   new: 0
char left: 0   top: 0   size: 74 x 59   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 576 x 796   char: 72 x 56
width left fringe: 0  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 21  divider: 0
height header-line: 14  mode-line: 16  divider: 0


\f
frame pixel: 627 x 856   cols/lines: 75 x 59   units: 8 x 14
frame text pixel: 576 x 826   cols/lines: 72 x 59
tool: 0  scroll: 21  fringe: 0  border: 15  right: 2  bottom: 2
w32-rect: (0 0 635 912), (0 0 627 832)
#<window 24 on *info*>   parent: nil
pixel left: 0   top: 0   size: 597 x 826   new: 0
char left: 0   top: 0   size: 74 x 59   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 576 x 796   char: 72 x 56
width left fringe: 0  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 21  divider: 0
height header-line: 14  mode-line: 16  divider: 0


\f
frame pixel: 627 x 856   cols/lines: 75 x 59   units: 8 x 14
frame text pixel: 576 x 826   cols/lines: 72 x 59
tool: 0  scroll: 21  fringe: 0  border: 15  right: 2  bottom: 2
w32-rect: (0 0 635 912), (0 0 627 832)
#<window 24 on *info*>   parent: nil
pixel left: 0   top: 0   size: 597 x 826   new: 0
char left: 0   top: 0   size: 74 x 59   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 576 x 796   char: 72 x 56
width left fringe: 0  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 21  divider: 0
height header-line: 14  mode-line: 16  divider: 0

------------
\f
frame pixel: 627 x 832   cols/lines: 75 x 57   units: 8 x 14
frame text pixel: 576 x 802   cols/lines: 72 x 57
tool: 0  scroll: 21  fringe: 0  border: 15  right: 2  bottom: 2
w32-rect: (0 0 635 912), (0 0 627 832)
#<window 24 on *info*>   parent: nil
pixel left: 0   top: 0   size: 597 x 802   new: 0
char left: 0   top: 0   size: 74 x 57   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 576 x 772   char: 72 x 55
width left fringe: 0  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 21  divider: 0
height header-line: 14  mode-line: 16  divider: 0


\f
frame pixel: 627 x 832   cols/lines: 75 x 57   units: 8 x 14
frame text pixel: 576 x 802   cols/lines: 72 x 57
tool: 0  scroll: 21  fringe: 0  border: 15  right: 2  bottom: 2
w32-rect: (0 0 635 912), (0 0 627 832)
#<window 24 on *info*>   parent: nil
pixel left: 0   top: 0   size: 597 x 802   new: 0
char left: 0   top: 0   size: 74 x 57   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 576 x 772   char: 72 x 55
width left fringe: 0  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 21  divider: 0
height header-line: 14  mode-line: 16  divider: 0


\f
frame pixel: 627 x 832   cols/lines: 75 x 57   units: 8 x 14
frame text pixel: 576 x 802   cols/lines: 72 x 57
tool: 0  scroll: 21  fringe: 0  border: 15  right: 2  bottom: 2
w32-rect: (0 0 635 912), (0 0 627 832)
#<window 24 on *info*>   parent: nil
pixel left: 0   top: 0   size: 597 x 802   new: 0
char left: 0   top: 0   size: 74 x 57   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 576 x 772   char: 72 x 55
width left fringe: 0  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 21  divider: 0
height header-line: 14  mode-line: 16  divider: 0


\f
frame pixel: 627 x 772   cols/lines: 75 x 53   units: 8 x 14
frame text pixel: 576 x 742   cols/lines: 72 x 53
tool: 0  scroll: 21  fringe: 0  border: 15  right: 2  bottom: 2
w32-rect: (0 0 635 828), (0 0 627 748)
#<window 24 on *info*>   parent: nil
pixel left: 0   top: 0   size: 597 x 742   new: 0
char left: 0   top: 0   size: 74 x 53   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 576 x 712   char: 72 x 50
width left fringe: 0  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 21  divider: 0
height header-line: 14  mode-line: 16  divider: 0


\f
frame pixel: 627 x 772   cols/lines: 75 x 53   units: 8 x 14
frame text pixel: 576 x 742   cols/lines: 72 x 53
tool: 0  scroll: 21  fringe: 0  border: 15  right: 2  bottom: 2
w32-rect: (0 0 635 828), (0 0 627 748)
#<window 24 on *info*>   parent: nil
pixel left: 0   top: 0   size: 597 x 742   new: 0
char left: 0   top: 0   size: 74 x 53   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 576 x 712   char: 72 x 50
width left fringe: 0  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 21  divider: 0
height header-line: 14  mode-line: 16  divider: 0


\f
frame pixel: 627 x 772   cols/lines: 75 x 53   units: 8 x 14
frame text pixel: 576 x 742   cols/lines: 72 x 53
tool: 0  scroll: 21  fringe: 0  border: 15  right: 2  bottom: 2
w32-rect: (0 0 635 828), (0 0 627 748)
#<window 24 on *info*>   parent: nil
pixel left: 0   top: 0   size: 597 x 742   new: 0
char left: 0   top: 0   size: 74 x 53   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 576 x 712   char: 72 x 50
width left fringe: 0  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 21  divider: 0
height header-line: 14  mode-line: 16  divider: 0

------------
\f
frame pixel: 699 x 856   cols/lines: 84 x 59   units: 8 x 14
frame text pixel: 648 x 826   cols/lines: 81 x 59
tool: 0  scroll: 21  fringe: 0  border: 15  right: 2  bottom: 2
w32-rect: (0 0 707 912), (0 0 699 856)
#<window 24 on *info*>   parent: nil
pixel left: 0   top: 0   size: 669 x 826   new: 0
char left: 0   top: 0   size: 83 x 59   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 648 x 796   char: 81 x 56
width left fringe: 0  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 21  divider: 0
height header-line: 14  mode-line: 16  divider: 0


\f
frame pixel: 699 x 856   cols/lines: 84 x 59   units: 8 x 14
frame text pixel: 648 x 826   cols/lines: 81 x 59
tool: 0  scroll: 21  fringe: 0  border: 15  right: 2  bottom: 2
w32-rect: (0 0 707 912), (0 0 699 856)
#<window 24 on *info*>   parent: nil
pixel left: 0   top: 0   size: 669 x 826   new: 0
char left: 0   top: 0   size: 83 x 59   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 648 x 796   char: 81 x 56
width left fringe: 0  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 21  divider: 0
height header-line: 14  mode-line: 16  divider: 0


\f
frame pixel: 699 x 856   cols/lines: 84 x 59   units: 8 x 14
frame text pixel: 648 x 826   cols/lines: 81 x 59
tool: 0  scroll: 21  fringe: 0  border: 15  right: 2  bottom: 2
w32-rect: (0 0 707 912), (0 0 699 856)
#<window 24 on *info*>   parent: nil
pixel left: 0   top: 0   size: 669 x 826   new: 0
char left: 0   top: 0   size: 83 x 59   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 648 x 796   char: 81 x 56
width left fringe: 0  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 21  divider: 0
height header-line: 14  mode-line: 16  divider: 0


\f
frame pixel: 627 x 856   cols/lines: 75 x 59   units: 8 x 14
frame text pixel: 576 x 826   cols/lines: 72 x 59
tool: 0  scroll: 21  fringe: 0  border: 15  right: 2  bottom: 2
w32-rect: (0 0 635 912), (0 0 627 832)
#<window 24 on *info*>   parent: nil
pixel left: 0   top: 0   size: 597 x 826   new: 0
char left: 0   top: 0   size: 74 x 59   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 576 x 796   char: 72 x 56
width left fringe: 0  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 21  divider: 0
height header-line: 14  mode-line: 16  divider: 0


\f
frame pixel: 627 x 856   cols/lines: 75 x 59   units: 8 x 14
frame text pixel: 576 x 826   cols/lines: 72 x 59
tool: 0  scroll: 21  fringe: 0  border: 15  right: 2  bottom: 2
w32-rect: (0 0 635 912), (0 0 627 832)
#<window 24 on *info*>   parent: nil
pixel left: 0   top: 0   size: 597 x 826   new: 0
char left: 0   top: 0   size: 74 x 59   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 576 x 796   char: 72 x 56
width left fringe: 0  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 21  divider: 0
height header-line: 14  mode-line: 16  divider: 0


\f
frame pixel: 627 x 856   cols/lines: 75 x 59   units: 8 x 14
frame text pixel: 576 x 826   cols/lines: 72 x 59
tool: 0  scroll: 21  fringe: 0  border: 15  right: 2  bottom: 2
w32-rect: (0 0 635 912), (0 0 627 832)
#<window 24 on *info*>   parent: nil
pixel left: 0   top: 0   size: 597 x 826   new: 0
char left: 0   top: 0   size: 74 x 59   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 576 x 796   char: 72 x 56
width left fringe: 0  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 21  divider: 0
height header-line: 14  mode-line: 16  divider: 0

------------
\f
frame pixel: 699 x 856   cols/lines: 84 x 59   units: 8 x 14
frame text pixel: 648 x 826   cols/lines: 81 x 59
tool: 0  scroll: 21  fringe: 0  border: 15  right: 2  bottom: 2
w32-rect: (0 0 707 912), (0 0 699 856)
#<window 24 on *info*>   parent: nil
pixel left: 0   top: 0   size: 669 x 826   new: 0
char left: 0   top: 0   size: 83 x 59   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 648 x 796   char: 81 x 56
width left fringe: 0  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 21  divider: 0
height header-line: 14  mode-line: 16  divider: 0


\f
frame pixel: 699 x 856   cols/lines: 84 x 59   units: 8 x 14
frame text pixel: 648 x 826   cols/lines: 81 x 59
tool: 0  scroll: 21  fringe: 0  border: 15  right: 2  bottom: 2
w32-rect: (0 0 707 912), (0 0 699 856)
#<window 24 on *info*>   parent: nil
pixel left: 0   top: 0   size: 669 x 826   new: 0
char left: 0   top: 0   size: 83 x 59   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 648 x 796   char: 81 x 56
width left fringe: 0  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 21  divider: 0
height header-line: 14  mode-line: 16  divider: 0


\f
frame pixel: 699 x 856   cols/lines: 84 x 59   units: 8 x 14
frame text pixel: 648 x 826   cols/lines: 81 x 59
tool: 0  scroll: 21  fringe: 0  border: 15  right: 2  bottom: 2
w32-rect: (0 0 707 912), (0 0 699 856)
#<window 24 on *info*>   parent: nil
pixel left: 0   top: 0   size: 669 x 826   new: 0
char left: 0   top: 0   size: 83 x 59   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 648 x 796   char: 81 x 56
width left fringe: 0  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 21  divider: 0
height header-line: 14  mode-line: 16  divider: 0


\f
frame pixel: 699 x 856   cols/lines: 84 x 59   units: 8 x 14
frame text pixel: 648 x 826   cols/lines: 81 x 59
tool: 0  scroll: 21  fringe: 0  border: 15  right: 2  bottom: 2
w32-rect: (0 0 707 912), (0 0 699 856)
#<window 24 on *info*>   parent: nil
pixel left: 0   top: 0   size: 669 x 826   new: 0
char left: 0   top: 0   size: 83 x 59   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 648 x 796   char: 81 x 56
width left fringe: 0  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 21  divider: 0
height header-line: 14  mode-line: 16  divider: 0


\f
frame pixel: 699 x 856   cols/lines: 84 x 59   units: 8 x 14
frame text pixel: 648 x 826   cols/lines: 81 x 59
tool: 0  scroll: 21  fringe: 0  border: 15  right: 2  bottom: 2
w32-rect: (0 0 707 912), (0 0 699 856)
#<window 24 on *info*>   parent: nil
pixel left: 0   top: 0   size: 669 x 826   new: 0
char left: 0   top: 0   size: 83 x 59   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 648 x 796   char: 81 x 56
width left fringe: 0  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 21  divider: 0
height header-line: 14  mode-line: 16  divider: 0


\f
frame pixel: 699 x 856   cols/lines: 84 x 59   units: 8 x 14
frame text pixel: 648 x 826   cols/lines: 81 x 59
tool: 0  scroll: 21  fringe: 0  border: 15  right: 2  bottom: 2
w32-rect: (0 0 707 912), (0 0 699 856)
#<window 24 on *info*>   parent: nil
pixel left: 0   top: 0   size: 669 x 826   new: 0
char left: 0   top: 0   size: 83 x 59   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 648 x 796   char: 81 x 56
width left fringe: 0  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 21  divider: 0
height header-line: 14  mode-line: 16  divider: 0

------------
\f
frame pixel: 699 x 856   cols/lines: 84 x 59   units: 8 x 14
frame text pixel: 648 x 826   cols/lines: 81 x 59
tool: 0  scroll: 21  fringe: 0  border: 15  right: 2  bottom: 2
w32-rect: (0 0 707 912), (0 0 699 856)
#<window 24 on *info*>   parent: nil
pixel left: 0   top: 0   size: 669 x 826   new: 0
char left: 0   top: 0   size: 83 x 59   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 648 x 796   char: 81 x 56
width left fringe: 0  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 21  divider: 0
height header-line: 14  mode-line: 16  divider: 0


\f
frame pixel: 699 x 856   cols/lines: 84 x 59   units: 8 x 14
frame text pixel: 648 x 826   cols/lines: 81 x 59
tool: 0  scroll: 21  fringe: 0  border: 15  right: 2  bottom: 2
w32-rect: (0 0 707 912), (0 0 699 856)
#<window 24 on *info*>   parent: nil
pixel left: 0   top: 0   size: 669 x 826   new: 0
char left: 0   top: 0   size: 83 x 59   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 648 x 796   char: 81 x 56
width left fringe: 0  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 21  divider: 0
height header-line: 14  mode-line: 16  divider: 0


\f
frame pixel: 699 x 856   cols/lines: 84 x 59   units: 8 x 14
frame text pixel: 648 x 826   cols/lines: 81 x 59
tool: 0  scroll: 21  fringe: 0  border: 15  right: 2  bottom: 2
w32-rect: (0 0 707 912), (0 0 699 856)
#<window 24 on *info*>   parent: nil
pixel left: 0   top: 0   size: 669 x 826   new: 0
char left: 0   top: 0   size: 83 x 59   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 648 x 796   char: 81 x 56
width left fringe: 0  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 21  divider: 0
height header-line: 14  mode-line: 16  divider: 0


\f
frame pixel: 699 x 856   cols/lines: 84 x 59   units: 8 x 14
frame text pixel: 648 x 826   cols/lines: 81 x 59
tool: 0  scroll: 21  fringe: 0  border: 15  right: 2  bottom: 2
w32-rect: (0 0 707 912), (0 0 699 856)
#<window 24 on *info*>   parent: nil
pixel left: 0   top: 0   size: 669 x 826   new: 0
char left: 0   top: 0   size: 83 x 59   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 648 x 796   char: 81 x 56
width left fringe: 0  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 21  divider: 0
height header-line: 14  mode-line: 16  divider: 0


\f
frame pixel: 699 x 856   cols/lines: 84 x 59   units: 8 x 14
frame text pixel: 648 x 826   cols/lines: 81 x 59
tool: 0  scroll: 21  fringe: 0  border: 15  right: 2  bottom: 2
w32-rect: (0 0 707 912), (0 0 699 856)
#<window 24 on *info*>   parent: nil
pixel left: 0   top: 0   size: 669 x 826   new: 0
char left: 0   top: 0   size: 83 x 59   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 648 x 796   char: 81 x 56
width left fringe: 0  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 21  divider: 0
height header-line: 14  mode-line: 16  divider: 0


\f
frame pixel: 699 x 856   cols/lines: 84 x 59   units: 8 x 14
frame text pixel: 648 x 826   cols/lines: 81 x 59
tool: 0  scroll: 21  fringe: 0  border: 15  right: 2  bottom: 2
w32-rect: (0 0 707 912), (0 0 699 856)
#<window 24 on *info*>   parent: nil
pixel left: 0   top: 0   size: 669 x 826   new: 0
char left: 0   top: 0   size: 83 x 59   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 648 x 796   char: 81 x 56
width left fringe: 0  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 21  divider: 0
height header-line: 14  mode-line: 16  divider: 0

------------
\f
frame pixel: 699 x 856   cols/lines: 84 x 59   units: 8 x 14
frame text pixel: 648 x 826   cols/lines: 81 x 59
tool: 0  scroll: 21  fringe: 0  border: 15  right: 2  bottom: 2
w32-rect: (0 0 707 912), (0 0 699 856)
#<window 24 on *info*>   parent: nil
pixel left: 0   top: 0   size: 669 x 826   new: 0
char left: 0   top: 0   size: 83 x 59   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 648 x 796   char: 81 x 56
width left fringe: 0  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 21  divider: 0
height header-line: 14  mode-line: 16  divider: 0


\f
frame pixel: 699 x 856   cols/lines: 84 x 59   units: 8 x 14
frame text pixel: 648 x 826   cols/lines: 81 x 59
tool: 0  scroll: 21  fringe: 0  border: 15  right: 2  bottom: 2
w32-rect: (0 0 707 912), (0 0 699 856)
#<window 24 on *info*>   parent: nil
pixel left: 0   top: 0   size: 669 x 826   new: 0
char left: 0   top: 0   size: 83 x 59   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 648 x 796   char: 81 x 56
width left fringe: 0  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 21  divider: 0
height header-line: 14  mode-line: 16  divider: 0


\f
frame pixel: 699 x 856   cols/lines: 84 x 59   units: 8 x 14
frame text pixel: 648 x 826   cols/lines: 81 x 59
tool: 0  scroll: 21  fringe: 0  border: 15  right: 2  bottom: 2
w32-rect: (0 0 707 912), (0 0 699 856)
#<window 24 on *info*>   parent: nil
pixel left: 0   top: 0   size: 669 x 826   new: 0
char left: 0   top: 0   size: 83 x 59   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 648 x 796   char: 81 x 56
width left fringe: 0  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 21  divider: 0
height header-line: 14  mode-line: 16  divider: 0


\f
frame pixel: 699 x 856   cols/lines: 84 x 59   units: 8 x 14
frame text pixel: 648 x 826   cols/lines: 81 x 59
tool: 0  scroll: 21  fringe: 0  border: 15  right: 2  bottom: 2
w32-rect: (0 0 707 912), (0 0 699 856)
#<window 24 on *info*>   parent: nil
pixel left: 0   top: 0   size: 669 x 826   new: 0
char left: 0   top: 0   size: 83 x 59   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 648 x 796   char: 81 x 56
width left fringe: 0  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 21  divider: 0
height header-line: 14  mode-line: 16  divider: 0


\f
frame pixel: 699 x 856   cols/lines: 84 x 59   units: 8 x 14
frame text pixel: 648 x 826   cols/lines: 81 x 59
tool: 0  scroll: 21  fringe: 0  border: 15  right: 2  bottom: 2
w32-rect: (0 0 707 912), (0 0 699 856)
#<window 24 on *info*>   parent: nil
pixel left: 0   top: 0   size: 669 x 826   new: 0
char left: 0   top: 0   size: 83 x 59   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 648 x 796   char: 81 x 56
width left fringe: 0  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 21  divider: 0
height header-line: 14  mode-line: 16  divider: 0


\f
frame pixel: 699 x 856   cols/lines: 84 x 59   units: 8 x 14
frame text pixel: 648 x 826   cols/lines: 81 x 59
tool: 0  scroll: 21  fringe: 0  border: 15  right: 2  bottom: 2
w32-rect: (0 0 707 912), (0 0 699 856)
#<window 24 on *info*>   parent: nil
pixel left: 0   top: 0   size: 669 x 826   new: 0
char left: 0   top: 0   size: 83 x 59   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 648 x 796   char: 81 x 56
width left fringe: 0  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 21  divider: 0
height header-line: 14  mode-line: 16  divider: 0

========================================================

bug#16923: 24.3.50; reression: `set-frame-size' loses mode line

[martin rudalics]

 > I set border-width to 10 and internal to 15.  First, some of the times
 > when the mode line would have disappeared it did not do so.  Second,
 > it did still do so sometimes - almost disappeared, that is.  In the
 > latter case, what I saw (attached) was that, instead, part of the mode
 > line disappeared, and there was no bottom border.

Good.  IIUC this shows that the display engine works correctly.  It
draws the mode line but somehow it gets clipped together with the
internal border.

 > It seems we're getting somewhere now.

It will be just a sobering experience when we're there at last.

 >> (3) Try to enhance `window--dump-frame' in a way that it does not erase
 >>      its buffer and call it several times, immediately before and after
 >>      you ask for a frame size change in `fit-frame'.  Moreover, you could
 >>      add two lines to it with a suitable informatory text to display the
 >>      values returned by
 >>
 >>      (w32-frame-rect frame)
 >>      (w32-frame-rect frame t)
 >>
 >>      These are Windows specific so I can't include them in the
 >>      `window--dump-frame' version that comes with Emacs.
 >
 > Attached also.  When fit-frame was called, it printed ------------.
 > Then it called `window--dump-frame' 3 times.  Then it fit the frame.
 > Then it called `window--dump-frame' 3 times again. `window--dump-frame'
 > inserted a form feed, then the data.

It seems easy to spot the problem - it should be

w32-rect: (0 0 635 912), (0 0 627 832)
...
w32-rect: (0 0 635 828), (0 0 627 748)
...
w32-rect: (0 0 707 912), (0 0 699 856) <--- here
...
w32-rect: (0 0 635 912), (0 0 627 832)

The difference between the height of the outer rectangle (which includes
title and menu bar and decorations) and the client rectangle shrinks
from 80 to 56 pixels.  I suppose that all parts exclusively in the outer
rectangle (title, menu bar, ...) are still here as before (are they????)
which means that there are 24 pixels less for the client rectangle and
Windows partly draws the frame decoration over it and clips the rest.

Prepare a function to print the difference of the (nth 3) of the two
`w32-frame-rect' calls in the echo area of a second frame, bind it to a
key, and you should see that whenever the modeline is absent that value
is 56 while otherwise it is 80.

Note that `w32-frame-rect' is purely build from Windows API calls - that
is, the raw values are provided by Windows and Emacs only converts them
to coordinates.  So at first sight this looks like a Windows bug.
Windows should never return another difference unless, for example, the
menu bar wraps.

 >> It looks like a timing error where Emacs and Windows have different
 >> conceptions about the size of the Emacs frame.  Maybe locally binding
 >> `w32-enable-frame-resize-hack' to nil around the `fit-frame' calls
 >> would help.
 >
 > Actually, that does seem to help.  It seems to solve the problem.
 > Let me know, after looking over all of this information, whether you
 > think something can be or needs to be fixed on the Emacs side for
 > this bug, or whether I should just wrap such a binding around the
 > body of `fit-frame'.

It's a fragile fix.  But I have no better solution at the moment.

 > FWIW: Dunno whether it is related, but I have also seen this recently:
 > Library pp-c-l.el shows a form-feed char in a pretty way, as shown here:
 > http://www.emacswiki.org/cgi-bin/wiki/PrettyControlL.  This is
 > still the case in general, but sometimes when a file with form feeds
 > is first visited they appear normally, i.e., as ^L.  Even hitting `C-l'
 > does not cause their proper display.  Eventually they are displayed OK.
 >
 > Perhaps Emacs redisplay is now happening less than was the case before?
 >
 > Dunno whether this is at all related to bug #16923 (which does not
 > regain the proper display of the mode line at all).

FWIW this is completely unrelated.

martin

bug#16923: 24.3.50; reression: `set-frame-size' loses mode line

[Drew Adams]

> It seems easy to spot the problem - it should be
> w32-rect: (0 0 635 912), (0 0 627 832)
> ...
> w32-rect: (0 0 635 828), (0 0 627 748)
> ...
> w32-rect: (0 0 707 912), (0 0 699 856) <--- here
> ...
> w32-rect: (0 0 635 912), (0 0 627 832)
> 
> The difference between the height of the outer rectangle (which includes
> title and menu bar and decorations) and the client rectangle shrinks
> from 80 to 56 pixels.  I suppose that all parts exclusively in the outer
> rectangle (title, menu bar, ...) are still here as before (are they????)

Sorry, I don't quite follow you.
Just what are you asking me to check (and how)?

> which means that there are 24 pixels less for the client rectangle and
> Windows partly draws the frame decoration over it and clips the rest.
> 
> Prepare a function to print the difference of the (nth 3) of the two
> `w32-frame-rect' calls in the echo area of a second frame, bind it to a
> key, and you should see that whenever the modeline is absent that value
> is 56 while otherwise it is 80.

Sorry, I really do not know what you would like me to do.
Please elaborate.

> Note that `w32-frame-rect' is purely build from Windows API calls - that
> is, the raw values are provided by Windows and Emacs only converts them
> to coordinates.  So at first sight this looks like a Windows bug.
> Windows should never return another difference unless, for example, the
> menu bar wraps.
>
>  >> It looks like a timing error where Emacs and Windows have different
>  >> conceptions about the size of the Emacs frame.  Maybe locally binding
>  >> `w32-enable-frame-resize-hack' to nil around the `fit-frame' calls
>  >> would help.
>  >
>  > Actually, that does seem to help.  It seems to solve the problem.
>  > Let me know, after looking over all of this information, whether you
>  > think something can be or needs to be fixed on the Emacs side for
>  > this bug, or whether I should just wrap such a binding around the
>  > body of `fit-frame'.
> 
> It's a fragile fix.  But I have no better solution at the moment.

OK, I guess I'll make that change, then.  Can you say what is fragile
about it?  Do you expect that it will break something?  Or do you mean
only that it might not work in all cases?  (Or do you mean something
else?)

bug#16923: 24.3.50; reression: `set-frame-size' loses mode line

[martin rudalics]

 > Sorry, I don't quite follow you.
 > Just what are you asking me to check

Whether the frame title part, the menu bar or any other decorations
provided by Windows change when the modeline disappears.

 > (and how)?

By looking at the Emacs frame including its decorations.

 >> which means that there are 24 pixels less for the client rectangle and
 >> Windows partly draws the frame decoration over it and clips the rest.
 >>
 >> Prepare a function to print the difference of the (nth 3) of the two
 >> `w32-frame-rect' calls in the echo area of a second frame, bind it to a
 >> key, and you should see that whenever the modeline is absent that value
 >> is 56 while otherwise it is 80.
 >
 > Sorry, I really do not know what you would like me to do.
 > Please elaborate.

Evaluate

(defun foo ()
   (interactive)
   (let ((window-rect (w32-frame-rect))
	(client-rect (w32-frame-rect nil t)))
   (message "%s"
	   (- (- (nth 3 window-rect) (nth 1 window-rect))
	      (- (nth 3 client-rect) (nth 1 client-rect))))))

(global-set-key [(control meta +)] 'foo)

and look what it prints.  I suppose the values are different depending
on when the modeline is present and when it is not.  Here the value is
different when the menubar wraps or disappears, after F11, ...

 > OK, I guess I'll make that change, then.  Can you say what is fragile
 > about it?  Do you expect that it will break something?  Or do you mean
 > only that it might not work in all cases?  (Or do you mean something
 > else?)

It might not work in all cases.

martin

bug#16923: 24.3.50; reression: `set-frame-size' loses mode line

[Drew Adams]

>  > Just what are you asking me to check
> 
> Whether the frame title part, the menu bar or any other decorations
> provided by Windows change when the modeline disappears.

No, they do not change when the mode line disappears.

> (defun foo ()...)
> (global-set-key [(control meta +)] 'foo)
> and look what it prints.  

80

> I suppose the values are different depending
> on when the modeline is present and when it is not.  Here the value is
> different when the menubar wraps or disappears, after F11, ...

No, the value is not different when the mode line is present or missing.

Yes, the value is different (25) when I toggle full screen or I resize
the frame so the menu bar no longer wraps.

bug#16923: 24.3.50; reression: `set-frame-size' loses mode line

[martin rudalics]

Drew Adams schrieb:
 >>  > Just what are you asking me to check
 >>
 >> Whether the frame title part, the menu bar or any other decorations
 >> provided by Windows change when the modeline disappears.
 >
 > No, they do not change when the mode line disappears.
 >
 >> (defun foo ()...)
 >> (global-set-key [(control meta +)] 'foo)
 >> and look what it prints.
 >
 > 80
 >
 >> I suppose the values are different depending
 >> on when the modeline is present and when it is not.  Here the value is
 >> different when the menubar wraps or disappears, after F11, ...
 >
 > No, the value is not different when the mode line is present or missing.
 >
 > Yes, the value is different (25) when I toggle full screen or I resize
 > the frame so the menu bar no longer wraps.

 From the backtrace you attached earlier it's clearly visible that in 21
calls the value is 56.  And as I remarked earlier, this value is Windows
internal.  So unless we have some proof that Emacs is asking Windows to
do something like enlarging the title bar or wrapping the menu bar, we
must assume that Emacs sent so many resize requests in a row that it was
able to confuse Windows.

I have no idea how often you ask for changing the frame size in one and
the same redisplay cycle.  On Windows, without ConfigureNotify events, I
wouldn't issue more than one request per frame in one redisplay cycle.
Everything else means asking for trouble.

martin

bug#16923: 24.3.50; reression: `set-frame-size' loses mode line

[Drew Adams]

> From the backtrace you attached earlier it's clearly visible that in 21
> calls the value is 56.  And as I remarked earlier, this value is Windows
> internal.  So unless we have some proof that Emacs is asking Windows to
> do something like enlarging the title bar or wrapping the menu bar, we
> must assume that Emacs sent so many resize requests in a row that it was
> able to confuse Windows.
> 
> I have no idea how often you ask for changing the frame size in one and
> the same redisplay cycle.  On Windows, without ConfigureNotify events, I
> wouldn't issue more than one request per frame in one redisplay cycle.
> Everything else means asking for trouble.

In the debug output I sent, file throw-emacs-bug-16923.txt, you see,
as I mentioned, seven calls to `fit-frame' (each "------------" in the
file).  I was doing `s RET' in Info, non-incrementally searching for
the next occurrence of a string ("terminals").  Each press of `s'
entailed a single call to `fit-frame'.  In some cases a second
occurrence was found in the same node, so any `s' and its `fit-frame'
other than the first in such a node is essentially a no-op (except for
the bug side effect of removing the mode line).

Does that respond to your question about how often frame resizing is
requested per "redisplay cycle"?  I do not know the period, whether
in terms of a number of input events or elapsed time, of a "redisplay
cycle", but I can say that my pressing of `s' determined the calls
to `fit-frame': one per press.

And in the other test I did earlier, just using `M-: (fit-frame)'
twice in the same frame, the number of calls to `fit-frame' was two.

You say that you "assume that Emacs sent so many resize requests in
a row that it was able to confuse Windows".  What do you mean to draw
attention to here: the number of requests in a row or the rapidity or
frequency of resize requests?  What constitutes a "row", i.e., until
interrupted by what?

Based on what I say above, I do not see how it could be that either
a high cadence or a high number of successive `fit-frame' calls could
be overwhelming redisplay.  But I am entirely ignorant about redisplay,
and I am not very clear about what you are asking here.

bug#16923: 24.3.50; reression: `set-frame-size' loses mode line

[Eli Zaretskii]

> Date: Sat, 8 Mar 2014 07:34:54 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 16923@debbugs.gnu.org
> 
> > From the backtrace you attached earlier it's clearly visible that in 21
> > calls the value is 56.  And as I remarked earlier, this value is Windows
> > internal.  So unless we have some proof that Emacs is asking Windows to
> > do something like enlarging the title bar or wrapping the menu bar, we
> > must assume that Emacs sent so many resize requests in a row that it was
> > able to confuse Windows.
> > 
> > I have no idea how often you ask for changing the frame size in one and
> > the same redisplay cycle.  On Windows, without ConfigureNotify events, I
> > wouldn't issue more than one request per frame in one redisplay cycle.
> > Everything else means asking for trouble.
> 
> In the debug output I sent, file throw-emacs-bug-16923.txt, you see,
> as I mentioned, seven calls to `fit-frame' (each "------------" in the
> file).  I was doing `s RET' in Info, non-incrementally searching for
> the next occurrence of a string ("terminals").  Each press of `s'
> entailed a single call to `fit-frame'.  In some cases a second
> occurrence was found in the same node, so any `s' and its `fit-frame'
> other than the first in such a node is essentially a no-op (except for
> the bug side effect of removing the mode line).
> 
> Does that respond to your question about how often frame resizing is
> requested per "redisplay cycle"?  I do not know the period, whether
> in terms of a number of input events or elapsed time, of a "redisplay
> cycle", but I can say that my pressing of `s' determined the calls
> to `fit-frame': one per press.

Every time Emacs waits for input, it automatically enters redisplay.
So, unless you typed a series of 's' keys faster than Emacs could
process them (which I doubt, since you probably looked at the search
results before pressing the next 's'), each 's' keystroke would account
for one redisplay cycle.  If you took your time reading before you
pressed another key, there could be more than one redisplay cycle
between every two 's' keystrokes.

> Based on what I say above, I do not see how it could be that either
> a high cadence or a high number of successive `fit-frame' calls could
> be overwhelming redisplay.  But I am entirely ignorant about redisplay,
> and I am not very clear about what you are asking here.

Perhaps Martin meant something other than the redisplay cycle I
described above.

bug#16923: 24.3.50; reression: `set-frame-size' loses mode line

[Drew Adams]

> Every time Emacs waits for input, it automatically enters redisplay.
> So, unless you typed a series of 's' keys faster than Emacs could
> process them (which I doubt, since you probably looked at the search
> results before pressing the next 's'), each 's' keystroke would account
> for one redisplay cycle.  If you took your time reading before you
> pressed another key, there could be more than one redisplay cycle
> between every two 's' keystrokes.

That coincides with what I thought.  And no, I did not press `s'
quickly at all.  Similarly, for the test of just doing
`M-: (fit-frame)' twice in succession: I can wait as long as we like
from one to the next.

> > Based on what I say above, I do not see how it could be that either
> > a high cadence or a high number of successive `fit-frame' calls could
> > be overwhelming redisplay.  But I am entirely ignorant about redisplay,
> > and I am not very clear about what you are asking here.
> 
> Perhaps Martin meant something other than the redisplay cycle I
> described above.

bug#16923: 24.3.50; reression: `set-frame-size' loses mode line

[martin rudalics]

 > In the debug output I sent, file throw-emacs-bug-16923.txt, you see,
 > as I mentioned, seven calls to `fit-frame' (each "------------" in the
 > file).  I was doing `s RET' in Info, non-incrementally searching for
 > the next occurrence of a string ("terminals").  Each press of `s'
 > entailed a single call to `fit-frame'.  In some cases a second
 > occurrence was found in the same node, so any `s' and its `fit-frame'
 > other than the first in such a node is essentially a no-op (except for
 > the bug side effect of removing the mode line).
 >
 > Does that respond to your question about how often frame resizing is
 > requested per "redisplay cycle"?  I do not know the period, whether
 > in terms of a number of input events or elapsed time, of a "redisplay
 > cycle", but I can say that my pressing of `s' determined the calls
 > to `fit-frame': one per press.
 >
 > And in the other test I did earlier, just using `M-: (fit-frame)'
 > twice in the same frame, the number of calls to `fit-frame' was two.

I see 42 calls of `window--dump-frame' which from what you say above
means that for every `fit-frame' there are 6 calls of
`window--dump-frame'.  Does that mean there are 6 `set-frame-size'
requests per each `fit-frame' call?

Note: I'm not interested in `fit-frame' or how you calculate frame
sizes.  I'm only interested in your calls of `set-frame-size' or
whatever you use to resize your frame.  How many such calls are there in
throw-emacs-bug-16923?  And how can I attribute any of these calls to a
frame without a mode line?

 > You say that you "assume that Emacs sent so many resize requests in
 > a row that it was able to confuse Windows".  What do you mean to draw
 > attention to here: the number of requests in a row

The number.

 > or the rapidity or
 > frequency of resize requests?  What constitutes a "row", i.e., until
 > interrupted by what?

By redisplay.

 > Based on what I say above, I do not see how it could be that either
 > a high cadence or a high number of successive `fit-frame' calls could
 > be overwhelming redisplay.  But I am entirely ignorant about redisplay,
 > and I am not very clear about what you are asking here.

The problem is not in redisplay.  The problem is the number of resize
requests sent in succession to the window manager before redisplay
occurs.  On Windows this is the number of calls of AdjustWindowRect
which corresponds to the number of calls of `set-frame-size'.  Redisplay
should occur only after Emacs has negotiated with Windows for each of
these calls.

Anyway.  Beginning with the fourth "------------" on line 271 of
throw-emacs-bug-16923 the height difference of window and client
rectangle is 56 and not 80 as before.  Unless we can resolve that
mystery it hardly make sense to experiment any further.

martin

bug#16923: 24.3.50; reression: `set-frame-size' loses mode line

[martin rudalics]

 > Perhaps Martin meant something other than the redisplay cycle I
 > described above.

I had no idea about how Drew triggered the calls or redisplay.  What I
wanted to know was how often he invoked `set-frame-size' before the next
redisplay, and how often he then invoked `set-frame-size' before the
next redisplay, and so on ...  That's what I used the term cycle for.

martin

bug#16923: 24.3.50; reression: `set-frame-size' loses mode line

[Drew Adams]

> I see 42 calls of `window--dump-frame' which from what you say above
> means that for every `fit-frame' there are 6 calls of
> `window--dump-frame'.  Does that mean there are 6 `set-frame-size'
> requests per each `fit-frame' call?

No, it does not.  You asked me to invoke `window--dump-frame' multiple
times before and after each invocation of `fit-frame'.  I figured 3
times would be enough to satisfy that (so 6 times per `fit-frame').
Did I misunderstand the request?

> Note: I'm not interested in `fit-frame' or how you calculate frame
> sizes.  I'm only interested in your calls of `set-frame-size' or
> whatever you use to resize your frame.  How many such calls are there in
> throw-emacs-bug-16923?  And how can I attribute any of these calls to a
> frame without a mode line?

There is one `set-frame-size' per `fit-frame' call.  So seven calls
to `set-frame-size'.

I don't recall exactly, and I see that I did not mention it in my
report with `throw-emacs-bug-16923' (though I mentioned all of the rest
of this), just how many of the seven `fit-frame' invocations resulted
in loss of the mode line.  I believe that only the last invocation
lost the mode line, but I am not sure to remember correctly.

IIRC, I believed that I stopped as soon as I got one mode line
disappearance, but I couldn't swear that that is the case.  I should
have noted that in my report.

>  > You say that you "assume that Emacs sent so many resize requests in
>  > a row that it was able to confuse Windows".  What do you mean to draw
>  > attention to here: the number of requests in a row
> 
> The number.
> 
>  > or the rapidity or
>  > frequency of resize requests?  What constitutes a "row", i.e., until
>  > interrupted by what?
> 
> By redisplay.

Doesn't redisplay occur if the Info node changes?  At any rate, as I
said, I just hit `s RET' repeatedly to search for the same string.
Sometimes that string was found more than once in the same node,
sometimes not.

>  > Based on what I say above, I do not see how it could be that either
>  > a high cadence or a high number of successive `fit-frame' calls could
>  > be overwhelming redisplay.  But I am entirely ignorant about redisplay,
>  > and I am not very clear about what you are asking here.
> 
> The problem is not in redisplay.  The problem is the number of resize
> requests sent in succession to the window manager before redisplay
> occurs.  On Windows this is the number of calls of AdjustWindowRect
> which corresponds to the number of calls of `set-frame-size'.  Redisplay
> should occur only after Emacs has negotiated with Windows for each of
> these calls.
> 
> Anyway.  Beginning with the fourth "------------" on line 271 of
> throw-emacs-bug-16923 the height difference of window and client
> rectangle is 56 and not 80 as before.  Unless we can resolve that
> mystery it hardly make sense to experiment any further.

OK.  Let me know if you want me to try something else.

bug#16923: 24.3.50; reression: `set-frame-size' loses mode line

[martin rudalics]

 > No, it does not.  You asked me to invoke `window--dump-frame' multiple
 > times before and after each invocation of `fit-frame'.

I always said before and after a "resize operation".  But if as you say
`fit-frame' calls `set-frame-size' once only and no-one else calls
`set-frame-size' in between, it's OK.  In the future please remember:
I'm only interested in calls to resize the frame.

 > I figured 3
 > times would be enough to satisfy that (so 6 times per `fit-frame').
 > Did I misunderstand the request?

The "several times" was obviously a misunderstanding.  I meant to make
one call before and after each `set-frame-size' and trigger that
operation several times, until the mode line disappears.

 > There is one `set-frame-size' per `fit-frame' call.  So seven calls
 > to `set-frame-size'.

On line 3 of throw-emacs-bug-16923.txt I see

frame pixel: 627 x 832   cols/lines: 75 x 57   units: 8 x 14

on line 48 I see

frame pixel: 627 x 856   cols/lines: 75 x 59   units: 8 x 14

and on line 93 I see

frame pixel: 627 x 748   cols/lines: 75 x 51   units: 8 x 14

I think these are the first in a row of three identic dumps.

This means that the frame size changes across the "------------" on line
91.  And it changes again across the next two "------------"'s.  Can you
explain that?  If it's caused by the window manager, then you should
notice that the heights don't fit already there (you got 51 lines
instead of the 59 you requested).  If it's not caused by the window
manager I don't know.

martin

bug#16923: 24.3.50; reression: `set-frame-size' loses mode line

[Drew Adams]

> This means that the frame size changes across the "------------" on line
> 91.  And it changes again across the next two "------------"'s.  Can you
> explain that?

I'm not sure I get your drift.  But as I said, IIRC, each time I hit
`s RET' there was a call to `fit-frame', hence to `set-frame-size'.

If `s' caused the Info node to change to a node of a different size,
then naturally the resulting frame size would be different.

> If it's caused by the window manager, then you should
> notice that the heights don't fit already there (you got 51 lines
> instead of the 59 you requested).

What shows a request of 59 and a result of 51?  I see `51' on line 93,
which I guess you are saying is the resulting frame size (?).  But
resulting from what size request?  Where do you see the `59' as an
indication of what size was requested?

What I think I see instead is this:

3 calls to w32* before the resize request, showing a height of 51,
followed by 3 more calls to w32* after the resize request, showing
a height of 59 (starting on line 138).  But I don't see, in the
dump output, anything that indicates what size was requested with
`set-frame-size'.

This is what I said about that in my report about it:

   When fit-frame was called, it printed ------------.
   Then it called `window--dump-frame' 3 times.
   Then it fit the frame.
   Then it called `window--dump-frame' 3 times again.
   `window--dump-frame' inserted a form feed, then the data.

And this is an extract of the code I used:

 (with-current-buffer (get-buffer-create "*window-frame-dump*")
   (insert "------------\n"))
 (window--dump-frame)
 (window--dump-frame)
 (window--dump-frame)
 (set-frame-size...)
 (window--dump-frame)
 (window--dump-frame)
 (window--dump-frame)

IIRC, it is only the last resize request in throw-bug-16923.txt
that resulted in the loss (or half loss) of the mode line.  The
dump data for the last resize request shows that none of the data
changed as a result of that request.  The sizes do not change, as
they should not change (IIRC, the same node was involved).

IOW, IIUC, the dump data do not show the problem (bug).  The
problem is not, AFAICT, the resulting size.  The problem is that
the mode line is missing (or half missing - I don't recall now
which screenshot corresponds to the dump text).

In sum, sorry, but I'm just not following you well enough.  If
you would like me to do something, or draw a conclusion, or
provide some more information, please clarify/elaborate.

> If it's not caused by the window manager I don't know.

If what is not caused by the window mgr?  If there is no frame
size change and there should not be any frame size change, then
how can the window mgr be at fault?  The problem is that the
mode line disappears.  Without a change in frame size in this case.
How can the window mgr be responsible for a mode line display
malfunction?

bug#16923: 24.3.50; reression: `set-frame-size' loses mode line

[martin rudalics]

 >> This means that the frame size changes across the "------------" on line
 >> 91.  And it changes again across the next two "------------"'s.  Can you
 >> explain that?
 >
 > I'm not sure I get your drift.  But as I said, IIRC, each time I hit
 > `s RET' there was a call to `fit-frame', hence to `set-frame-size'.
 >
 > If `s' caused the Info node to change to a node of a different size,
 > then naturally the resulting frame size would be different.

It's important to get a trace of _every_ call of `set-frame-size' for
that frame - no matter where it comes from.  Are you sure you did that?
And I take it granted that for each `set-frame-size' you inserted a
"------------" in the buffer, then three identical `window--dump-frame'
outputs before the call to `set-frame-size' each preceded by a form feed
and then three identical `window--dump-frame' outputs after the call to
`set-frame-size' each preceded by a form feed too.  Then you did the
same for the next `set-frame-size' call.  Can you confirm that?  If not,
please elaborate.

 >> If it's caused by the window manager, then you should
 >> notice that the heights don't fit already there (you got 51 lines
 >> instead of the 59 you requested).
 >
 > What shows a request of 59 and a result of 51?  I see `51' on line 93,
 > which I guess you are saying is the resulting frame size (?).  But
 > resulting from what size request?  Where do you see the `59' as an
 > indication of what size was requested?

On line 48:

frame pixel: 627 x 856   cols/lines: 75 x 59   units: 8 x 14

 From the interpretation I gave above this line results from the first
`window--dump-frame' call following the very first `set-frame-size' call
you recorded.  Can you see that?  Is my interpretation correct?

 > What I think I see instead is this:
 >
 > 3 calls to w32* before the resize request, showing a height of 51,
 > followed by 3 more calls to w32* after the resize request, showing
 > a height of 59 (starting on line 138).

Line 138 is from the first `window--dump-frame' call following the
_second_ `set-frame-size' resize request you recorded.  I'm talking
about the _first_ `set-frame-size' request you recorded.

 > But I don't see, in the
 > dump output, anything that indicates what size was requested with
 > `set-frame-size'.

A dump is an image of a state.  You would have to record any arguments
separately (which would be a good idea BTW, as well as including
information whether the dump was requested before or after the
`set-frame-size' call and whether the call was made at a time the mode
line was visible).

And please make only one call of `window--dump-frame' before and one
call after each `set-frame-size' call.  And please don't insert any form
feeds - they might easily corrupt any communication about which line of
dumped text we are on.

 > This is what I said about that in my report about it:
 >
 >    When fit-frame was called, it printed ------------.
 >    Then it called `window--dump-frame' 3 times.
 >    Then it fit the frame.
 >    Then it called `window--dump-frame' 3 times again.
 >    `window--dump-frame' inserted a form feed, then the data.
 >
 > And this is an extract of the code I used:
 >
 >  (with-current-buffer (get-buffer-create "*window-frame-dump*")
 >    (insert "------------\n"))
 >  (window--dump-frame)
 >  (window--dump-frame)
 >  (window--dump-frame)
 >  (set-frame-size...)
 >  (window--dump-frame)
 >  (window--dump-frame)
 >  (window--dump-frame)

This is how I understood it.  But what apparently happened is that after
the last (of six) `window--dump-frame' calles belonging to the first
`set-frame-size' request and before the first `window--dump-frame' call
belonging to the second `set-frame-size' request the size of the frame
changed as in lines 78 to 104 of throw-emacs-bug-16923.txt:


frame pixel: 627 x 856   cols/lines: 75 x 59   units: 8 x 14
frame text pixel: 576 x 826   cols/lines: 72 x 59
tool: 0  scroll: 21  fringe: 0  border: 15  right: 2  bottom: 2
w32-rect: (0 0 635 912), (0 0 627 832)
#<window 24 on *info*>   parent: nil
pixel left: 0   top: 0   size: 597 x 826   new: 0
char left: 0   top: 0   size: 74 x 59   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 576 x 796   char: 72 x 56
width left fringe: 0  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 21  divider: 0
height header-line: 14  mode-line: 16  divider: 0

------------
\f
frame pixel: 627 x 748   cols/lines: 75 x 51   units: 8 x 14
frame text pixel: 576 x 718   cols/lines: 72 x 51
tool: 0  scroll: 21  fringe: 0  border: 15  right: 2  bottom: 2
w32-rect: (0 0 635 828), (0 0 627 748)
#<window 24 on *info*>   parent: nil
pixel left: 0   top: 0   size: 597 x 718   new: 0
char left: 0   top: 0   size: 74 x 51   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 576 x 688   char: 72 x 49
width left fringe: 0  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 21  divider: 0
height header-line: 14  mode-line: 16  divider: 0


And this change is unexplained yet.  What height did you see and what
height did you expect to see at the time you hit `s' before the
"------------" was drawn in this excerpt - 59 or 51 lines?

 > IIRC, it is only the last resize request in throw-bug-16923.txt
 > that resulted in the loss (or half loss) of the mode line.  The
 > dump data for the last resize request shows that none of the data
 > changed as a result of that request.  The sizes do not change, as
 > they should not change (IIRC, the same node was involved).
 >
 > IOW, IIUC, the dump data do not show the problem (bug).  The
 > problem is not, AFAICT, the resulting size.  The problem is that
 > the mode line is missing (or half missing - I don't recall now
 > which screenshot corresponds to the dump text).
 >
 > In sum, sorry, but I'm just not following you well enough.  If
 > you would like me to do something, or draw a conclusion, or
 > provide some more information, please clarify/elaborate.

There are far too many inconsistencies before we even get there.

 >> If it's not caused by the window manager I don't know.
 >
 > If what is not caused by the window mgr?  If there is no frame
 > size change and there should not be any frame size change, then
 > how can the window mgr be at fault?  The problem is that the
 > mode line disappears.  Without a change in frame size in this case.
 > How can the window mgr be responsible for a mode line display
 > malfunction?

Please let's try to concentrate on the problem I sketched here before
drawing any conclusions about what happened afterwards.

Thanks, martin

bug#16923: 24.3.50; reression: `set-frame-size' loses mode line

[Drew Adams]

[-- Attachment #1: Type: text/plain, Size: 6092 bytes --]

>  >> This means that the frame size changes across the "------------" on line
>  >> 91.  And it changes again across the next two "------------"'s.  Can you
>  >> explain that?
> 
> It's important to get a trace of _every_ call of `set-frame-size' for
> that frame - no matter where it comes from.  Are you sure you did that?

I cannot be sure that something, somewhere else did not issue another call
of `set-frame-size', no.  My debugging is limited to `fit-frame' calls.

> And I take it granted that for each `set-frame-size' you inserted a
> "------------" in the buffer, then three identical `window--dump-frame'
> outputs before the call to `set-frame-size' each preceded by a form feed
> and then three identical `window--dump-frame' outputs after the call to
> `set-frame-size' each preceded by a form feed too.  

Correct, wrt the call to `set-frame-size' within `fit-frame'.  See above.

> Then you did the same for the next `set-frame-size' call.  Can you
> confirm that?  If not, please elaborate.

Yes, AFAIK, IIRC.  And as I've already confirmed several times now.

>  >> If it's caused by the window manager, then you should
>  >> notice that the heights don't fit already there (you got 51 lines
>  >> instead of the 59 you requested).
>  >
>  > What shows a request of 59 and a result of 51?  I see `51' on line 93,
>  > which I guess you are saying is the resulting frame size (?).  But
>  > resulting from what size request?  Where do you see the `59' as an
>  > indication of what size was requested?
> 
> On line 48:
> frame pixel: 627 x 856   cols/lines: 75 x 59   units: 8 x 14
> 
> From the interpretation I gave above this line results from the first
> `window--dump-frame' call following the very first `set-frame-size' call
> you recorded.  Can you see that?  Is my interpretation correct?

Yes.  But again, where does the dump show a _request_ of 59?  What line
48 shows is the _result_ of resizing to 59.  And again, IIRC that was
the right thing to do - the only place where the mode line disappeared
in this debug file is at the end.  But I am repeating what I've already
repeated.

>  > What I think I see instead is this:
>  > 3 calls to w32* before the resize request, showing a height of 51,
>  > followed by 3 more calls to w32* after the resize request, showing
>  > a height of 59 (starting on line 138).
> 
> Line 138 is from the first `window--dump-frame' call following the
> _second_ `set-frame-size' resize request you recorded.  I'm talking
> about the _first_ `set-frame-size' request you recorded.

As I said, IIRC, there was no problem with that first `set-frame-size'
(before line 48).  The mode line did not disappear at that resizing.

But it's possible that I am not remembering correctly.  (So I repeated
the test - below.)

> And please make only one call of `window--dump-frame' before and one
> call after each `set-frame-size' call.  And please don't insert any form
> feeds - they might easily corrupt any communication about which line of
> dumped text we are on.
> 
> ... But what apparently happened is that after
> the last (of six) `window--dump-frame' calles belonging to the first
> `set-frame-size' request and before the first `window--dump-frame' call
> belonging to the second `set-frame-size' request the size of the frame
> changed as in lines 78 to 104 of throw-emacs-bug-16923.txt:
> ...
> And this change is unexplained yet.  What height did you see and
> what height did you expect to see at the time you hit `s' before the
> "------------" was drawn in this excerpt - 59 or 51 lines?

Dunno.

---

I made another test.  I removed the form feed from `window-dump-frame'
and I have `fit-frame' call `window-dump-frame' only once before and once
after `set-frame-size'.  And I have `fit-frame' print the requested new
width and height, before calling `set-frame-size'.

I tested it using `C-x C-_', which is bound to `fit-frame'.  See attached.

It shows that the height, as reported by `window--dump-frame', changed
from 69 to 62 after the dump that reported the result of the first
`set-frame-size'.  Why that would be is a mystery to me.

It shows that the resulting height of the second `set-frame-size', which
caused the mode line to disappear, is correct: 69.  (But the starting
height, according to `window--dump-frame', was unexpected - see above.)

The two attachments show the same test, repeated.  But here is some
more info that may help:

If I just repeat calls to `fit-frame' when the frame is already the
right size then the mode line does not disappear.  To manifest the
problem, I must first manually resize the frame (e.g. with the mouse)
so that `fit-frame' will actually resize it (change its size).  Then,
after that first `fit-frame' resizes it correctly, a second `fit-frame'
leads to the debug output attached: the mode line is lost, and the
dump output from `fit-frame' BEFORE the `set-frame-size' shows an
incorrect height value.

IOW, it seems that what is needed is first (a) an actual change in
frame size by `set-frame-size' and then (b) a `set-frame-size' that
does not actually change the size.  Both (a) and (b) seem necessary
to lose the mode line.  If I start with a frame that already has the
target size (i.e., it has already been fit), then repeating `fit-frame'
has no visible effect, including no loss of the mode line.

Note too that even though the dump shows an incorrect height value,
there is nothing visual that corresponds to this: The frame height
after the frame is fit (correctly) does not visibly change when the
second `fit-frame' is called.  The only visible effect of the second
`fit-frame' is that the mode line disappears.

IOW, `fit-frame', and thus `set-frame-size', seem to be doing their
job correctly.  As you point out, and as these dumps show once again,
something internal in Emacs seems to think that the height is less
than it actually is (by 6 units, in this case).  The new, requested
frame height is applied correctly.

HTH.

[-- Attachment #2: throw-emacs-bug-16923-bis.txt --]
[-- Type: text/plain, Size: 2484 bytes --]

------------

frame pixel: 728 x 804   cols/lines: 104 x 67   units: 7 x 12
frame text pixel: 707 x 804   cols/lines: 101 x 67
tool: 0  scroll: 21  fringe: 0  border: 0  right: 2  bottom: 2
w32-rect: (0 0 736 884), (0 0 728 804)
#<window 30 on throw-fit-frm.el>   parent: nil
pixel left: 0   top: 0   size: 728 x 804   new: 0
char left: 0   top: 0   size: 104 x 67   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 707 x 790   char: 101 x 65
width left fringe: 0  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 21  divider: 0
height header-line: 0  mode-line: 14  divider: 0

::: Requested WIDTH: 101, HEIGHT: 69

frame pixel: 728 x 828   cols/lines: 104 x 69   units: 7 x 12
frame text pixel: 707 x 828   cols/lines: 101 x 69
tool: 0  scroll: 21  fringe: 0  border: 0  right: 2  bottom: 2
w32-rect: (0 0 736 884), (0 0 728 804)
#<window 30 on throw-fit-frm.el>   parent: nil
pixel left: 0   top: 0   size: 728 x 828   new: 0
char left: 0   top: 0   size: 104 x 69   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 707 x 814   char: 101 x 67
width left fringe: 0  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 21  divider: 0
height header-line: 0  mode-line: 14  divider: 0

------------

frame pixel: 728 x 744   cols/lines: 104 x 62   units: 7 x 12
frame text pixel: 707 x 744   cols/lines: 101 x 62
tool: 0  scroll: 21  fringe: 0  border: 0  right: 2  bottom: 2
w32-rect: (0 0 736 824), (0 0 728 744)
#<window 30 on throw-fit-frm.el>   parent: nil
pixel left: 0   top: 0   size: 728 x 744   new: 0
char left: 0   top: 0   size: 104 x 62   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 707 x 730   char: 101 x 60
width left fringe: 0  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 21  divider: 0
height header-line: 0  mode-line: 14  divider: 0

::: Requested WIDTH: 101, HEIGHT: 69

frame pixel: 728 x 828   cols/lines: 104 x 69   units: 7 x 12
frame text pixel: 707 x 828   cols/lines: 101 x 69
tool: 0  scroll: 21  fringe: 0  border: 0  right: 2  bottom: 2
w32-rect: (0 0 736 884), (0 0 728 804)
#<window 30 on throw-fit-frm.el>   parent: nil
pixel left: 0   top: 0   size: 728 x 828   new: 0
char left: 0   top: 0   size: 104 x 69   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 707 x 814   char: 101 x 67
width left fringe: 0  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 21  divider: 0
height header-line: 0  mode-line: 14  divider: 0


[-- Attachment #3: throw-emacs-bug-16923-ter.txt --]
[-- Type: text/plain, Size: 2480 bytes --]

------------

frame pixel: 728 x 804   cols/lines: 104 x 67   units: 7 x 12
frame text pixel: 707 x 804   cols/lines: 101 x 67
tool: 0  scroll: 21  fringe: 0  border: 0  right: 2  bottom: 2
w32-rect: (0 0 736 884), (0 0 728 804)
#<window 30 on throw-fit-frm.el>   parent: nil
pixel left: 0   top: 0   size: 728 x 804   new: 0
char left: 0   top: 0   size: 104 x 67   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 707 x 790   char: 101 x 65
width left fringe: 0  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 21  divider: 0
height header-line: 0  mode-line: 14  divider: 0

::: Requested WIDTH: 101, HEIGHT: 69

frame pixel: 728 x 828   cols/lines: 104 x 69   units: 7 x 12
frame text pixel: 707 x 828   cols/lines: 101 x 69
tool: 0  scroll: 21  fringe: 0  border: 0  right: 2  bottom: 2
w32-rect: (0 0 736 884), (0 0 728 804)
#<window 30 on throw-fit-frm.el>   parent: nil
pixel left: 0   top: 0   size: 728 x 828   new: 0
char left: 0   top: 0   size: 104 x 69   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 707 x 814   char: 101 x 67
width left fringe: 0  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 21  divider: 0
height header-line: 0  mode-line: 14  divider: 0

------------

frame pixel: 686 x 756   cols/lines: 98 x 63   units: 7 x 12
frame text pixel: 665 x 756   cols/lines: 95 x 63
tool: 0  scroll: 21  fringe: 0  border: 0  right: 2  bottom: 2
w32-rect: (0 0 694 836), (0 0 686 756)
#<window 30 on throw-fit-frm.el>   parent: nil
pixel left: 0   top: 0   size: 686 x 756   new: 0
char left: 0   top: 0   size: 98 x 63   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 665 x 742   char: 95 x 61
width left fringe: 0  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 21  divider: 0
height header-line: 0  mode-line: 14  divider: 0

::: Requested WIDTH: 101, HEIGHT: 69

frame pixel: 728 x 828   cols/lines: 104 x 69   units: 7 x 12
frame text pixel: 707 x 828   cols/lines: 101 x 69
tool: 0  scroll: 21  fringe: 0  border: 0  right: 2  bottom: 2
w32-rect: (0 0 736 884), (0 0 728 804)
#<window 30 on throw-fit-frm.el>   parent: nil
pixel left: 0   top: 0   size: 728 x 828   new: 0
char left: 0   top: 0   size: 104 x 69   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 707 x 814   char: 101 x 67
width left fringe: 0  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 21  divider: 0
height header-line: 0  mode-line: 14  divider: 0

bug#16923: 24.3.50; reression: `set-frame-size' loses mode line

[martin rudalics]

 > I cannot be sure that something, somewhere else did not issue another call
 > of `set-frame-size', no.  My debugging is limited to `fit-frame' calls.

But you can make sure that that something, somewhere is not part of your
code?

 > Yes.  But again, where does the dump show a _request_ of 59?  What line
 > 48 shows is the _result_ of resizing to 59.  And again, IIRC that was
 > the right thing to do - the only place where the mode line disappeared
 > in this debug file is at the end.  But I am repeating what I've already
 > repeated.

Your assertion of how you obtained the dump permits such the conclusion
that 59 was the requested size.  In your bis dump it's 69.

 >> Line 138 is from the first `window--dump-frame' call following the
 >> _second_ `set-frame-size' resize request you recorded.  I'm talking
 >> about the _first_ `set-frame-size' request you recorded.
 >
 > As I said, IIRC, there was no problem with that first `set-frame-size'
 > (before line 48).  The mode line did not disappear at that resizing.

But the dump was inconsistent with what you saw.

 > I made another test.  I removed the form feed from `window-dump-frame'
 > and I have `fit-frame' call `window-dump-frame' only once before and once
 > after `set-frame-size'.  And I have `fit-frame' print the requested new
 > width and height, before calling `set-frame-size'.

Very good.

 > I tested it using `C-x C-_', which is bound to `fit-frame'.  See attached.

Fine.  But I need a couple of tests in sequence.  Seven as the last time
might be good - I want to know whether the w32-rect problem shows up as
well.  In your first test it did - but not immediately.  In the present
tests it did not.

 > It shows that the height, as reported by `window--dump-frame', changed
 > from 69 to 62 after the dump that reported the result of the first
 > `set-frame-size'.  Why that would be is a mystery to me.
 >
 > It shows that the resulting height of the second `set-frame-size', which
 > caused the mode line to disappear, is correct: 69.  (But the starting
 > height, according to `window--dump-frame', was unexpected - see above.)

I think both problems disappear when you set
`w32-enable-frame-resize-hack' to nil.  Please do that and repeat the
simple C-x C-_ test two times (I only need to see one ------------
between two dumps).  For the moment, this is the most important test.

 > The two attachments show the same test, repeated.  But here is some
 > more info that may help:
 >
 > If I just repeat calls to `fit-frame' when the frame is already the
 > right size then the mode line does not disappear.  To manifest the
 > problem, I must first manually resize the frame (e.g. with the mouse)
 > so that `fit-frame' will actually resize it (change its size).  Then,
 > after that first `fit-frame' resizes it correctly, a second `fit-frame'
 > leads to the debug output attached: the mode line is lost, and the
 > dump output from `fit-frame' BEFORE the `set-frame-size' shows an
 > incorrect height value.

This would be fine but I don't see that anywhere in the dumps.  That is,
I see that you request 101 columns and get 104 but that might be another
issue.

 > IOW, it seems that what is needed is first (a) an actual change in
 > frame size by `set-frame-size' and then (b) a `set-frame-size' that
 > does not actually change the size.  Both (a) and (b) seem necessary
 > to lose the mode line.  If I start with a frame that already has the
 > target size (i.e., it has already been fit), then repeating `fit-frame'
 > has no visible effect, including no loss of the mode line.

Can you provide a dump of that sequence supported by a good explanation
of what you did?

 > Note too that even though the dump shows an incorrect height value,
 > there is nothing visual that corresponds to this: The frame height
 > after the frame is fit (correctly) does not visibly change when the
 > second `fit-frame' is called.  The only visible effect of the second
 > `fit-frame' is that the mode line disappears.
 >
 > IOW, `fit-frame', and thus `set-frame-size', seem to be doing their
 > job correctly.  As you point out, and as these dumps show once again,
 > something internal in Emacs seems to think that the height is less
 > than it actually is (by 6 units, in this case).  The new, requested
 > frame height is applied correctly.

Obviously, if Emacs (1) stores inside a bad value you do not see and you
(2) ask it to change the frame size to itself, then (3) Emacs might
surprise you with a frame with the bad value stored in (1).  That's what
we have to find out.

Thanks, martin

bug#16923: 24.3.50; reression: `set-frame-size' loses mode line

[Drew Adams]

[-- Attachment #1: Type: text/plain, Size: 5710 bytes --]

>  > I cannot be sure that something, somewhere else did not issue another
>  > call of `set-frame-size', no.  My debugging is limited to `fit-frame'
>  > calls.
> 
> But you can make sure that that something, somewhere is not part of your
> code?

My code also calls `set-frame-size' on `minibuffer-exit-hook', to reset
the minibuffer frame size.  That's it.

However, my code also calls `modify-frame-parameters' in many contexts
and locations.  I tested again, after removing two of those from
functions on `post-command-hook', including resizing the minibuffer frame
- see attached (*-04.txt), which shows the same problem as before.
I believe that I have eliminated all other uses of
`modify-frame-parameters' from the test.

But if, for example, you have a suggested `defadvice' or something for
`set-frame-size' and `modify-frame-parameters' or whatever, I can try
that too.

>  > I made another test.  I removed the form feed from `window-dump-frame'
>  > and I have `fit-frame' call `window-dump-frame' only once before and once
>  > after `set-frame-size'.  And I have `fit-frame' print the requested new
>  > width and height, before calling `set-frame-size'.
> 
> Very good.
> 
>  > I tested it using `C-x C-_', which is bound to `fit-frame'.  See
>  > attached.
> 
> Fine.  But I need a couple of tests in sequence.  Seven as the last time
> might be good - I want to know whether the w32-rect problem shows up as
> well.  In your first test it did - but not immediately.  In the present
> tests it did not.

Unclear.  Please be clear about just what sequence of just which tests
you need.

>  > It shows that the height, as reported by `window--dump-frame', changed
>  > from 69 to 62 after the dump that reported the result of the first
>  > `set-frame-size'.  Why that would be is a mystery to me.
>  >
>  > It shows that the resulting height of the second `set-frame-size', which
>  > caused the mode line to disappear, is correct: 69.  (But the starting
>  > height, according to `window--dump-frame', was unexpected - see above.)
> 
> I think both problems

What are "both problems"?  I have seen only one problem, AFAIK: loss of
the mode line.

> disappear when you set `w32-enable-frame-resize-hack' to nil.
> Please do that and repeat the simple C-x C-_ test two times (I only need
> to see one ------------ between two dumps).

Attached, as *-05.txt.  As mentioned before, that stops the mode line
from disappearing, and it breaks thumbifying.

> For the moment, this is the most important test.
> 
>  > The two attachments show the same test, repeated.  But here is some
>  > more info that may help:
>  >
>  > If I just repeat calls to `fit-frame' when the frame is already the
>  > right size then the mode line does not disappear.  To manifest the
>  > problem, I must first manually resize the frame (e.g. with the mouse)
>  > so that `fit-frame' will actually resize it (change its size).  Then,
>  > after that first `fit-frame' resizes it correctly, a second `fit-frame'
>  > leads to the debug output attached: the mode line is lost, and the
>  > dump output from `fit-frame' BEFORE the `set-frame-size' shows an
>  > incorrect height value.
> 
> This would be fine but I don't see that anywhere in the dumps.  That is,
> I see that you request 101 columns and get 104 but that might be another
> issue.

No, I already stated that that corresponds to the (correct) frame fitting.
By correct I mean that the frame size changed and the mode line was not
lost.

And as you have now requested multiple dump files, you had better
cite just which file you are referring to from now on, when you make such
comments.  I assume that you meant throw-emacs-bug-16923-ter.txt here.
That file shows a correct resizing with no mode-line loss, followed by
no size change but with mode-line loss.

>  > IOW, it seems that what is needed is first (a) an actual change in
>  > frame size by `set-frame-size' and then (b) a `set-frame-size' that
>  > does not actually change the size.  Both (a) and (b) seem necessary
>  > to lose the mode line.  If I start with a frame that already has the
>  > target size (i.e., it has already been fit), then repeating `fit-frame'
>  > has no visible effect, including no loss of the mode line.
> 
> Can you provide a dump of that sequence supported by a good explanation
> of what you did?

What sequence?  I provided a good explanation of what I did.
Please be specific about just what recipe you want followed.

>  > Note too that even though the dump shows an incorrect height value,
>  > there is nothing visual that corresponds to this: The frame height
>  > after the frame is fit (correctly) does not visibly change when the
>  > second `fit-frame' is called.  The only visible effect of the second
>  > `fit-frame' is that the mode line disappears.
>  >
>  > IOW, `fit-frame', and thus `set-frame-size', seem to be doing their
>  > job correctly.  As you point out, and as these dumps show once again,
>  > something internal in Emacs seems to think that the height is less
>  > than it actually is (by 6 units, in this case).  The new, requested
>  > frame height is applied correctly.
> 
> Obviously, if Emacs (1) stores inside a bad value you do not see and you
> (2) ask it to change the frame size to itself, then (3) Emacs might
> surprise you with a frame with the bad value stored in (1).  That's what
> we have to find out.

Emacs has so far never surprised me with the wrong frame size.  So far,
it has resized the frame as I expectd each time.  The only problem is the
loss of the mode line - not the size of the frame.

[-- Attachment #2: throw-emacs-bug-16923-04.txt --]
[-- Type: text/plain, Size: 2484 bytes --]

------------

frame pixel: 728 x 804   cols/lines: 104 x 67   units: 7 x 12
frame text pixel: 707 x 804   cols/lines: 101 x 67
tool: 0  scroll: 21  fringe: 0  border: 0  right: 2  bottom: 2
w32-rect: (0 0 736 884), (0 0 728 804)
#<window 14 on throw-fit-frm.el>   parent: nil
pixel left: 0   top: 0   size: 728 x 804   new: 0
char left: 0   top: 0   size: 104 x 67   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 707 x 790   char: 101 x 65
width left fringe: 0  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 21  divider: 0
height header-line: 0  mode-line: 14  divider: 0

::: Requested WIDTH: 101, HEIGHT: 69

frame pixel: 728 x 828   cols/lines: 104 x 69   units: 7 x 12
frame text pixel: 707 x 828   cols/lines: 101 x 69
tool: 0  scroll: 21  fringe: 0  border: 0  right: 2  bottom: 2
w32-rect: (0 0 736 884), (0 0 728 804)
#<window 14 on throw-fit-frm.el>   parent: nil
pixel left: 0   top: 0   size: 728 x 828   new: 0
char left: 0   top: 0   size: 104 x 69   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 707 x 814   char: 101 x 67
width left fringe: 0  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 21  divider: 0
height header-line: 0  mode-line: 14  divider: 0

------------

frame pixel: 728 x 684   cols/lines: 104 x 57   units: 7 x 12
frame text pixel: 707 x 684   cols/lines: 101 x 57
tool: 0  scroll: 21  fringe: 0  border: 0  right: 2  bottom: 2
w32-rect: (0 0 736 764), (0 0 728 684)
#<window 14 on throw-fit-frm.el>   parent: nil
pixel left: 0   top: 0   size: 728 x 684   new: 0
char left: 0   top: 0   size: 104 x 57   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 707 x 670   char: 101 x 55
width left fringe: 0  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 21  divider: 0
height header-line: 0  mode-line: 14  divider: 0

::: Requested WIDTH: 101, HEIGHT: 69

frame pixel: 728 x 828   cols/lines: 104 x 69   units: 7 x 12
frame text pixel: 707 x 828   cols/lines: 101 x 69
tool: 0  scroll: 21  fringe: 0  border: 0  right: 2  bottom: 2
w32-rect: (0 0 736 884), (0 0 728 804)
#<window 14 on throw-fit-frm.el>   parent: nil
pixel left: 0   top: 0   size: 728 x 828   new: 0
char left: 0   top: 0   size: 104 x 69   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 707 x 814   char: 101 x 67
width left fringe: 0  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 21  divider: 0
height header-line: 0  mode-line: 14  divider: 0


[-- Attachment #3: throw-emacs-bug-16923-05.txt --]
[-- Type: text/plain, Size: 2478 bytes --]

------------

frame pixel: 728 x 804   cols/lines: 104 x 67   units: 7 x 12
frame text pixel: 707 x 804   cols/lines: 101 x 67
tool: 0  scroll: 21  fringe: 0  border: 0  right: 2  bottom: 2
w32-rect: (0 0 736 884), (0 0 728 804)
#<window 14 on throw-fit-frm.el>   parent: nil
pixel left: 0   top: 0   size: 728 x 804   new: 0
char left: 0   top: 0   size: 104 x 67   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 707 x 790   char: 101 x 65
width left fringe: 0  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 21  divider: 0
height header-line: 0  mode-line: 14  divider: 0

::: Requested WIDTH: 101, HEIGHT: 69

frame pixel: 728 x 804   cols/lines: 104 x 67   units: 7 x 12
frame text pixel: 707 x 804   cols/lines: 101 x 67
tool: 0  scroll: 21  fringe: 0  border: 0  right: 2  bottom: 2
w32-rect: (0 0 736 884), (0 0 728 804)
#<window 14 on throw-fit-frm.el>   parent: nil
pixel left: 0   top: 0   size: 728 x 804   new: 0
char left: 0   top: 0   size: 104 x 67   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 707 x 790   char: 101 x 65
width left fringe: 0  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 21  divider: 0
height header-line: 0  mode-line: 14  divider: 0

------------

frame pixel: 679 x 708   cols/lines: 97 x 59   units: 7 x 12
frame text pixel: 658 x 708   cols/lines: 94 x 59
tool: 0  scroll: 21  fringe: 0  border: 0  right: 2  bottom: 2
w32-rect: (0 0 687 788), (0 0 679 708)
#<window 14 on throw-fit-frm.el>   parent: nil
pixel left: 0   top: 0   size: 679 x 708   new: 0
char left: 0   top: 0   size: 97 x 59   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 658 x 694   char: 94 x 57
width left fringe: 0  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 21  divider: 0
height header-line: 0  mode-line: 14  divider: 0

::: Requested WIDTH: 101, HEIGHT: 69

frame pixel: 679 x 708   cols/lines: 97 x 59   units: 7 x 12
frame text pixel: 658 x 708   cols/lines: 94 x 59
tool: 0  scroll: 21  fringe: 0  border: 0  right: 2  bottom: 2
w32-rect: (0 0 736 884), (0 0 728 804)
#<window 14 on throw-fit-frm.el>   parent: nil
pixel left: 0   top: 0   size: 679 x 708   new: 0
char left: 0   top: 0   size: 97 x 59   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 658 x 694   char: 94 x 57
width left fringe: 0  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 21  divider: 0
height header-line: 0  mode-line: 14  divider: 0

bug#16923: 24.3.50; reression: `set-frame-size' loses mode line

[martin rudalics]

 > My code also calls `set-frame-size' on `minibuffer-exit-hook', to reset
 > the minibuffer frame size.  That's it.
 >
 > However, my code also calls `modify-frame-parameters' in many contexts
 > and locations.  I tested again, after removing two of those from
 > functions on `post-command-hook', including resizing the minibuffer frame
 > - see attached (*-04.txt), which shows the same problem as before.
 > I believe that I have eliminated all other uses of
 > `modify-frame-parameters' from the test.
 >
 > But if, for example, you have a suggested `defadvice' or something for
 > `set-frame-size' and `modify-frame-parameters' or whatever, I can try
 > that too.

I don't use advices so I can't suggest anything.  The only correct
approach is to run Emacs under gdb.

 >> Fine.  But I need a couple of tests in sequence.  Seven as the last time
 >> might be good - I want to know whether the w32-rect problem shows up as
 >> well.  In your first test it did - but not immediately.  In the present
 >> tests it did not.
 >
 > Unclear.  Please be clear about just what sequence of just which tests
 > you need.

Something like the sequence of the first seven tests you sent me, aka
throw-emacs-bug-16923.txt, however, with your new approach (only one
call of `window--dump-frame', show arguments of `set-frame-size').  I
say "something like" because I don't think that you can reproduce the
exactly same sequence of events as in throw-emacs-bug-16923.txt.

 >> Please do that and repeat the simple C-x C-_ test two times (I only need
 >> to see one ------------ between two dumps).
 >
 > Attached, as *-05.txt.  As mentioned before, that stops the mode line
 > from disappearing, and it breaks thumbifying.

OK.  I don't have the slightest idea how this can have worked for you
as intended.

 > ::: Requested WIDTH: 101, HEIGHT: 69
 >
 > frame pixel: 728 x 804   cols/lines: 104 x 67   units: 7 x 12
 > frame text pixel: 707 x 804   cols/lines: 101 x 67
 > tool: 0  scroll: 21  fringe: 0  border: 0  right: 2  bottom: 2
 > w32-rect: (0 0 736 884), (0 0 728 804)
 > #<window 14 on throw-fit-frm.el>   parent: nil
 > pixel left: 0   top: 0   size: 728 x 804   new: 0
 > char left: 0   top: 0   size: 104 x 67   new: 0
 > normal: 1.0 x 1.0   new: 0
 > body pixel: 707 x 790   char: 101 x 65
 > width left fringe: 0  left margin: 0  right margin: 0
 > width right fringe: 0  scroll-bar: 21  divider: 0
 > height header-line: 0  mode-line: 14  divider: 0
 >
 > ------------

Here you should see 101 columns and 69 lines, but according to what gets
printed below you see 97 columns and 59 lines - ten lines less than
requested.  How many lines do you really see here, say by comparing the
numbers of the lines on top and bottom of the throw-fit-frm.el window?
If you really see 69 lines, then please call `window--frame-dump' on
that frame interactively here.  If it still prints 59 lines, we at least
have found a stable configuration where the dump produces a result that
does not match what you see.

 > frame pixel: 679 x 708   cols/lines: 97 x 59   units: 7 x 12
 > frame text pixel: 658 x 708   cols/lines: 94 x 59
 > tool: 0  scroll: 21  fringe: 0  border: 0  right: 2  bottom: 2
 > w32-rect: (0 0 687 788), (0 0 679 708)
 > #<window 14 on throw-fit-frm.el>   parent: nil
 > pixel left: 0   top: 0   size: 679 x 708   new: 0
 > char left: 0   top: 0   size: 97 x 59   new: 0
 > normal: 1.0 x 1.0   new: 0
 > body pixel: 658 x 694   char: 94 x 57
 > width left fringe: 0  left margin: 0  right margin: 0
 > width right fringe: 0  scroll-bar: 21  divider: 0
 > height header-line: 0  mode-line: 14  divider: 0

I just see the same problem as with the `w32-enable-frame-resize-hack' t
case, that is, the size of the frame recorded does not match the size of
the frame you requested.

 >> This would be fine but I don't see that anywhere in the dumps.  That is,
 >> I see that you request 101 columns and get 104 but that might be another
 >> issue.
 >
 > No, I already stated that that corresponds to the (correct) frame fitting.
 > By correct I mean that the frame size changed and the mode line was not
 > lost.

By correct I mean that you have to get the size you requested.  As long
as I cannot resolve the size mystery I cannot continue investigating the
mode line bug - it's the former that might cause the later.

 > And as you have now requested multiple dump files, you had better
 > cite just which file you are referring to from now on, when you make such
 > comments.  I assume that you meant throw-emacs-bug-16923-ter.txt here.
 > That file shows a correct resizing with no mode-line loss, followed by
 > no size change but with mode-line loss.

I always refer to what you send me along with the mail.  And in the mail
you said

 > The two attachments show the same test, repeated.

without further specification so I didn't care.  IIUC you mean that the
dumps from throw-emacs-bug-16923-bis.txt reflect a change of the frame
size while that of throw-emacs-bug-16923-ter.txt reflect a mode line
loss without frame size change and was done immediately after the
former.  Is that so?

 >>  > IOW, it seems that what is needed is first (a) an actual change in
 >>  > frame size by `set-frame-size' and then (b) a `set-frame-size' that
 >>  > does not actually change the size.  Both (a) and (b) seem necessary
 >>  > to lose the mode line.  If I start with a frame that already has the
 >>  > target size (i.e., it has already been fit), then repeating `fit-frame'
 >>  > has no visible effect, including no loss of the mode line.
 >>
 >> Can you provide a dump of that sequence supported by a good explanation
 >> of what you did?
 >
 > What sequence?  I provided a good explanation of what I did.
 > Please be specific about just what recipe you want followed.

The sequence of actions starting with "IOW, it seems that what is needed
is first (a) an actual change in frame size ...".

 > Emacs has so far never surprised me with the wrong frame size.  So far,
 > it has resized the frame as I expectd each time.  The only problem is the
 > loss of the mode line - not the size of the frame.

Unfortunately, I can't reproduce that here.

martin

bug#16923: 24.3.50; reression: `set-frame-size' loses mode line

[Drew Adams]

[-- Attachment #1: Type: text/plain, Size: 2624 bytes --]

Trying to pick up this bug thread again.  I'm afraid your last mail
is confusing to me at this point.

This is what I've done for this test:

1. Ensure, I think, that the only calls to `set-frame-size' are from
my calling `fit-frame' interactively (via C-x C-_).  Nothing on
`post-command-hook' that invokes `set-frame-size', for instance.

2. Resized a frame manually (with the mouse), so that the next call
to `fit-frame' would actually change the size (to fit the buffer text).

3. C-x C-_ (`fit-frame'), which fit the frame, with no loss of the
mode line.

4.  C-x C-_ again, which fit the frame (as a no-op, no size change
needed), this time with loss of the mode line (the bug).

Attached is the log, *window-frame-dump*.  After #3, I added a
line of zeros to the buffer, to make clear where the second call to
`fit-frame' (hence `set-frame-size') occurred.

The relevant lines from `fit-frame' are these:

(with-current-buffer (get-buffer-create "*window-frame-dump*")
  (insert (format "::: Requested WIDTH: %S, HEIGHT: %S\n" wid hgt)))
(set-frame-size frame wid hgt))))))

And this is the `window-dump-frame' code I used:

(defun window--dump-frame (&optional window-or-frame)
  "..."
  (interactive)
  (let* ((window
	  (cond
	   ((or (not window-or-frame)
		(frame-live-p window-or-frame))
	    (frame-root-window window-or-frame))
	   ((or (window-live-p window-or-frame)
		(window-child window-or-frame))
	    window-or-frame)
	   (t
	    (frame-root-window))))
	 (frame (window-frame window)))
    (with-current-buffer (get-buffer-create "*window-frame-dump*")
      ;;(erase-buffer)
      (insert
       (format "\nframe pixel: %s x %s   cols/lines: %s x %s   \
units: %s x %s\n"
	       (frame-pixel-width frame) (frame-pixel-height frame)
	       (frame-total-cols frame) (frame-text-lines frame)
	       (frame-char-width frame) (frame-char-height frame))
       (format "frame text pixel: %s x %s   cols/lines: %s x %s\n"
	       (frame-text-width frame) (frame-text-height frame)
	       (frame-text-cols frame) (frame-text-lines frame))
       (format "tool: %s  scroll: %s  fringe: %s  border: %s  \
right: %s  bottom: %s\n"
	       (tool-bar-height frame t)
	       (frame-scroll-bar-width frame)
	       (frame-fringe-width frame)
	       (frame-border-width frame)
	       (frame-right-divider-width frame)
	       (frame-bottom-divider-width frame))
       (format "w32-rect: %S, %S\n"
               (w32-frame-rect frame)
               (w32-frame-rect frame t)))
      (walk-window-tree 'window--dump-window frame t t))))

HTH.

[-- Attachment #2: throw-bug-16923-2014-03-27a.txt --]
[-- Type: text/plain, Size: 2543 bytes --]

------------

frame pixel: 511 x 528   cols/lines: 73 x 44   units: 7 x 12
frame text pixel: 490 x 528   cols/lines: 70 x 44
tool: 0  scroll: 21  fringe: 0  border: 0  right: 2  bottom: 2
w32-rect: (0 0 519 608), (0 0 511 528)
#<window 14 on throw-fit-frm.el>   parent: nil
pixel left: 0   top: 0   size: 511 x 528   new: 0
char left: 0   top: 0   size: 73 x 44   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 490 x 514   char: 70 x 42
width left fringe: 0  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 21  divider: 0
height header-line: 0  mode-line: 14  divider: 0

::: Requested WIDTH: 101, HEIGHT: 69

frame pixel: 728 x 828   cols/lines: 104 x 69   units: 7 x 12
frame text pixel: 707 x 828   cols/lines: 101 x 69
tool: 0  scroll: 21  fringe: 0  border: 0  right: 2  bottom: 2
w32-rect: (0 0 736 884), (0 0 728 804)
#<window 14 on throw-fit-frm.el>   parent: nil
pixel left: 0   top: 0   size: 728 x 828   new: 0
char left: 0   top: 0   size: 104 x 69   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 707 x 814   char: 101 x 67
width left fringe: 0  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 21  divider: 0
height header-line: 0  mode-line: 14  divider: 0

0000000000000000000000000000000000000000000000000000000

------------

frame pixel: 728 x 804   cols/lines: 104 x 67   units: 7 x 12
frame text pixel: 707 x 804   cols/lines: 101 x 67
tool: 0  scroll: 21  fringe: 0  border: 0  right: 2  bottom: 2
w32-rect: (0 0 736 884), (0 0 728 804)
#<window 14 on throw-fit-frm.el>   parent: nil
pixel left: 0   top: 0   size: 728 x 804   new: 0
char left: 0   top: 0   size: 104 x 67   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 707 x 790   char: 101 x 65
width left fringe: 0  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 21  divider: 0
height header-line: 0  mode-line: 14  divider: 0

::: Requested WIDTH: 101, HEIGHT: 69

frame pixel: 728 x 828   cols/lines: 104 x 69   units: 7 x 12
frame text pixel: 707 x 828   cols/lines: 101 x 69
tool: 0  scroll: 21  fringe: 0  border: 0  right: 2  bottom: 2
w32-rect: (0 0 736 884), (0 0 728 804)
#<window 14 on throw-fit-frm.el>   parent: nil
pixel left: 0   top: 0   size: 728 x 828   new: 0
char left: 0   top: 0   size: 104 x 69   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 707 x 814   char: 101 x 67
width left fringe: 0  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 21  divider: 0
height header-line: 0  mode-line: 14  divider: 0

bug#16923: 24.3.50; reression: `set-frame-size' loses mode line

[martin rudalics]

 > 1. Ensure, I think, that the only calls to `set-frame-size' are from
 > my calling `fit-frame' interactively (via C-x C-_).  Nothing on
 > `post-command-hook' that invokes `set-frame-size', for instance.
 >
 > 2. Resized a frame manually (with the mouse), so that the next call
 > to `fit-frame' would actually change the size (to fit the buffer text).
 >
 > 3. C-x C-_ (`fit-frame'), which fit the frame, with no loss of the
 > mode line.
 >
 > 4.  C-x C-_ again, which fit the frame (as a no-op, no size change
 > needed), this time with loss of the mode line (the bug).
 >
 > Attached is the log, *window-frame-dump*.  After #3, I added a
 > line of zeros to the buffer, to make clear where the second call to
 > `fit-frame' (hence `set-frame-size') occurred.

Thanks.  The problem is that while in the first dump Windows and Emacs
agree about the frame's pixel height as

frame pixel: 511 x 528   cols/lines: 73 x 44   units: 7 x 12
                    ^^^
frame text pixel: 490 x 528   cols/lines: 70 x 44
tool: 0  scroll: 21  fringe: 0  border: 0  right: 2  bottom: 2
w32-rect: (0 0 519 608), (0 0 511 528)
                                   ^^^
they disagree in all remaining dumps

frame pixel: 728 x 828   cols/lines: 104 x 69   units: 7 x 12
                    ^^^
frame text pixel: 707 x 828   cols/lines: 101 x 69
tool: 0  scroll: 21  fringe: 0  border: 0  right: 2  bottom: 2
w32-rect: (0 0 736 884), (0 0 728 804)
                                   ^^^
by 24 pixels, incidentally (maybe) the equivalent of two lines of 12
pixels.  Please try two things now:

(1) Repeat the test once with a default character height of 11 pixels
     and once with say 14 pixels so we can tell whether the two lines
     paradigm holds.

(2) Try to replace `fit-frame' by (set-frame-size nil 101 69) so we can
     eliminate `fit-frame' as possible source of the problem and have an
     easier repeatable scenario.

martin

bug#16923: 24.3.50; reression: `set-frame-size' loses mode line

[Lars Ingebrigtsen]

martin rudalics <rudalics@gmx.at> writes:

> frame pixel: 728 x 828   cols/lines: 104 x 69   units: 7 x 12
>                    ^^^
> frame text pixel: 707 x 828   cols/lines: 101 x 69
> tool: 0  scroll: 21  fringe: 0  border: 0  right: 2  bottom: 2
> w32-rect: (0 0 736 884), (0 0 728 804)
>                                   ^^^
> by 24 pixels, incidentally (maybe) the equivalent of two lines of 12
> pixels.  Please try two things now:
>
> (1) Repeat the test once with a default character height of 11 pixels
>     and once with say 14 pixels so we can tell whether the two lines
>     paradigm holds.
>
> (2) Try to replace `fit-frame' by (set-frame-size nil 101 69) so we can
>     eliminate `fit-frame' as possible source of the problem and have an
>     easier repeatable scenario.

More information was requested five years ago, but none was given, so
I'm closing this bug report.  If further progress can be made now,
please reopen.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#16923: 24.3.50; reression: `set-frame-size' loses mode line

[Drew Adams]

Wow, that was a long and detailed thread!


I think I have not seen that bug in recent
Emacs releases, so I guess it got taken
care of somehow.

Thx to Martin for all of his efforts in
this thread.