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

[martin rudalics <rudalics@gmx.at>]

 > 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