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

Previous Next

Full log

View this message in rfc822 format

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

> 在 2015年2月22日，18:00，martin rudalics <rudalics <at> gmx.at> 写道：
> 
> 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 ...
> 
To me, I don't care about the initial sizes H1 and V1. Just try to keep the *current* columns and lines.
Maybe we can add a new value like 'smart to the variable frame-inhibit-implied-resize.

> 
> 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?
> 
Sorry, I'm not familiar with object-c. I'm just a basic user of Mac.


> 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.
That's the fact. Emacs doesn't know the real size of frame and is using a wrong frame size.
This must be the cause of the display problem.


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

> 
> 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.
I will try the Emacs 25.

Previous Next

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