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

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