GNU bug report logs - #19482
Changing to big font cause display problem

Previous Next

Full log

View this message in rfc822 format

From: martin rudalics <rudalics <at> gmx.at>
To: 张海君 <netjune <at> icloud.com>
Cc: 19482 <at> debbugs.gnu.org
Subject: bug#19482: Changing to big font cause display problem
Date: Sun, 22 Feb 2015 11:00:43 +0100

> I like the following behavior:
> When setting font, emacs changes frame's size, but the new size is adjusted to keep the whole frame visible.
> This is more useful.

It's far from trivial to accomplish though.  Suppose you have some frame
sizes H1xV1 and a default font size F1.  Now you change the default font
to F2 and would get the relative sizes H2xV2 where, however, V2 exceeds
the size of your display.  So we adjust V2 (and maybe H2 as well) to fit
the frame into your display.  Next you change the font size back to F1
and probably expect to get the initial sizes H1 and V1 back.  But the
frame sizing code doesn't remember them ...

I do something comparable in the windows code where I maintain for each
window a nominal size (retrievable via `window-normal-size') but dislike
the associated maintenance burden profoundly.

And a final touch: On X and Windows I have a function called
`x-frame-geometry' which, far from perfect, allows to retrieve the sizes
of the part of a frame not managed by Emacs.  I don't have such a
function for the ns part of Emacs.  But to tell whether a frame can be
embedded into a display I need to know the size of the display and the
sizes of the decorations added by the window manager.  Could you write
such a function for ns?

> - After setting font:
> There's one frame. Frame's height didn't exceed height of display. So I could see both the frame' title and the echo area.
> Frame' width exceeded width of display. I could see the upper left corner, but not the right border of the frame.

This contradicts what you said earlier, namely

  ----------------------------- (2) after issuing (set-frame-font "Menlo:size=30") ----------------------
  frame pixel: 1552 x 1194   cols/lines: 86 x 35   units: 18 x 34
  frame text pixel: 1530 x 1190   cols/lines: 85 x 35
  tool: 0  scroll: 0  fringe: 18  border: 2  right: 0  bottom: 0

and

  My screen resolution is 1440x900.

1194 is certainly larger than 900 so you should either not see the title
bar or not see the echo area.  Can you clarify this issue?  Some strange
things seem to happen on Mac OS X.

> - When "maximize the frame and then restore its normal size":
> Frame's width changed too much. Frame's height changed slightly(less than height of one text line).
>
> Dumped results:
> ------------------- maximized -------------------------------
> frame pixel: 1392 x 840   cols/lines: 77 x 24   units: 18 x 34
> frame text pixel: 1370 x 836   cols/lines: 76 x 24
> tool: 0  scroll: 0  fringe: 18  border: 2  right: 0  bottom: 0
>
> #<window 3 on *scratch*>   parent: nil
> pixel left: 0   top: 0   size: 1388 x 802   new: 802
> char left: 0   top: 0   size: 77 x 23   new: 21
> normal: 1.0 x 1.0   new: nil
> body pixel: 1370 x 769   char: 76 x 22
> width left fringe: 9  left margin: 0  right margin: 0
> width right fringe: 9  scroll-bar: 0  divider: 0
> height header-line: 0  mode-line: 33  divider: 0
>
> #<window 4 on  *Minibuf-0*>   parent: nil
> pixel left: 0   top: 802   size: 1388 x 34   new: 0
> char left: 0   top: 23   size: 1388 x 1   new: 1
> normal: 1.0 x 1.0   new: ignore
> body pixel: 1370 x 34   char: 76 x 1
> width left fringe: 9  left margin: 0  right margin: 0
> width right fringe: 9  scroll-bar: 0  divider: 0
> height header-line: 0  mode-line: 0  divider: 0
>
> ------------------- restored ----------------------------
> frame pixel: 1554 x 840   cols/lines: 86 x 24   units: 18 x 34

And this seems to confirm what I said above: Restoring doesn't restore
the previous height which should be 1194 but keeps the frame maximized
vertically.  This seems to be an idiosyncrasy of the Mac OS code and we
should either find some reference (on the Web) where this behavior is
described or some Mac OS expert reading this would be so kind to help us
in this regard.

> frame text pixel: 1532 x 836   cols/lines: 85 x 24
> tool: 0  scroll: 0  fringe: 18  border: 2  right: 0  bottom: 0
>
> #<window 3 on *scratch*>   parent: nil
> pixel left: 0   top: 0   size: 1550 x 802   new: 646
> char left: 0   top: 0   size: 86 x 23   new: 33
> normal: 1.0 x 1.0   new: nil
> body pixel: 1532 x 769   char: 85 x 22
> width left fringe: 9  left margin: 0  right margin: 0
> width right fringe: 9  scroll-bar: 0  divider: 0
> height header-line: 0  mode-line: 33  divider: 0
>
> #<window 4 on  *Minibuf-0*>   parent: nil
> pixel left: 0   top: 802   size: 1550 x 34   new: 0
> char left: 0   top: 23   size: 1550 x 1   new: 1
> normal: 1.0 x 1.0   new: ignore
> body pixel: 1532 x 34   char: 85 x 1
> width left fringe: 9  left margin: 0  right margin: 0
> width right fringe: 9  scroll-bar: 0  divider: 0
> height header-line: 0  mode-line: 0  divider: 0
> ---------------------------------------------------------------------
>
> Emacs changes its frame size when setting font, but the frame size may be limited by window manager or something else.

Indeed.  The problem is to find out what the limits are.

> So the frame's real size is not expected as emacs. Here emacs may get the real size and use the real size.

Emacs should get the size eventually.  If you tried one of the Emacs 25
"nightlies", you should be able to find a variable called
`frame-size-history' there.  We could use that variable to trace back
the OS request and find out why Emacs doesn't process it correctly.

But still note: Even if we can trace this problem and solve it, the
problem remains that the frame's proportions are distorted by the
request and there's hardly a chance to get back the initial frame size
when you switch back to the initial font size.

martin

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.