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