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

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

[Harold Pimentel]

Hi,

I'm having an issue with set-frame-font. It is as follows:

- I use:
	(set-frame-font "Menlo-12")
- 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

Any insight would be great.

Here is my system info:

- Mac OSX (10.6.6)
- Emacs.app 23.2.1 (via Macports, but also verified on the latest build of 23.3 build 03-10)




Thanks,

Harold

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

[martin rudalics]

 > 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

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

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

[martin rudalics]

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

It should also work to set `split-height-threshold' to nil in your case.

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

Do you mean that

   (set-frame-font "Menlo-12" t)

resizes the frame as

   (set-frame-font "Menlo-12")

does?  Or do you mean that with a non-maximized frame splitting doesn't
occur irrespective of the font chosen?

martin