From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#19482: Changing to big font cause display problem Date: Wed, 25 Feb 2015 11:33:05 +0100 Message-ID: <54EDA4E1.2060304@gmx.at> References: <54DE424B.8070506@gmx.at> <7294F8DD-9324-4872-9AAA-5E4A229EFD04@icloud.com> <54E49C26.1070209@gmx.at> <0534A31D-5D69-4687-88CE-FA3C23A20278@icloud.com> <54E58941.3030005@gmx.at> <0255489D-9FE7-4C96-850D-2ED2FC80E42B@icloud.com> <54E77B3E.4000907@gmx.at> <1C7DF283-CB55-4360-AC5B-7565305D85F8@icloud.com> <54E86FA3.6010902@gmx.at> <54E9A8CB.8070605@gmx.at> <3EDF6985-A93A-46E9-9083-C2E496AB98C1@icloud.com> <24726EFE-F45F-4F6C-8941-AA1E5457D14F@swipnet.se> <54EA0D77.7010009@gmx.at> <504DD3FF-BA56-4407-AFE6-CCAA9F90BB31@swipnet.se> <54EA2570.8090504@gmx.at> <54EAC726.8090208@swipnet.se> <7F209FD7-19DD-4F47-A8BF-98E88EC65FCB@swipnet.se> <54ED7B0F.2070101@gmx.at> <54ED93C5.7020307@swipnet.se> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1424860467 32345 80.91.229.3 (25 Feb 2015 10:34:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 25 Feb 2015 10:34:27 +0000 (UTC) Cc: 19482@debbugs.gnu.org To: "Jan D." Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Feb 25 11:34:16 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YQZID-000899-WA for geb-bug-gnu-emacs@m.gmane.org; Wed, 25 Feb 2015 11:34:14 +0100 Original-Received: from localhost ([::1]:53653 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YQZID-0005eE-C0 for geb-bug-gnu-emacs@m.gmane.org; Wed, 25 Feb 2015 05:34:13 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34439) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YQZI5-0005dD-PL for bug-gnu-emacs@gnu.org; Wed, 25 Feb 2015 05:34:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YQZI2-0002o0-FF for bug-gnu-emacs@gnu.org; Wed, 25 Feb 2015 05:34:05 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:53732) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YQZI2-0002nq-Bt for bug-gnu-emacs@gnu.org; Wed, 25 Feb 2015 05:34:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YQZI1-0002Ks-RI for bug-gnu-emacs@gnu.org; Wed, 25 Feb 2015 05:34:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 25 Feb 2015 10:34:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19482 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 19482-submit@debbugs.gnu.org id=B19482.14248604078936 (code B ref 19482); Wed, 25 Feb 2015 10:34:01 +0000 Original-Received: (at 19482) by debbugs.gnu.org; 25 Feb 2015 10:33:27 +0000 Original-Received: from localhost ([127.0.0.1]:57330 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YQZHS-0002K3-4k for submit@debbugs.gnu.org; Wed, 25 Feb 2015 05:33:26 -0500 Original-Received: from mout.gmx.net ([212.227.15.15]:53199) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YQZHP-0002Jp-FK for 19482@debbugs.gnu.org; Wed, 25 Feb 2015 05:33:24 -0500 Original-Received: from [188.22.238.206] ([188.22.238.206]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0M8edX-1XeOfz0EuB-00wCqi; Wed, 25 Feb 2015 11:33:12 +0100 In-Reply-To: <54ED93C5.7020307@swipnet.se> X-Provags-ID: V03:K0:52QGn3IekvHh6bIytweQmrIkvx60D7U3odihP4exXFZzAKxYdOZ EZ64aRFBsTOAt/mcPYUxAxCdsWBlCgHdbkp6sq55JbmXOcGs7Y2xQXCHom1gwZw5IZiBYS8 qx2uA3J/gTxFP3MfLlWi+ysuTKoImfe0PfoKw48AQUOdYktYyazVA000nsAFETrDsvFgPqc rXl3XdvLNtCuwVKJ+SaSw== X-UI-Out-Filterresults: notjunk:1; X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:99792 Archived-At: >> For the purpose of `x-frame-geometry' the outer window of a frame on X >> is the one returned by FRAME_OUTER_WINDOW. The inner window is the one >> whose size is given by FRAME_PIXEL_WIDTH and FRAME_PIXEL_HEIGHT. > > Then you should never need to bother with _OUTER_TO_INNER_DIFF. Then how do I get the size of the outer window (the size of the object returned by FRAME_OUTER_WINDOW)? >> IIUC the only problem is whether the "window manager window" does >> contain the external toolbar/mmenubar. > > It never does. It only contains the title bar. Are you sure? External menu and tool bars bars are normally in between title bar and the inner window so how can they not be counted? >> The title bar and the external >> borders are definitely part of the window manager window. > > The title bar is, but borders are not. It is entirely possible to set border on any X window, regardless of where it is in the hierarchy. > So the external borders Emacs sets is on the outmost Emacs window, not on the window manager window. Where does Emacs set external borders? Do we really control that? > You must specify what you mean by outer and > inner. I did that and it's still cited at the top of this post. > FRAME_OUTER_TO_INNER_DIFF_Y gives the diff between the outmost > Emacs created window and the window manager window. No. It's the diff between the _top edge_ of the outmost Emacs created window and that of the window manager window (using your parlance). What's missing is the diff between the _bottom edge_ of the outmost created window and that of the window manager window. >> I don't know how to get the difference between the >> bottom edge of the Emacs window and the bottom edge of the outer window. >> So I approximate. This approximation obviously goes wrong when the left >> and bottom borders are not the same size. Can you tell me a better way? > > As I said, I'm implementing this. But it seems you don't need this. > If you are only interested in the size of the Emacs created outmost > window, OUTER_TO_INNER_DIFF does not apply. I am interested in the size of the "window manager window". > Only borders do. I also need title bar, external tool and menu bar. >> > So what you have calculated is not the window manager window sizes, >> > because inner_to_outer width is not taken into account. >> >> FRAME_OUTER_TO_INNER_DIFF_X gives me the offset of the left edge of the >> inner window wrt the outer window. > > Again, define inner and outer. We are using confusing terminology. > I suggest > window manager window > Outmost Emacs created window. > Inner Emacs created window. The last one is not needed in this discussion. Can we agree that your "window manager window" is the one returned by FRAME_OUTER_WINDOW? And that the "outmost Emacs created window" is the one whose sizes are specified by FRAME_PIXEL_WIDTH and FRAME_PIXEL_HEIGHT? If so, then "outer window" is equivalent to "window manager window" and "inner window" is equivalent to "outmost Emacs created window" >> Are you sure? Does FRAME_OUTER_TO_INNER_DIFF_X not include the extra 10 >> pixels you mentioned above? > > Yes they do. Then my calculation should handle this case (and obviously seems to fail for the external border at the bottom of such a frame). >> That would be devastating. Scroll bars are part of the inner window. > > Not in the X sense, they are attached to the outmost Emacs created > window. Thats one of the reasons we have that window, the other is > external menubar and external tool bar. But their size is counted in the "inner window" aka "outmost Emacs created window". Otherwise we could not really handle a frame with side-by-side windows where two or more scrollbars would have to be counted. > Only Emacs native scrollbar are attached to the inner Emacs window, I fail to understand you. IMHO all scrollbars are attached to the "inner window". Scrollbars are part of an Emacs "window" not of an Emacs "frame" on graphical systems. To my knowledge, external scroll bars exist only when embedding the Emacs frame somewhere else, for example, on a terminal. > as well as non-external (i.e. text) menu and non-external toolbar. These are part of the inner window. > But for frame-inner-size you subtract menu and tool bar. So this is > not the size of the largest Emacs created window. You're right. What I earlier said about the value of 'frame-inner-size' was probably misleading. Let's forget about 'frame-inner-size' for the moment, it's too confusing. > What are you doing with these sizes? Give applications a possibility to calculate the maximimum size of a frame so that it remains entirely visible within the work area of its display. This could be used, for example, to guarantee that setting the default font doesn't make a frame larger than the display. Also I want the sizes of external tool and menu bar for debugging things like the various maximized/fullsize variants. martin