bug#8242: Issue with help menu and set-frame-font

[martin rudalics <rudalics@gmx.at>]

 > I'm having an issue with set-frame-font. It is as follows:
 >
 > - I use:
 > 	(set-frame-font "Menlo-12")

Doesn't this already change the (pixel-)size of the frame?

 > - I split the current frame into two windows
 > - If I raise the help menu it goes into the opposite window, changing that buffer (this is normal)
 > - I maximize my window
 > 	- I was using maximize-frame.el, but simply making the window as large as possible until it "clicks" will suffice
 > - Now, if raise the help menu, it splits the current window vertically instead of putting the help into the other window (BUG HERE)
 > 	- If I don't change the font, I will not have this issue

Large parts of Emacs think in terms of lines and columns.  So what
happens in my opinion is that with the default (larger, I presume) frame
font less lines fit on one frame of the same pixel height than with the
Menlo-12 font you want to use.

If you invoke `set-frame-font' with the second argument nil, Emacs will
usually adjust the frame's pixel height in order to make it occupy the
same number of lines as with the previously used font.  Hence, a
subsequent check whether a window can be split fails just as if you
hadn't changed the font at all, so an existing window gets reused.

But if you maximize the frame, then with the Menlo-12 font _more_ lines
may fit into a window than with the original font.  So when you invoke
help in the maximized frame, the test (via `split-height-threshold')
whether an existing window can be split succeeds and a new window gets
popped up.

If you invoke `set-frame-font' with the second argument non-nil, Emacs
should keep the (non-maximized) frame pixel height constant and you
should be able to observe the splitting behavior with a non-maximized
frame as well.

Could you try to verify these my suppositions?

martin