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

From: martin rudalics <[email-masked]>
Date: Sun, 09 Mar 2014 14:56:02 +0100

>> 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

------------

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