From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Jan D." Newsgroups: gmane.emacs.bugs Subject: bug#19482: Changing to big font cause display problem Date: Wed, 25 Feb 2015 21:22:48 +0100 Message-ID: <0EC97186-BC13-4ABB-A86C-B1AA5287748B@swipnet.se> 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> <54EE1BE2.2060008@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1424895990 30139 80.91.229.3 (25 Feb 2015 20:26:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 25 Feb 2015 20:26:30 +0000 (UTC) Cc: 19482@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Feb 25 21:26:20 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 1YQiUE-0002VD-5c for geb-bug-gnu-emacs@m.gmane.org; Wed, 25 Feb 2015 21:23:14 +0100 Original-Received: from localhost ([::1]:56247 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YQiUD-0007AE-E7 for geb-bug-gnu-emacs@m.gmane.org; Wed, 25 Feb 2015 15:23:13 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50795) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YQiU8-00079Q-HR for bug-gnu-emacs@gnu.org; Wed, 25 Feb 2015 15:23:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YQiU3-00081j-HV for bug-gnu-emacs@gnu.org; Wed, 25 Feb 2015 15:23:08 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:54473) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YQiU3-00081d-DQ for bug-gnu-emacs@gnu.org; Wed, 25 Feb 2015 15:23:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YQiU2-0002yv-3b for bug-gnu-emacs@gnu.org; Wed, 25 Feb 2015 15:23:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: "Jan D." Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 25 Feb 2015 20:23: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.142489578111449 (code B ref 19482); Wed, 25 Feb 2015 20:23:02 +0000 Original-Received: (at 19482) by debbugs.gnu.org; 25 Feb 2015 20:23:01 +0000 Original-Received: from localhost ([127.0.0.1]:58071 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YQiU0-0002ya-4n for submit@debbugs.gnu.org; Wed, 25 Feb 2015 15:23:00 -0500 Original-Received: from mailfe01.swip.net ([212.247.154.1]:43847 helo=swip.net) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YQiTw-0002yI-EZ for 19482@debbugs.gnu.org; Wed, 25 Feb 2015 15:22:58 -0500 X-T2-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00 Original-Received: from hosdjarv.se (account mj138573@tele2.se [46.59.42.57] verified) by mailfe01.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 563905039; Wed, 25 Feb 2015 21:22:49 +0100 In-Reply-To: <54EE1BE2.2060008@gmx.at> X-Mailer: Apple Mail (2.2070.6) 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:99823 Archived-At: Hi. > 25 feb 2015 kl. 20:00 skrev martin rudalics : >=20 > >> 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. >=20 > 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. Yes, but it is buggy as it does not take into accout the case of the = tool bar at the bottom. >=20 > > > >> 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? > > >=20 > > 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). >=20 > 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. Yes. >=20 > > 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. >=20 > And how does this differ from FRAME_OUTER_TO_INNER_DIFF_Y? I don't know, I think they would be the same. >=20 > > 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. >=20 > That's confusing. OT1H they are part of the outer window and OTOH = they > are drawn around the window manager window. No, the border is drawn around the outer window. > This makes nesting > impossible. That is, the Emacs outer window cannot be contained in = the > windows manager window The only purpose for a window manager windon is to contain other = applications top level windows. >=20 > >> But it's still where the internal borders are? > > > > They are in the inner window. >=20 > But we don't count them in `frame-text-height'. Ok. That makes sense though, the inner border is not text. >=20 > > Then how do you allow for spanning between monitors? >=20 > 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. But if you want to span when the second monitor is connected, but = constrain when there is only one? There are so many corner cases here. There will be bug reports if Emacs = tries to constrain stuff. The only one that has the full picture is the window manager, so it is = its job, not Emacs. Jan D.