all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: martin rudalics <rudalics@gmx.at>, 22105@debbugs.gnu.org
Subject: bug#22105: 25.1.50; REGRESSION - `modify-frame-parameters'
Date: Mon, 7 Dec 2015 09:00:43 -0800 (PST)	[thread overview]
Message-ID: <2b37d302-b956-48e6-98d0-fc116af6e684@default> (raw)
In-Reply-To: <566560E2.4010204@gmx.at>

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





  reply	other threads:[~2015-12-07 17:00 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-07  6:03 bug#22105: 25.1.50; REGRESSION - `modify-frame-parameters' Drew Adams
2015-12-07 10:35 ` martin rudalics
2015-12-07 17:00   ` Drew Adams [this message]
2015-12-08  9:17     ` martin rudalics
2015-12-08 14:07       ` martin rudalics
2015-12-12 10:44         ` martin rudalics
2015-12-12 10:59           ` Eli Zaretskii
2015-12-12 13:46             ` martin rudalics
2016-04-30 22:29               ` Lars Ingebrigtsen
2016-05-01  1:26                 ` Drew Adams
2019-08-08  4:07 ` Stefan Kangas
2019-08-08 15:18   ` Drew Adams
2020-09-07 16:28     ` Lars Ingebrigtsen
2020-09-07 16:35       ` Eli Zaretskii
     [not found]     ` <<87sgbt5z63.fsf@gnus.org>
     [not found]       ` <<83y2llmtn7.fsf@gnu.org>
2020-09-07 17:11         ` Drew Adams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2b37d302-b956-48e6-98d0-fc116af6e684@default \
    --to=drew.adams@oracle.com \
    --cc=22105@debbugs.gnu.org \
    --cc=rudalics@gmx.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.