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

[Drew Adams]

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

throw-emacs-bug-16923-04.txt
Description: Text document

throw-emacs-bug-16923-05.txt
Description: Text document