From: 张海君 <netjune@icloud.com>
To: martin rudalics <rudalics@gmx.at>
Cc: 19482@debbugs.gnu.org
Subject: bug#19482: Changing to big font cause display problem
Date: Sun, 22 Feb 2015 18:54:51 +0800 [thread overview]
Message-ID: <3EDF6985-A93A-46E9-9083-C2E496AB98C1@icloud.com> (raw)
In-Reply-To: <54E9A8CB.8070605@gmx.at>
> 在 2015年2月22日,18:00,martin rudalics <rudalics@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.
next prev parent reply other threads:[~2015-02-22 10:54 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-01 15:21 bug#19482: Changing to big font cause display problem 张海君
2015-02-13 18:28 ` martin rudalics
2015-02-18 11:19 ` 张海君
2015-02-18 14:05 ` martin rudalics
2015-02-19 1:59 ` 张海君
2015-02-19 6:57 ` martin rudalics
2015-02-20 10:23 ` 张海君
2015-02-20 18:21 ` martin rudalics
2015-02-21 1:33 ` 张海君
2015-02-21 11:44 ` martin rudalics
2015-02-22 2:57 ` 张海君
2015-02-22 10:00 ` martin rudalics
2015-02-22 10:54 ` 张海君 [this message]
2015-02-22 11:32 ` martin rudalics
2015-02-22 12:27 ` 张海君
2015-02-22 17:09 ` martin rudalics
2015-02-23 2:11 ` 张海君
2015-02-22 16:27 ` Jan D.
2015-02-22 17:10 ` martin rudalics
2015-02-22 17:43 ` Jan D.
2015-02-22 18:52 ` martin rudalics
2015-02-23 6:22 ` Jan D.
2015-02-24 19:09 ` Jan D.
2015-02-25 7:34 ` martin rudalics
2015-02-25 9:20 ` Jan D.
2015-02-25 10:33 ` martin rudalics
2015-02-25 15:27 ` Jan D.
2015-02-25 17:33 ` martin rudalics
2015-02-25 18:25 ` Jan D.
2015-02-25 19:00 ` martin rudalics
2015-02-25 20:22 ` Jan D.
2015-02-27 8:30 ` martin rudalics
2015-02-27 17:49 ` Jan D.
2015-02-25 19:17 ` Jan D.
2015-02-27 8:30 ` martin rudalics
2015-02-27 17:52 ` Jan D.
2015-02-27 19:49 ` martin rudalics
2015-02-27 20:29 ` Jan D.
2015-03-01 15:14 ` martin rudalics
2015-03-01 16:18 ` Jan D.
2015-03-10 14:36 ` 张海君
2015-03-10 18:47 ` martin rudalics
2015-03-12 5:14 ` Jan D.
2015-03-12 10:13 ` martin rudalics
2015-03-12 16:52 ` Eli Zaretskii
2015-03-12 18:21 ` Jan D.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3EDF6985-A93A-46E9-9083-C2E496AB98C1@icloud.com \
--to=netjune@icloud.com \
--cc=19482@debbugs.gnu.org \
--cc=rudalics@gmx.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).