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 20:00:50 +0100 Message-ID: <54EE1BE2.2060008@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> <54EDA4E1.2060304@gmx.at> <54EE0767.1090407@gmx.at> <384E8844-0873-4204-89D0-A120E94683C9@swipnet.se> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1424890955 27280 80.91.229.3 (25 Feb 2015 19:02:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 25 Feb 2015 19:02:35 +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 20:02:24 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 1YQhDl-0000kV-Ox for geb-bug-gnu-emacs@m.gmane.org; Wed, 25 Feb 2015 20:02:10 +0100 Original-Received: from localhost ([::1]:55973 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YQhDl-0006cC-9y for geb-bug-gnu-emacs@m.gmane.org; Wed, 25 Feb 2015 14:02:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37289) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YQhDh-0006TY-II for bug-gnu-emacs@gnu.org; Wed, 25 Feb 2015 14:02:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YQhDe-00048M-CY for bug-gnu-emacs@gnu.org; Wed, 25 Feb 2015 14:02:05 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:54465) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YQhDe-00048I-A9 for bug-gnu-emacs@gnu.org; Wed, 25 Feb 2015 14:02:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YQhDe-00019J-4G for bug-gnu-emacs@gnu.org; Wed, 25 Feb 2015 14:02:02 -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 19:02:02 +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.14248908734359 (code B ref 19482); Wed, 25 Feb 2015 19:02:02 +0000 Original-Received: (at 19482) by debbugs.gnu.org; 25 Feb 2015 19:01:13 +0000 Original-Received: from localhost ([127.0.0.1]:58063 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YQhCq-00018E-F6 for submit@debbugs.gnu.org; Wed, 25 Feb 2015 14:01:12 -0500 Original-Received: from mout.gmx.net ([212.227.17.21]:64020) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YQhCo-00017z-4y for 19482@debbugs.gnu.org; Wed, 25 Feb 2015 14:01:10 -0500 Original-Received: from [188.22.238.206] ([188.22.238.206]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MEbYb-1YKNXP16TZ-00Fh3g; Wed, 25 Feb 2015 20:00:58 +0100 In-Reply-To: <384E8844-0873-4204-89D0-A120E94683C9@swipnet.se> X-Provags-ID: V03:K0:JWfsMc0YAkdFdiw6Qh70UgnMBBnM0BuyZ1ZQswEBKJjxThLjHff 7HvutNElQ1A2eZgNCzPZ/GL7KM4cr4o/Tn3fZkm2yoJKBywugUAQlM4qCdS89EIxkUua7s3 EJa5JvqkyVp3oNfvVc+YQbQ2Qgyl5uWao87Tw9KfUpYCvXnLMa+r+9d25xkxWKRUQkzvvlJ sX62gWoyF7NpGspDNc5hQ== 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:99821 Archived-At: >> So in >> >> #define FRAME_OUTER_TO_INNER_DIFF_Y(f) \ >> ((f)->output_data.x->y_pixels_outer_diff \ >> + FRAME_MENUBAR_HEIGHT (f) + FRAME_TOOLBAR_HEIGHT (f)) >> >> we calculate the height difference of the Emacs outer window and the >> Emacs inner window where y_pixels_outer_diff in this context stands for >> the external border only. Correct? > > No. As currently defined, this is the difference at the top, so it > includes the title bar if any. Also, I said the Gnome 3 window manager > puts a 10 pixel area for shading purposes. y_pixels_outer_diff > contains these 10 pixels + borders. Window managers may put extra > decorations around a window, those are also included. Only if the > window manager adds nothing to the sides, and there is no title bar > does y_pixels_outer_diff represent the border only. OK. This is what I assumed initially. So this macro specifies the distance of the top of the Emacs inner window from the top of the window manager window. > >> And this >> >> /* These many pixels are the difference between the outer window (i.e. the >> left and top of the window manager decoration) and FRAME_X_WINDOW. */ >> int x_pixels_diff, y_pixels_diff; >> >> is misleading because "outer window" here is not the same as >> "FRAME_OUTER_WINDOW". So I'm still not sure: What do >> y_pixels_outer_diff and y_pixels_diff typically stand for? > > y_pixels_outer_diff is typically the title bar height + the external > border. Nowdays there are few window managers that add decorations at > the top except the title bar, but if they did, it would be added here > (like the 10 pixel shading area). So this is the distance of the top of the Emacs outer window from the top of the window manager window plus the external border. > y_pixels_diff is the offsets to the FRAME_X_WINDOW, not the > FRAME_OUTER_WINDOW. For the case with external menu bar and external > tool bar at the top, y_pixels_diff is y_pixels_outer_diff + menu bar > height + tool bar height. If there are no tool bar or menu bar, then > they become the same. And how does this differ from FRAME_OUTER_TO_INNER_DIFF_Y? > I do include nested windows in the picture above. The inner window is nested inside the outer window, which in turn is nested inside the window manager window. > > It is a containment relationship. Ithe inner window is contained inside the outer window. > The outer window is contained inside the window manager window. > >> Now where do the external borders go in this drawing? I >> considered them part of the window manager window. You apparently >> consider them part of the Emacs outer window. Right? > > In X speak they are part of the outer window. X handles external > borders separate from windows, so you specify both width/height and > border width when you create a window. They are part of the outer > window, because if you kill the window manager and run without any > window manager, the borders are still there. That's confusing. OT1H they are part of the outer window and OTOH they are drawn around the window manager window. This makes nesting impossible. That is, the Emacs outer window cannot be contained in the windows manager window >> But it's still where the internal borders are? > > They are in the inner window. But we don't count them in `frame-text-height'. > Then how do you allow for spanning between monitors? You mean someone who increases the default font would expect the frame to span a second monitor. That person would have to set the option in a way that it doesn't constrain the frame's size. martin