[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#22105: 25.1.50; REGRESSION - `modify-frame-parameters'
From: |
Drew Adams |
Subject: |
bug#22105: 25.1.50; REGRESSION - `modify-frame-parameters' |
Date: |
Mon, 7 Dec 2015 09:00:43 -0800 (PST) |
> 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.
- bug#22105: 25.1.50; REGRESSION - `modify-frame-parameters', Drew Adams, 2015/12/07
- bug#22105: 25.1.50; REGRESSION - `modify-frame-parameters', martin rudalics, 2015/12/07
- bug#22105: 25.1.50; REGRESSION - `modify-frame-parameters',
Drew Adams <=
- bug#22105: 25.1.50; REGRESSION - `modify-frame-parameters', martin rudalics, 2015/12/08
- bug#22105: 25.1.50; REGRESSION - `modify-frame-parameters', martin rudalics, 2015/12/08
- bug#22105: 25.1.50; REGRESSION - `modify-frame-parameters', martin rudalics, 2015/12/12
- bug#22105: 25.1.50; REGRESSION - `modify-frame-parameters', Eli Zaretskii, 2015/12/12
- bug#22105: 25.1.50; REGRESSION - `modify-frame-parameters', martin rudalics, 2015/12/12