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 20:17:53 +0100 Message-ID: <866CADAE-2B20-42FF-BCAB-E5D9DFAA4AFD@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> 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 1424891964 14817 80.91.229.3 (25 Feb 2015 19:19:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 25 Feb 2015 19:19:24 +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 20:19:14 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 1YQhUG-0003Ly-42 for geb-bug-gnu-emacs@m.gmane.org; Wed, 25 Feb 2015 20:19:12 +0100 Original-Received: from localhost ([::1]:56036 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YQhUF-0001tH-Hc for geb-bug-gnu-emacs@m.gmane.org; Wed, 25 Feb 2015 14:19:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40628) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YQhUB-0001rU-AU for bug-gnu-emacs@gnu.org; Wed, 25 Feb 2015 14:19:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YQhU6-0000yr-9r for bug-gnu-emacs@gnu.org; Wed, 25 Feb 2015 14:19:07 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:54469) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YQhU6-0000yj-6A for bug-gnu-emacs@gnu.org; Wed, 25 Feb 2015 14:19:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YQhU5-0001X3-No for bug-gnu-emacs@gnu.org; Wed, 25 Feb 2015 14:19:01 -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 19:19: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.14248918865820 (code B ref 19482); Wed, 25 Feb 2015 19:19:01 +0000 Original-Received: (at 19482) by debbugs.gnu.org; 25 Feb 2015 19:18:06 +0000 Original-Received: from localhost ([127.0.0.1]:58067 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YQhTB-0001Vn-A9 for submit@debbugs.gnu.org; Wed, 25 Feb 2015 14:18:06 -0500 Original-Received: from mailfe03.swip.net ([212.247.154.65]:34012 helo=swip.net) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YQhT8-0001VG-0b for 19482@debbugs.gnu.org; Wed, 25 Feb 2015 14:18:03 -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 mailfe03.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 409347121; Wed, 25 Feb 2015 20:17:53 +0100 In-Reply-To: <384E8844-0873-4204-89D0-A120E94683C9@swipnet.se> 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:99822 Archived-At: Hi. I redid the whole INNER_TO_OUTER thing, and now handle all sides. The macros INNER_TO_OUTER are removed. Jan D. > 25 feb 2015 kl. 19:25 skrev Jan D. : >=20 >=20 >> 25 feb 2015 kl. 18:33 skrev martin rudalics : >>=20 >>>> Then how do I get the size of the outer window (the size of the = object >>>> returned by FRAME_OUTER_WINDOW)? >>>>=20 >>>=20 >>> There is a difference between FRAME_OUTER_WINDOW and the window = manager window. The window manager window is outside = FRAME_OUTER_WINDOW, and its parent. >>> OUTER_TO_INNER gives the diff between the window manager window and = FRAME_OUTER_WINDOW. The size of FRAME_OUTER_WINDOW is = FRAME_PIXEL_WIDTH/HEIGHT + borders. >>=20 >> With "borders" you mean external borders, I presume. >=20 > Yes. >=20 >> So in >>=20 >> #define FRAME_OUTER_TO_INNER_DIFF_Y(f) \ >> ((f)->output_data.x->y_pixels_outer_diff \ >> + FRAME_MENUBAR_HEIGHT (f) + FRAME_TOOLBAR_HEIGHT (f)) >>=20 >> 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? >=20 > 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 >> And this >>=20 >> /* 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; >>=20 >> 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 > 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 >>=20 >>>>>> IIUC the only problem is whether the "window manager window" does >>>>>> contain the external toolbar/mmenubar. >>>>>=20 >>>>> It never does. It only contains the title bar. >>>>=20 >>>> Are you sure? >>>=20 >>> Like a gazillion percent sure. >>=20 >> OK. Then we apparently have the following misunderstanding. You = seem >> to say that the window manager window does not contain the Emacs = outer >> window but only the title bar. >=20 > No, the window manager contains them both, the title bar above Emacs = outer window. >=20 >> I say that the window manager window >> contains the title bar and the Emacs outer window. >=20 > Right. >=20 >>=20 >>>> External menu and tool bars bars are normally in between >>>> title bar and the inner window so how can they not be counted? >>>=20 >>> --------------------------------------------------------- >>> | Window manager window, title bar >>> | -------------------------------------------------------- >>> | | Emacs outer window, menu bar >>> | | tool bar >>> | | ------------------------------------------------------ >>> | | | Emacs inner window, text and scrollbar >>> | | | >>>=20 >>=20 >> We're probably meaning the same thing but you do not include nested >> windows, so for you the Emacs inner window is not part of the Emacs >> outer window. >=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. >=20 > It is a containment relationship. Ithe inner window is contained = inside the outer window. > The outer window is contained inside the window manager window. >=20 >> 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? >=20 > 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 >>=20 >>> Things get more complicated for when Emacs is compiled without a >>> toolkit (i.e. non-external menu bar) or the non-external toolbar. = For >>> the no toolkit case, there is no Emacs outer window. >>=20 >> But it's still where the internal borders are? >=20 > They are in the inner window. >=20 >>=20 >>>> I also need title bar, external tool and menu bar. >>>=20 >>> Please note that a window manager window is just one way a window >>> manager can set a title bar. There are other ways, esp. for = composite >>> managers, and (I guess) Wayland. In these cases, there is no way we >>> can know the size of the title bar. >>=20 >> Then we can do nothing in these cases. >=20 > Right. >=20 >>=20 >>>> 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. >>>>=20 >>>=20 >>> This is a job for the window manager. Some window managers = constrain the size of Emacs, some do not. >>=20 >> If I deliberately set the frame size to some large value, there's >> obviously no reason to constrain that. But if I increase the default >> font I'd probably want my frame stay within the bounds of the = display. >=20 > Some window managers already do that for you. >=20 >> At least the behavior described by the OP where the frame's height is >> constrained by the display while the width isn't doesn't sound very >> reasonable. >>=20 >>> Also, you do need to take into account things like panels that the >>> desktop can contain, and handle the fact that the panels may be >>> different on different workspaces and monitors. Are you handling = the >>> case when Emacs is too high for one monitor but there is another >>> monitor below that shows the rest? Are you handling the same case, >>> but this time the monitor below shows a different workspace and the >>> rest is not shown below? >>=20 >> No. We already do not everywhere handle these cases correctly. But = my >> restriction would be "safe" in the sense that my frame's size would >> never exceed that of the frame we produce currently. >=20 > Then how do you allow for spanning between monitors? >=20 >>=20 >>> This is really a window manager function, we should not have it in >>> Emacs at all. If someone sets a font so large that Emacs is not = fully >>> visible, let them. Tell them to get another window manager if they >>> want Emacs constrained. And how do we know what the user wants? >>> Someone might not want Emacs constrained (for example I don't). >>=20 >> The OP proposed an option to do that. >=20 > Jan D. >=20 >=20 >=20 >=20