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: Mon, 23 Feb 2015 07:22:30 +0100 Message-ID: <54EAC726.8090208@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> 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 1424672603 32064 80.91.229.3 (23 Feb 2015 06:23:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 23 Feb 2015 06:23:23 +0000 (UTC) Cc: =?UTF-8?Q?=E5=BC=A0=E6=B5=B7=E5=90=9B?= , 19482@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Feb 23 07:23:10 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 1YPmQA-0002i5-98 for geb-bug-gnu-emacs@m.gmane.org; Mon, 23 Feb 2015 07:23:10 +0100 Original-Received: from localhost ([::1]:42194 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YPmQ9-0003z8-Dh for geb-bug-gnu-emacs@m.gmane.org; Mon, 23 Feb 2015 01:23:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53778) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YPmQ5-0003yq-PT for bug-gnu-emacs@gnu.org; Mon, 23 Feb 2015 01:23:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YPmQ2-0006S1-JT for bug-gnu-emacs@gnu.org; Mon, 23 Feb 2015 01:23:05 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:59762) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YPmQ2-0006Rx-FV for bug-gnu-emacs@gnu.org; Mon, 23 Feb 2015 01:23:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YPmQ2-0004PS-3i for bug-gnu-emacs@gnu.org; Mon, 23 Feb 2015 01: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: Mon, 23 Feb 2015 06: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.142467255516913 (code B ref 19482); Mon, 23 Feb 2015 06:23:02 +0000 Original-Received: (at 19482) by debbugs.gnu.org; 23 Feb 2015 06:22:35 +0000 Original-Received: from localhost ([127.0.0.1]:51001 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YPmPZ-0004Of-T1 for submit@debbugs.gnu.org; Mon, 23 Feb 2015 01:22:34 -0500 Original-Received: from mailfe05.swip.net ([212.247.154.129]:60127 helo=swip.net) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YPmPW-0004OW-MY for 19482@debbugs.gnu.org; Mon, 23 Feb 2015 01:22:31 -0500 X-T2-Spam-Status: No, hits=0.8 required=5.0 tests=BAYES_50 Original-Received: from hosdjarv.se (account mj138573@tele2.se [46.59.42.57] verified) by mailfe05.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 570542547; Mon, 23 Feb 2015 07:22:28 +0100 Original-Received: from jdvpro.hq.ismobile.com (unknown [176.57.193.190]) (Authenticated sender: jhd) by hosdjarv.se (Postfix) with ESMTPSA id 81F4C1A012C; Mon, 23 Feb 2015 06:22:28 +0000 (UTC) User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 In-Reply-To: <54EA2570.8090504@gmx.at> 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:99725 Archived-At: Hi. martin rudalics skrev den 2015-02-22 19:52: > >> IIUC FRAME_OUTER_TO_INNER_DIFF_Y is the height of title bar, tool bar > > > > Only for external toolbar. > > ... and external menubar, yes. BTW, when do we get the menu bar in the > title bar? One line less to count ... Sadly there is no standard for how to do this. Ubuntu (and others) seems to be moving to having a global menubar a'la MacOS/OSX. Then you never have to count it. I think this is semiautomatic, but I wonder if Emacs takes it into account, I'll have to test it. > > > The define has just not been updated with something like > FRAME_TOOLBAR_WIDTH: > > > > #define FRAME_OUTER_TO_INNER_DIFF_X(f) \ > > ((f)->output_data.x->x_pixels_outer_diff) > > #define FRAME_OUTER_TO_INNER_DIFF_Y(f) \ > > ((f)->output_data.x->y_pixels_outer_diff \ > > + FRAME_MENUBAR_HEIGHT (f) + FRAME_TOOLBAR_HEIGHT (f)) > > Sure. But I probably can't change it without changing its clients as > well. I'm not sure. There are only a few usages, and I think not taking toolbal width into account is probably a bug. Will check this also. > > >> And at > >> least here a maximized frame shows decorations only on two orthogonal > >> sides so the above is certainly not always correct. Do you have any > >> better ideas? > > > > You can always compute them on the fly with something similar to what > x_real_positions does and take into account the lower right corner as > well as the upper left corner. > > I don't get the borders reported separately so I always distribute the > space occupied by the one visible border among it and the non-existent > border. Not a great deal obviously, but I'm sure that mouse position > calculations are off by a few pixels in that case. > What I meant was that x_real_positions gets the upper left corner for the outer window and the inner window and calls the difference OUTER_TO_INNER_DIFF. But you can take the width/height of the outer/inner window and also calculate exactly the diff of all sides. Jan D.