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

[Harold Pimentel]

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

Yes. The frame appears to be shorter and a few columns more narrow.

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

You are correct! When I set split-height-threshold to a large value, I get the 
original, expected behavior.

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

I could not verify this. I.e., when calling (set-frame-font "Menlo-12" t), I 
get the same behavior as before.



Thanks for your help,

Harold