bug#22105: 25.1.50; REGRESSION - `modify-frame-parameters'

[Drew Adams <drew.adams@oracle.com>]

> I suppose the behavior is indeed caused by adding and removing the menu
> bar.  At least when doing C-z repeatedly with the "(debug)" commented
> out I see here both small and normal font frames continuously increase
> in size.
> 
> You could try with
> (setq frame-inhibit-implied-resize '(menu-bar-lines tool-bar-lines))
> which inherently means to not resize the outer frame when adding or
> removing the menu bar.  It seems to cure the problem I described above.

Thanks for the quick reply.

Yes, that does seem to take care of this problem, but I will take a
closer look when I get a chance.  In any case, other woes introduced
on 2015-10-20 are not fixed by setting that option - I'll have to find
some time to track those down.

But this is a user option.  Even if changing the value is a "fix"
for this, I'm not sure how I should approach this wrt a library that
lets users thumbify frames and decide which frame parameter values
they want to impose on the thumbnail frames.  I guess I could change
the option value on the fly, if `menu-bar-lines' is changed to or
from 0).  But that seems ugly and awkward.

I see that the default value of this option gives you the same
behavior as you get in Emacs 24.5 (or earlier).  E.g., toggling
menu-bar-mode changes the height, but toggling tool-bar-mode does
not change the height.

But that compatibility does not apply to my thumbification.  That
still seems like a bug.

My code restores a set of frame parameters, but that behavior is
broken, it seems, because that particular call to
`modify-frame-parameters' has _no effect_.

It's not just that the frame height is changed by the height of
a menu-bar or not, depending on the option value.

The height is not changed _at all_ by that call, if I don't tweak
the option, and it should be changed a _lot_ (assuming you resized
the unthumbified frame to reduce the height a lot).

The `height' parameter that is being restored is apparently ignored.
My guess is that all of the parameters are being ignored - that
particular call to `modify-frame-parameters' appears to be a no-op.
That doesn't seem to follow what the option should do, regardless
of the option value.

And if you step through the debugger then it _has_ its intended
effect - the `modify-frame-parameters' call is not ignored - it
restores all of the parameters passed to it (including `height').

So I cannot think that this bug is fixed (or not a bug), but I
don't really understand all that is involved, and I will play
some more with that user option - when I get a chance.

I hope that you will investigate, following my recipe, why
that `modify-frame-parameters' call now has no effect unless
you step through the debugger.  But I can at least confirm that
the problem does indeed seem to be brought on by the code that
implements that option.

Thanks for looking into this, Martin.