From unknown Tue Aug 19 09:32:06 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#19482 <19482@debbugs.gnu.org> To: bug#19482 <19482@debbugs.gnu.org> Subject: Status: Changing to big font cause display problem Reply-To: bug#19482 <19482@debbugs.gnu.org> Date: Tue, 19 Aug 2025 16:32:06 +0000 retitle 19482 Changing to big font cause display problem reassign 19482 emacs submitter 19482 =E5=BC=A0=E6=B5=B7=E5=90=9B severity 19482 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 01 13:51:22 2015 Received: (at submit) by debbugs.gnu.org; 1 Jan 2015 18:51:23 +0000 Received: from localhost ([127.0.0.1]:34631 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y6kqA-0000Qw-Dx for submit@debbugs.gnu.org; Thu, 01 Jan 2015 13:51:22 -0500 Received: from eggs.gnu.org ([208.118.235.92]:38418) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y6hZe-000138-Rb for submit@debbugs.gnu.org; Thu, 01 Jan 2015 10:22:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y6hZd-0007s5-RZ for submit@debbugs.gnu.org; Thu, 01 Jan 2015 10:22:06 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: **** X-Spam-Status: No, score=4.0 required=5.0 tests=BAYES_50, CHARSET_FARAWAY_HEADER autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:42374) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y6hZd-0007s1-PC for submit@debbugs.gnu.org; Thu, 01 Jan 2015 10:22:05 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40133) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y6hZd-0003lK-0v for bug-gnu-emacs@gnu.org; Thu, 01 Jan 2015 10:22:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y6hZY-0007rI-3L for bug-gnu-emacs@gnu.org; Thu, 01 Jan 2015 10:22:04 -0500 Received: from st13p27im-asmtp002.me.com ([17.162.190.64]:33871) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y6hZX-0007r5-Vv for bug-gnu-emacs@gnu.org; Thu, 01 Jan 2015 10:22:00 -0500 Received: from [192.168.1.129] (unknown [218.109.253.212]) by st13p27im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.33.0 64bit (built Aug 27 2014)) with ESMTPSA id <0NHI00M4580G4V40@st13p27im-asmtp002.me.com> for bug-gnu-emacs@gnu.org; Thu, 01 Jan 2015 15:21:57 +0000 (GMT) From: =?gb2312?B?1cW6o779?= Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Subject: Changing to big font cause display problem Message-id: Date: Thu, 01 Jan 2015 23:21:50 +0800 To: bug-gnu-emacs@gnu.org MIME-version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68,1.0.33,0.0.0000 definitions=2015-01-01_06:2014-12-31,2015-01-01,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=1 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1412080000 definitions=main-1501010161 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Thu, 01 Jan 2015 13:51:21 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.0 (----) Open emacs, and run the following code: (set-frame-font "Menlo:size=3D30") Then text in "*scratch*" buffer disappeared and I can't make the text = visible with scrolling up or down. After resizing Emacs's window size, text is visible. It seems that after changing font size Emacs doesn't known the real = window size and so can't display correctly. From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 13 13:28:44 2015 Received: (at 19482) by debbugs.gnu.org; 13 Feb 2015 18:28:44 +0000 Received: from localhost ([127.0.0.1]:42150 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YMKyp-0000Cf-Uc for submit@debbugs.gnu.org; Fri, 13 Feb 2015 13:28:44 -0500 Received: from mout.gmx.net ([212.227.17.22]:57539) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YMKyo-0000CT-5S for 19482@debbugs.gnu.org; Fri, 13 Feb 2015 13:28:42 -0500 Received: from [88.117.117.6] ([88.117.117.6]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MYtId-1Y8qRD1LTX-00VdS5; Fri, 13 Feb 2015 19:28:36 +0100 Message-ID: <54DE424B.8070506@gmx.at> Date: Fri, 13 Feb 2015 19:28:27 +0100 From: martin rudalics MIME-Version: 1.0 To: =?UTF-8?B?5byg5rW35ZCb?= , 19482@debbugs.gnu.org Subject: Re: bug#19482: Changing to big font cause display problem References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:6hmPztTnS/Kg7Pa+S6SN6RTh8OuMrih7VjDflTg5H+xR2jg1ACk wE9Ay32uvB2KYSRqhTEOhvA4odz+GKw59nKdFX5UI9IE0IKxTqNPcaT6if4UpVCrHqVPLSd V3pHtAQYgL3JbZig4OTpqCVUuJSGQqEfU8GvXvEbJinyBpKYHv0Grxf1UhOSEVvQoLF4Pqf fxB0wyx4gMbw4oef3tbCA== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 19482 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) > Open emacs, and run the following code: > (set-frame-font "Menlo:size=30") > > Then text in "*scratch*" buffer disappeared and I can't make the text visible with scrolling up or down. > After resizing Emacs's window size, text is visible. > > It seems that after changing font size Emacs doesn't known the real window size and so can't display > correctly. Can you still see this? If so please tell us which version of Emacs you use and how you built it. Thanks, martin From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 18 06:20:46 2015 Received: (at 19482) by debbugs.gnu.org; 18 Feb 2015 11:20:46 +0000 Received: from localhost ([127.0.0.1]:46961 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YO2gQ-0000NY-0M for submit@debbugs.gnu.org; Wed, 18 Feb 2015 06:20:46 -0500 Received: from st13p27im-asmtp002.me.com ([17.162.190.64]:37645) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YO2gN-0000NL-Iz for 19482@debbugs.gnu.org; Wed, 18 Feb 2015 06:20:44 -0500 Received: from [192.168.1.109] (unknown [58.101.97.252]) by st13p27im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Dec 4 2014)) with ESMTPSA id <0NJY00CM3SU8A040@st13p27im-asmtp002.me.com> for 19482@debbugs.gnu.org; Wed, 18 Feb 2015 11:20:36 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68,1.0.33,0.0.0000 definitions=2015-02-18_04:2015-02-18,2015-02-18,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1412110000 definitions=main-1502180121 Content-type: text/plain; charset=gb2312 MIME-version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: bug#19482: Changing to big font cause display problem From: =?gb2312?B?1cW6o779?= In-reply-to: <54DE424B.8070506@gmx.at> Date: Wed, 18 Feb 2015 19:19:31 +0800 Content-transfer-encoding: quoted-printable Message-id: <7294F8DD-9324-4872-9AAA-5E4A229EFD04@icloud.com> References: <54DE424B.8070506@gmx.at> To: martin rudalics X-Mailer: Apple Mail (2.2070.6) X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 19482 Cc: 19482@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Yes.=20 Emacs Version: 24.4.90. Downloaded from = http://emacsformacosx.com/builds. > =D4=DA 2015=C4=EA2=D4=C214=C8=D5=A3=AC02:28=A3=ACmartin rudalics = =D0=B4=B5=C0=A3=BA >=20 >> Open emacs, and run the following code: >> (set-frame-font "Menlo:size=3D30") >>=20 >> Then text in "*scratch*" buffer disappeared and I can't make the text = visible with scrolling up or down. >> After resizing Emacs's window size, text is visible. >>=20 >> It seems that after changing font size Emacs doesn't known the real = window size and so can't display >> correctly. >=20 > Can you still see this? If so please tell us which version of Emacs = you > use and how you built it. >=20 > Thanks, martin From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 18 09:05:42 2015 Received: (at 19482) by debbugs.gnu.org; 18 Feb 2015 14:05:42 +0000 Received: from localhost ([127.0.0.1]:47072 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YO5G2-0005kd-BR for submit@debbugs.gnu.org; Wed, 18 Feb 2015 09:05:42 -0500 Received: from mout.gmx.net ([212.227.15.18]:54412) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YO5Fy-0005kN-Q9 for 19482@debbugs.gnu.org; Wed, 18 Feb 2015 09:05:39 -0500 Received: from [178.190.161.200] ([178.190.161.200]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MO7ee-1YRMVz3dZM-005Vzh; Wed, 18 Feb 2015 15:05:32 +0100 Message-ID: <54E49C26.1070209@gmx.at> Date: Wed, 18 Feb 2015 15:05:26 +0100 From: martin rudalics MIME-Version: 1.0 To: =?GB2312?B?1cW6o779?= Subject: Re: bug#19482: Changing to big font cause display problem References: <54DE424B.8070506@gmx.at> <7294F8DD-9324-4872-9AAA-5E4A229EFD04@icloud.com> In-Reply-To: <7294F8DD-9324-4872-9AAA-5E4A229EFD04@icloud.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:O5+wR5avP9eeQZhl3xjw2Ep6OU/V2tkkZ4P3WHSWzqvHB56vPED QM2/49EQc8r42BWtbVQmOuXVtvHoGs58Kz35ym4XHxdvgDyaj7WhtMEQ7HBi/EZ9OmydT6A uuy1/FqPbXjemtXPUFBeHRXDbppg8E0V41R19J1qEAb01pb+7L83eT5roi1qd3NSnTT4I/0 ggA1qn0umJfEip4iT2z1w== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 19482 Cc: 19482@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) > Yes. > Emacs Version: 24.4.90. Downloaded from http://emacsformacosx.com/builds Can you please do M-: (window-dump-frame) in that frame and post the result (from a buffer called *window-frame-dump*) here. If possible do that three times, once before you issue the (set-frame-font "Menlo:size=30") once after it when you don't see the *scratch* contents and once after you resized and see the contents again. BTW: Instead of resizing, maximizing the frame and restoring its normal size should make the contents visible too. Right? Also can you try with the last of the so-called nightlies? I doubt it changes anything but maybe we can debug that problem better then. I have no Mac OS X here so the entire task of debugging this will rest on you. Thanks, martin From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 18 20:59:32 2015 Received: (at 19482) by debbugs.gnu.org; 19 Feb 2015 01:59:32 +0000 Received: from localhost ([127.0.0.1]:48247 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YOGOq-0007H2-4R for submit@debbugs.gnu.org; Wed, 18 Feb 2015 20:59:32 -0500 Received: from st13p27im-asmtp001.me.com ([17.162.190.63]:41544) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YOGOo-0007Gu-Pq for 19482@debbugs.gnu.org; Wed, 18 Feb 2015 20:59:31 -0500 Received: from [192.168.1.109] (unknown [58.101.27.211]) by st13p27im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Dec 4 2014)) with ESMTPSA id <0NJZ00MG4XJ1BS20@st13p27im-asmtp001.me.com> for 19482@debbugs.gnu.org; Thu, 19 Feb 2015 01:59:29 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68,1.0.33,0.0.0000 definitions=2015-02-18_08:2015-02-18,2015-02-18,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1412110000 definitions=main-1502190021 Content-type: text/plain; charset=gb2312 MIME-version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: bug#19482: Changing to big font cause display problem From: =?gb2312?B?1cW6o779?= In-reply-to: <54E49C26.1070209@gmx.at> Date: Thu, 19 Feb 2015 09:59:28 +0800 Content-transfer-encoding: quoted-printable Message-id: <0534A31D-5D69-4687-88CE-FA3C23A20278@icloud.com> References: <54DE424B.8070506@gmx.at> <7294F8DD-9324-4872-9AAA-5E4A229EFD04@icloud.com> <54E49C26.1070209@gmx.at> To: martin rudalics X-Mailer: Apple Mail (2.2070.6) X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 19482 Cc: 19482@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) When I do that, emacs reports error: Debugger entered--Lisp error: (void-function window-dump-frame) (window-dump-frame) eval((window-dump-frame) nil) eval-expression((window-dump-frame) nil) call-interactively(eval-expression nil nil) command-execute(eval-expression) > =D4=DA 2015=C4=EA2=D4=C218=C8=D5=A3=AC22:05=A3=ACmartin rudalics = =D0=B4=B5=C0=A3=BA >=20 >> Yes. >> Emacs Version: 24.4.90. Downloaded from = http://emacsformacosx.com/builds >=20 > Can you please do >=20 > M-: (window-dump-frame) >=20 > in that frame and post the result (from a buffer called > *window-frame-dump*) here. If possible do that three times, once = before > you issue the (set-frame-font "Menlo:size=3D30") once after it when = you > don't see the *scratch* contents and once after you resized and see = the > contents again. BTW: Instead of resizing, maximizing the frame and > restoring its normal size should make the contents visible too. = Right? >=20 > Also can you try with the last of the so-called nightlies? I doubt it > changes anything but maybe we can debug that problem better then. I > have no Mac OS X here so the entire task of debugging this will rest = on > you. >=20 > Thanks, martin From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 19 01:57:19 2015 Received: (at 19482) by debbugs.gnu.org; 19 Feb 2015 06:57:20 +0000 Received: from localhost ([127.0.0.1]:48310 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YOL31-0005he-KA for submit@debbugs.gnu.org; Thu, 19 Feb 2015 01:57:19 -0500 Received: from mout.gmx.net ([212.227.15.15]:62557) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YOL2y-0005hS-MU for 19482@debbugs.gnu.org; Thu, 19 Feb 2015 01:57:17 -0500 Received: from [194.166.82.88] ([194.166.82.88]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LjIit-1XqNL52Q99-00dUwq; Thu, 19 Feb 2015 07:57:12 +0100 Message-ID: <54E58941.3030005@gmx.at> Date: Thu, 19 Feb 2015 07:57:05 +0100 From: martin rudalics MIME-Version: 1.0 To: =?GB2312?B?1cW6o779?= Subject: Re: bug#19482: Changing to big font cause display problem References: <54DE424B.8070506@gmx.at> <7294F8DD-9324-4872-9AAA-5E4A229EFD04@icloud.com> <54E49C26.1070209@gmx.at> <0534A31D-5D69-4687-88CE-FA3C23A20278@icloud.com> In-Reply-To: <0534A31D-5D69-4687-88CE-FA3C23A20278@icloud.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:g8XJcj03Zyu3KWhipsK6N/mqsv5jt2QmqsG00VEIfqT8wJJOgfm tazOrf1vJwy0hJZem5+VQzGlfSmrz9trIDrZ5JixdWLPXKq841t9Xt6jhV+50uk7idixqwW niuZqZEpDJUK73GMs4Gy+22Eub8L+FnCgKaGN+JgtV+w1P+c9f2W3FAbZWcTPIZ4zFcEVhi i/CheRY+cYz4I+21gVURQ== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 19482 Cc: 19482@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) > When I do that, emacs reports error: > > Debugger entered--Lisp error: (void-function window-dump-frame) > (window-dump-frame) > eval((window-dump-frame) nil) > eval-expression((window-dump-frame) nil) > call-interactively(eval-expression nil nil) > command-execute(eval-expression) I'm too silly. I meant M-: (window--dump-frame) Sorry for the confusion, martin From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 20 05:23:16 2015 Received: (at 19482) by debbugs.gnu.org; 20 Feb 2015 10:23:17 +0000 Received: from localhost ([127.0.0.1]:49157 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YOkjs-0004Qf-2v for submit@debbugs.gnu.org; Fri, 20 Feb 2015 05:23:16 -0500 Received: from st13p27im-asmtp002.me.com ([17.162.190.64]:62106) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YOkjq-0004QW-Ed for 19482@debbugs.gnu.org; Fri, 20 Feb 2015 05:23:15 -0500 Received: from [192.168.1.109] (unknown [58.100.252.52]) by st13p27im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Dec 4 2014)) with ESMTPSA id <0NK200D51FIKBB50@st13p27im-asmtp002.me.com> for 19482@debbugs.gnu.org; Fri, 20 Feb 2015 10:23:13 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68,1.0.33,0.0.0000 definitions=2015-02-20_02:2015-02-20,2015-02-20,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1412110000 definitions=main-1502200100 Content-type: text/plain; charset=gb2312 MIME-version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: bug#19482: Changing to big font cause display problem From: =?gb2312?B?1cW6o779?= In-reply-to: <54E58941.3030005@gmx.at> Date: Fri, 20 Feb 2015 18:23:11 +0800 Content-transfer-encoding: quoted-printable Message-id: <0255489D-9FE7-4C96-850D-2ED2FC80E42B@icloud.com> 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> To: martin rudalics X-Mailer: Apple Mail (2.2070.6) X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 19482 Cc: 19482@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) > =D4=DA 2015=C4=EA2=D4=C219=C8=D5=A3=AC14:57=A3=ACmartin rudalics = =D0=B4=B5=C0=A3=BA >=20 >> When I do that, emacs reports error: >>=20 >> Debugger entered--Lisp error: (void-function window-dump-frame) >> (window-dump-frame) >> eval((window-dump-frame) nil) >> eval-expression((window-dump-frame) nil) >> call-interactively(eval-expression nil nil) >> command-execute(eval-expression) >=20 > I'm too silly. I meant >=20 > M-: (window--dump-frame) >=20 > Sorry for the confusion, martin Three results: ----------------------------- (1) before issuing (set-frame-font = "Menlo:size=3D30") ------------------------------------ frame pixel: 874 x 669 cols/lines: 87 x 35 units: 10 x 19 frame text pixel: 850 x 665 cols/lines: 85 x 35 tool: 0 scroll: 0 fringe: 20 border: 2 right: 0 bottom: 0 # parent: nil pixel left: 0 top: 0 size: 870 x 646 new: 646 char left: 0 top: 0 size: 87 x 34 new: 33 normal: 1.0 x 1.0 new: nil body pixel: 850 x 628 char: 85 x 33 width left fringe: 10 left margin: 0 right margin: 0 width right fringe: 10 scroll-bar: 0 divider: 0 height header-line: 0 mode-line: 18 divider: 0 # parent: nil pixel left: 0 top: 646 size: 870 x 19 new: 0 char left: 0 top: 34 size: 870 x 1 new: 0 normal: 1.0 x 1.0 new: ignore body pixel: 850 x 19 char: 85 x 1 width left fringe: 10 left margin: 0 right margin: 0 width right fringe: 10 scroll-bar: 0 divider: 0 height header-line: 0 mode-line: 0 divider: 0 ----------------------------- (2) after issuing (set-frame-font = "Menlo:size=3D30") ---------------------- frame pixel: 1552 x 1194 cols/lines: 86 x 35 units: 18 x 34 frame text pixel: 1530 x 1190 cols/lines: 85 x 35 tool: 0 scroll: 0 fringe: 18 border: 2 right: 0 bottom: 0 # parent: nil pixel left: 0 top: 0 size: 1548 x 1156 new: 1156 char left: 0 top: 0 size: 86 x 34 new: 33 normal: 1.0 x 1.0 new: nil body pixel: 1530 x 1123 char: 85 x 33 width left fringe: 9 left margin: 0 right margin: 0 width right fringe: 9 scroll-bar: 0 divider: 0 height header-line: 0 mode-line: 33 divider: 0 # parent: nil pixel left: 0 top: 1156 size: 1548 x 34 new: 0 char left: 0 top: 34 size: 1548 x 1 new: 0 normal: 1.0 x 1.0 new: ignore body pixel: 1530 x 34 char: 85 x 1 width left fringe: 9 left margin: 0 right margin: 0 width right fringe: 9 scroll-bar: 0 divider: 0 height header-line: 0 mode-line: 0 divider: 0 -------------------------- (3) after resizing the frame = ---------------------- frame pixel: 1392 x 840 cols/lines: 77 x 24 units: 18 x 34 frame text pixel: 1370 x 836 cols/lines: 76 x 24 tool: 0 scroll: 0 fringe: 18 border: 2 right: 0 bottom: 0 # parent: nil pixel left: 0 top: 0 size: 1388 x 802 new: 802 char left: 0 top: 0 size: 77 x 23 new: 22 normal: 1.0 x 1.0 new: nil body pixel: 1370 x 769 char: 76 x 22 width left fringe: 9 left margin: 0 right margin: 0 width right fringe: 9 scroll-bar: 0 divider: 0 height header-line: 0 mode-line: 33 divider: 0 # parent: nil pixel left: 0 top: 802 size: 1388 x 34 new: 0 char left: 0 top: 23 size: 1388 x 1 new: 0 normal: 1.0 x 1.0 new: ignore body pixel: 1370 x 34 char: 76 x 1 width left fringe: 9 left margin: 0 right margin: 0 width right fringe: 9 scroll-bar: 0 divider: 0 height header-line: 0 mode-line: 0 divider: 0 = --------------------------------------------------------------------------= My screen resolution is 1440x900. From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 20 13:24:47 2015 Received: (at 19482) by debbugs.gnu.org; 20 Feb 2015 18:24:47 +0000 Received: from localhost ([127.0.0.1]:49687 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YOsFr-0002yR-1A for submit@debbugs.gnu.org; Fri, 20 Feb 2015 13:24:47 -0500 Received: from mout.gmx.net ([212.227.17.20]:55682) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YOsFo-0002yI-NQ for 19482@debbugs.gnu.org; Fri, 20 Feb 2015 13:24:45 -0500 Received: from [93.82.11.100] ([93.82.11.100]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0M35iN-1XWDnj00Rz-00syYn; Fri, 20 Feb 2015 19:24:40 +0100 Message-ID: <54E77B3E.4000907@gmx.at> Date: Fri, 20 Feb 2015 19:21:50 +0100 From: martin rudalics MIME-Version: 1.0 To: =?GB2312?B?1cW6o779?= Subject: Re: bug#19482: Changing to big font cause display problem 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> In-Reply-To: <0255489D-9FE7-4C96-850D-2ED2FC80E42B@icloud.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:ppjUHXlj79Uzuq6usx0EiSSlG3Pxz2XjQjA/jdhRn3FlAl12s3n 6OHALbM6tzHnQWsWjYoFTvlBVC3UenV8eBnBcnjfx5b85bfNcZXmNix0oNu59i29lV8mkhX 4jU5FTUnyu9dM9Uz7xwUbsxbBRQif2BBn0K0FOAcdeb6ZjW8InidwMT38KocYTZjQrRVY9c okqHvDwDbmPef/VRB6DJQ== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 19482 Cc: 19482@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) > ----------------------------- (1) before issuing (set-frame-font "Menlo:size=30") ------------------------------------ > frame pixel: 874 x 669 cols/lines: 87 x 35 units: 10 x 19 > frame text pixel: 850 x 665 cols/lines: 85 x 35 > tool: 0 scroll: 0 fringe: 20 border: 2 right: 0 bottom: 0 [...] > ----------------------------- (2) after issuing (set-frame-font "Menlo:size=30") ---------------------- > frame pixel: 1552 x 1194 cols/lines: 86 x 35 units: 18 x 34 > frame text pixel: 1530 x 1190 cols/lines: 85 x 35 > tool: 0 scroll: 0 fringe: 18 border: 2 right: 0 bottom: 0 [...] > -------------------------- (3) after resizing the frame ---------------------- > frame pixel: 1392 x 840 cols/lines: 77 x 24 units: 18 x 34 > frame text pixel: 1370 x 836 cols/lines: 76 x 24 > tool: 0 scroll: 0 fringe: 18 border: 2 right: 0 bottom: 0 [...] > My screen resolution is 1440x900. IIUC this means that Emacs tries in `set-frame-font' to make your frame larger than your display which sounds like a bad idea. Try first to make the frame smaller before you call `set-frame-font' such that the resizing step in that function stays within the limits of the display and see whether the problem persists. Next try instead of (3) to maximize the frame and then restore its normal size, that is, the one after `set-frame-font', and see whether the problem persists (here I would simply type M-F10 twice). Finally, set the variable `frame-inhibit-implied-resize' to t, call `set-frame-font' and see whether the problem persists. martin From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 20 20:33:40 2015 Received: (at 19482) by debbugs.gnu.org; 21 Feb 2015 01:33:40 +0000 Received: from localhost ([127.0.0.1]:49779 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YOywu-0004Ni-7J for submit@debbugs.gnu.org; Fri, 20 Feb 2015 20:33:40 -0500 Received: from st13p27im-asmtp001.me.com ([17.162.190.63]:56819) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YOyws-0004NZ-31 for 19482@debbugs.gnu.org; Fri, 20 Feb 2015 20:33:38 -0500 Received: from [192.168.1.109] (unknown [58.101.31.77]) by st13p27im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Dec 4 2014)) with ESMTPSA id <0NK3000UQLNX1M10@st13p27im-asmtp001.me.com> for 19482@debbugs.gnu.org; Sat, 21 Feb 2015 01:33:37 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68,1.0.33,0.0.0000 definitions=2015-02-20_10:2015-02-20,2015-02-20,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1412110000 definitions=main-1502210014 Content-type: text/plain; charset=gb2312 MIME-version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: bug#19482: Changing to big font cause display problem From: =?gb2312?B?1cW6o779?= In-reply-to: <54E77B3E.4000907@gmx.at> Date: Sat, 21 Feb 2015 09:33:32 +0800 Content-transfer-encoding: quoted-printable Message-id: <1C7DF283-CB55-4360-AC5B-7565305D85F8@icloud.com> 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> To: martin rudalics X-Mailer: Apple Mail (2.2070.6) X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 19482 Cc: 19482@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) > =D4=DA 2015=C4=EA2=D4=C221=C8=D5=A3=AC02:21=A3=ACmartin rudalics = =D0=B4=B5=C0=A3=BA >=20 > IIUC this means that Emacs tries in `set-frame-font' to make your = frame > larger than your display which sounds like a bad idea. >=20 > Try first to make the frame smaller before you call `set-frame-font' > such that the resizing step in that function stays within the limits = of > the display and see whether the problem persists. >=20 > Next try instead of (3) to maximize the frame and then restore its > normal size, that is, the one after `set-frame-font', and see whether > the problem persists (here I would simply type M-F10 twice). >=20 > Finally, set the variable `frame-inhibit-implied-resize' to t, call > `set-frame-font' and see whether the problem persists. >=20 > martin The two tries both make the problem disappear. Setting the variable = `frame-inhibit-implied-resize' to t has no effect. It seems that the variable is not defined in version 24.4.90. From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 21 06:44:52 2015 Received: (at 19482) by debbugs.gnu.org; 21 Feb 2015 11:44:52 +0000 Received: from localhost ([127.0.0.1]:49891 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YP8UO-0002Ng-3E for submit@debbugs.gnu.org; Sat, 21 Feb 2015 06:44:52 -0500 Received: from mout.gmx.net ([212.227.15.15]:55407) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YP8UM-0002NX-JQ for 19482@debbugs.gnu.org; Sat, 21 Feb 2015 06:44:51 -0500 Received: from [88.117.118.249] ([88.117.118.249]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MHoC5-1YOITJ1OZx-003h7k; Sat, 21 Feb 2015 12:44:44 +0100 Message-ID: <54E86FA3.6010902@gmx.at> Date: Sat, 21 Feb 2015 12:44:35 +0100 From: martin rudalics MIME-Version: 1.0 To: =?GB2312?B?1cW6o779?= Subject: Re: bug#19482: Changing to big font cause display problem 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> In-Reply-To: <1C7DF283-CB55-4360-AC5B-7565305D85F8@icloud.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:Q4VrXpZAo1Q47JYAR+rA4RrRJv7JqMu5Ehsen2M0SJdJ8fya3UF uKyeVkGs5N4o+c0YfZ0bJFo0HpnOCxjj2I0qo3J/+3ryO+++CSFzFMZ1OT7RTl+XUw3q6Ep ib7cdIf0qRa4nN52cHBUooXcNjyPqlbpJUrGCTEWKGQetThOhwsi1npbsHfhKV2bkbwsP3b qxBqzYsULVDWKjR3OxwyA== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 19482 Cc: 19482@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) >> IIUC this means that Emacs tries in `set-frame-font' to make your frame >> larger than your display which sounds like a bad idea. >> >> Try first to make the frame smaller before you call `set-frame-font' >> such that the resizing step in that function stays within the limits of >> the display and see whether the problem persists. >> >> Next try instead of (3) to maximize the frame and then restore its >> normal size, that is, the one after `set-frame-font', and see whether >> the problem persists (here I would simply type M-F10 twice). >> >> Finally, set the variable `frame-inhibit-implied-resize' to t, call >> `set-frame-font' and see whether the problem persists. >> >> martin > > The two tries both make the problem disappear. Setting the variable `frame-inhibit-implied-resize' to t has no effect. > It seems that the variable is not defined in version 24.4.90. `frame-inhibit-implied-resize' is defined only in Emacs 25 so you would have to test this with the "nightlies" I mentioned earlier. Two more questions: - After doing your `set-frame-font' how much of the frame do you see? Do you see the upper left corner, the frame's title? Do you notice that the frame is larger than your display? For example, if you can see the frame's title, you should not see the frame's echo area. - When you "maximize the frame and then restore its normal size" does the frame have the size it had after the `set-frame-font' or did it change in some way? What does (window--dump-frame) give here? martin From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 21 21:57:16 2015 Received: (at 19482) by debbugs.gnu.org; 22 Feb 2015 02:57:16 +0000 Received: from localhost ([127.0.0.1]:50444 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YPMjL-0000dC-CW for submit@debbugs.gnu.org; Sat, 21 Feb 2015 21:57:15 -0500 Received: from st13p27im-asmtp001.me.com ([17.162.190.63]:40907) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YPMjI-0000d3-Oj for 19482@debbugs.gnu.org; Sat, 21 Feb 2015 21:57:13 -0500 Received: from [192.168.1.109] (unknown [58.101.25.225]) by st13p27im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Dec 4 2014)) with ESMTPSA id <0NK5005K2K76E320@st13p27im-asmtp001.me.com> for 19482@debbugs.gnu.org; Sun, 22 Feb 2015 02:57:11 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68,1.0.33,0.0.0000 definitions=2015-02-21_02:2015-02-20,2015-02-21,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1412110000 definitions=main-1502220028 Content-type: text/plain; charset=gb2312 MIME-version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: bug#19482: Changing to big font cause display problem From: =?gb2312?B?1cW6o779?= In-reply-to: <54E86FA3.6010902@gmx.at> Date: Sun, 22 Feb 2015 10:57:05 +0800 Content-transfer-encoding: quoted-printable Message-id: 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> To: martin rudalics X-Mailer: Apple Mail (2.2070.6) X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 19482 Cc: 19482@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) > =D4=DA 2015=C4=EA2=D4=C221=C8=D5=A3=AC19:44=A3=ACmartin rudalics = =D0=B4=B5=C0=A3=BA >=20 > `frame-inhibit-implied-resize' is defined only in Emacs 25 so you = would > have to test this with the "nightlies" I mentioned earlier. >=20 > Two more questions: >=20 > - After doing your `set-frame-font' how much of the frame do you see? > Do you see the upper left corner, the frame's title? Do you notice > that the frame is larger than your display? For example, if you can > see the frame's title, you should not see the frame's echo area. >=20 > - When you "maximize the frame and then restore its normal size" does > the frame have the size it had after the `set-frame-font' or did it > change in some way? What does (window--dump-frame) give here? >=20 > martin I see the doc of the variable 'frame-inhibit-implied-resize'. The new = behavior is not what I want. I like the following behavior: When setting font, emacs changes frame's size, but the new size is = adjusted to keep the whole frame visible. This is more useful. =20 - After setting font: There's one frame. Frame's height didn't exceed height of display. So I = could see both the frame' title and the echo area. Frame' width exceeded width of display. I could see the upper left = corner, but not the right border of the frame. - When "maximize the frame and then restore its normal size": Frame's width changed too much. Frame's height changed slightly(less = than height of one text line). Dumped results: ------------------- maximized ------------------------------- frame pixel: 1392 x 840 cols/lines: 77 x 24 units: 18 x 34 frame text pixel: 1370 x 836 cols/lines: 76 x 24 tool: 0 scroll: 0 fringe: 18 border: 2 right: 0 bottom: 0 # parent: nil pixel left: 0 top: 0 size: 1388 x 802 new: 802 char left: 0 top: 0 size: 77 x 23 new: 21 normal: 1.0 x 1.0 new: nil body pixel: 1370 x 769 char: 76 x 22 width left fringe: 9 left margin: 0 right margin: 0 width right fringe: 9 scroll-bar: 0 divider: 0 height header-line: 0 mode-line: 33 divider: 0 # parent: nil pixel left: 0 top: 802 size: 1388 x 34 new: 0 char left: 0 top: 23 size: 1388 x 1 new: 1 normal: 1.0 x 1.0 new: ignore body pixel: 1370 x 34 char: 76 x 1 width left fringe: 9 left margin: 0 right margin: 0 width right fringe: 9 scroll-bar: 0 divider: 0 height header-line: 0 mode-line: 0 divider: 0 ------------------- restored ---------------------------- frame pixel: 1554 x 840 cols/lines: 86 x 24 units: 18 x 34 frame text pixel: 1532 x 836 cols/lines: 85 x 24 tool: 0 scroll: 0 fringe: 18 border: 2 right: 0 bottom: 0 # parent: nil pixel left: 0 top: 0 size: 1550 x 802 new: 646 char left: 0 top: 0 size: 86 x 23 new: 33 normal: 1.0 x 1.0 new: nil body pixel: 1532 x 769 char: 85 x 22 width left fringe: 9 left margin: 0 right margin: 0 width right fringe: 9 scroll-bar: 0 divider: 0 height header-line: 0 mode-line: 33 divider: 0 # parent: nil pixel left: 0 top: 802 size: 1550 x 34 new: 0 char left: 0 top: 23 size: 1550 x 1 new: 1 normal: 1.0 x 1.0 new: ignore body pixel: 1532 x 34 char: 85 x 1 width left fringe: 9 left margin: 0 right margin: 0 width right fringe: 9 scroll-bar: 0 divider: 0 height header-line: 0 mode-line: 0 divider: 0 --------------------------------------------------------------------- Emacs changes its frame size when setting font, but the frame size may = be limited by window manager or something else. So the frame's real size is not expected as emacs. Here emacs may get = the real size and use the real size. From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 22 05:01:01 2015 Received: (at 19482) by debbugs.gnu.org; 22 Feb 2015 10:01:02 +0000 Received: from localhost ([127.0.0.1]:50509 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YPTLR-00050T-0e for submit@debbugs.gnu.org; Sun, 22 Feb 2015 05:01:01 -0500 Received: from mout.gmx.net ([212.227.15.15]:62138) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YPTLO-00050K-H1 for 19482@debbugs.gnu.org; Sun, 22 Feb 2015 05:00:59 -0500 Received: from [178.190.22.42] ([178.190.22.42]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LxPAo-1XSX6a2dtS-016tCd; Sun, 22 Feb 2015 11:00:54 +0100 Message-ID: <54E9A8CB.8070605@gmx.at> Date: Sun, 22 Feb 2015 11:00:43 +0100 From: martin rudalics MIME-Version: 1.0 To: =?GB2312?B?1cW6o779?= Subject: Re: bug#19482: Changing to big font cause display problem 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> In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:nlNSjN/VKimjRG9Y32mKl7IPbya7Ehuv4aFxr242gK32Bt0DFbc FkuPdHcGU50cV6OtqETKba0FmkB/uBEugftYhQB33IpDX6BbqL6vTCVeNX2IZDy/IQm89Pt Gc2a+WhDu1tO3P8vRaQ3zo3s8tRW+BISuDVvLzZUdDJMoc9J4bp5PrH1pSTj9RAIKavroiM gmpJrjnJckxSY273UaW0w== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 19482 Cc: 19482@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) > I like the following behavior: > When setting font, emacs changes frame's size, but the new size is adjusted to keep the whole frame visible. > This is more useful. It's far from trivial to accomplish though. Suppose you have some frame sizes H1xV1 and a default font size F1. Now you change the default font to F2 and would get the relative sizes H2xV2 where, however, V2 exceeds the size of your display. So we adjust V2 (and maybe H2 as well) to fit the frame into your display. Next you change the font size back to F1 and probably expect to get the initial sizes H1 and V1 back. But the frame sizing code doesn't remember them ... I do something comparable in the windows code where I maintain for each window a nominal size (retrievable via `window-normal-size') but dislike the associated maintenance burden profoundly. And a final touch: On X and Windows I have a function called `x-frame-geometry' which, far from perfect, allows to retrieve the sizes of the part of a frame not managed by Emacs. I don't have such a function for the ns part of Emacs. But to tell whether a frame can be embedded into a display I need to know the size of the display and the sizes of the decorations added by the window manager. Could you write such a function for ns? > - After setting font: > There's one frame. Frame's height didn't exceed height of display. So I could see both the frame' title and the echo area. > Frame' width exceeded width of display. I could see the upper left corner, but not the right border of the frame. This contradicts what you said earlier, namely ----------------------------- (2) after issuing (set-frame-font "Menlo:size=30") ---------------------- frame pixel: 1552 x 1194 cols/lines: 86 x 35 units: 18 x 34 frame text pixel: 1530 x 1190 cols/lines: 85 x 35 tool: 0 scroll: 0 fringe: 18 border: 2 right: 0 bottom: 0 and My screen resolution is 1440x900. 1194 is certainly larger than 900 so you should either not see the title bar or not see the echo area. Can you clarify this issue? Some strange things seem to happen on Mac OS X. > - When "maximize the frame and then restore its normal size": > Frame's width changed too much. Frame's height changed slightly(less than height of one text line). > > Dumped results: > ------------------- maximized ------------------------------- > frame pixel: 1392 x 840 cols/lines: 77 x 24 units: 18 x 34 > frame text pixel: 1370 x 836 cols/lines: 76 x 24 > tool: 0 scroll: 0 fringe: 18 border: 2 right: 0 bottom: 0 > > # parent: nil > pixel left: 0 top: 0 size: 1388 x 802 new: 802 > char left: 0 top: 0 size: 77 x 23 new: 21 > normal: 1.0 x 1.0 new: nil > body pixel: 1370 x 769 char: 76 x 22 > width left fringe: 9 left margin: 0 right margin: 0 > width right fringe: 9 scroll-bar: 0 divider: 0 > height header-line: 0 mode-line: 33 divider: 0 > > # parent: nil > pixel left: 0 top: 802 size: 1388 x 34 new: 0 > char left: 0 top: 23 size: 1388 x 1 new: 1 > normal: 1.0 x 1.0 new: ignore > body pixel: 1370 x 34 char: 76 x 1 > width left fringe: 9 left margin: 0 right margin: 0 > width right fringe: 9 scroll-bar: 0 divider: 0 > height header-line: 0 mode-line: 0 divider: 0 > > ------------------- restored ---------------------------- > frame pixel: 1554 x 840 cols/lines: 86 x 24 units: 18 x 34 And this seems to confirm what I said above: Restoring doesn't restore the previous height which should be 1194 but keeps the frame maximized vertically. This seems to be an idiosyncrasy of the Mac OS code and we should either find some reference (on the Web) where this behavior is described or some Mac OS expert reading this would be so kind to help us in this regard. > frame text pixel: 1532 x 836 cols/lines: 85 x 24 > tool: 0 scroll: 0 fringe: 18 border: 2 right: 0 bottom: 0 > > # parent: nil > pixel left: 0 top: 0 size: 1550 x 802 new: 646 > char left: 0 top: 0 size: 86 x 23 new: 33 > normal: 1.0 x 1.0 new: nil > body pixel: 1532 x 769 char: 85 x 22 > width left fringe: 9 left margin: 0 right margin: 0 > width right fringe: 9 scroll-bar: 0 divider: 0 > height header-line: 0 mode-line: 33 divider: 0 > > # parent: nil > pixel left: 0 top: 802 size: 1550 x 34 new: 0 > char left: 0 top: 23 size: 1550 x 1 new: 1 > normal: 1.0 x 1.0 new: ignore > body pixel: 1532 x 34 char: 85 x 1 > width left fringe: 9 left margin: 0 right margin: 0 > width right fringe: 9 scroll-bar: 0 divider: 0 > height header-line: 0 mode-line: 0 divider: 0 > --------------------------------------------------------------------- > > Emacs changes its frame size when setting font, but the frame size may be limited by window manager or something else. Indeed. The problem is to find out what the limits are. > So the frame's real size is not expected as emacs. Here emacs may get the real size and use the real size. Emacs should get the size eventually. If you tried one of the Emacs 25 "nightlies", you should be able to find a variable called `frame-size-history' there. We could use that variable to trace back the OS request and find out why Emacs doesn't process it correctly. But still note: Even if we can trace this problem and solve it, the problem remains that the frame's proportions are distorted by the request and there's hardly a chance to get back the initial frame size when you switch back to the initial font size. martin From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 22 05:56:51 2015 Received: (at 19482) by debbugs.gnu.org; 22 Feb 2015 10:56:51 +0000 Received: from localhost ([127.0.0.1]:50520 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YPUDS-0007jn-C5 for submit@debbugs.gnu.org; Sun, 22 Feb 2015 05:56:50 -0500 Received: from st13p27im-asmtp001.me.com ([17.162.190.63]:32829) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YPUDQ-0007je-M4 for 19482@debbugs.gnu.org; Sun, 22 Feb 2015 05:56:49 -0500 Received: from [192.168.1.109] (unknown [58.101.25.225]) by st13p27im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Dec 4 2014)) with ESMTPSA id <0NK600DAU6BGE520@st13p27im-asmtp001.me.com> for 19482@debbugs.gnu.org; Sun, 22 Feb 2015 10:54:57 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68,1.0.33,0.0.0000 definitions=2015-02-22_02:2015-02-20,2015-02-22,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1412110000 definitions=main-1502220104 Content-type: text/plain; charset=gb2312 MIME-version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: bug#19482: Changing to big font cause display problem From: =?gb2312?B?1cW6o779?= In-reply-to: <54E9A8CB.8070605@gmx.at> Date: Sun, 22 Feb 2015 18:54:51 +0800 Content-transfer-encoding: quoted-printable Message-id: <3EDF6985-A93A-46E9-9083-C2E496AB98C1@icloud.com> 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> To: martin rudalics X-Mailer: Apple Mail (2.2070.6) X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 19482 Cc: 19482@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) > =D4=DA 2015=C4=EA2=D4=C222=C8=D5=A3=AC18:00=A3=ACmartin rudalics = =D0=B4=B5=C0=A3=BA >=20 > It's far from trivial to accomplish though. Suppose you have some = frame > sizes H1xV1 and a default font size F1. Now you change the default = font > to F2 and would get the relative sizes H2xV2 where, however, V2 = exceeds > the size of your display. So we adjust V2 (and maybe H2 as well) to = fit > the frame into your display. Next you change the font size back to F1 > and probably expect to get the initial sizes H1 and V1 back. But the > frame sizing code doesn't remember them ... >=20 To me, I don't care about the initial sizes H1 and V1. Just try to keep = the *current* columns and lines. Maybe we can add a new value like 'smart to the variable = frame-inhibit-implied-resize. >=20 > And a final touch: On X and Windows I have a function called > `x-frame-geometry' which, far from perfect, allows to retrieve the = sizes > of the part of a frame not managed by Emacs. I don't have such a > function for the ns part of Emacs. But to tell whether a frame can be > embedded into a display I need to know the size of the display and the > sizes of the decorations added by the window manager. Could you write > such a function for ns? >=20 Sorry, I'm not familiar with object-c. I'm just a basic user of Mac. > This contradicts what you said earlier, namely >=20 > ----------------------------- (2) after issuing (set-frame-font = "Menlo:size=3D30") ---------------------- > frame pixel: 1552 x 1194 cols/lines: 86 x 35 units: 18 x 34 > frame text pixel: 1530 x 1190 cols/lines: 85 x 35 > tool: 0 scroll: 0 fringe: 18 border: 2 right: 0 bottom: 0 >=20 > and >=20 > My screen resolution is 1440x900. >=20 > 1194 is certainly larger than 900 so you should either not see the = title > bar or not see the echo area. Can you clarify this issue? Some = strange > things seem to happen on Mac OS X. That's the fact. Emacs doesn't know the real size of frame and is using = a wrong frame size. This must be the cause of the display problem. >=20 > And this seems to confirm what I said above: Restoring doesn't restore > the previous height which should be 1194 but keeps the frame maximized > vertically. This seems to be an idiosyncrasy of the Mac OS code and = we > should either find some reference (on the Web) where this behavior is > described or some Mac OS expert reading this would be so kind to help = us > in this regard. Yes. >=20 > Indeed. The problem is to find out what the limits are. >=20 >> So the frame's real size is not expected as emacs. Here emacs may get = the real size and use the real size. >=20 > Emacs should get the size eventually. If you tried one of the Emacs = 25 > "nightlies", you should be able to find a variable called > `frame-size-history' there. We could use that variable to trace back > the OS request and find out why Emacs doesn't process it correctly. I will try the Emacs 25. From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 22 06:32:56 2015 Received: (at 19482) by debbugs.gnu.org; 22 Feb 2015 11:32:56 +0000 Received: from localhost ([127.0.0.1]:50528 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YPUmO-0000DQ-5x for submit@debbugs.gnu.org; Sun, 22 Feb 2015 06:32:56 -0500 Received: from mout.gmx.net ([212.227.15.18]:60869) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YPUmL-0000DH-4n for 19482@debbugs.gnu.org; Sun, 22 Feb 2015 06:32:54 -0500 Received: from [178.190.22.42] ([178.190.22.42]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MMkDH-1YT2UQ1eV5-008Zzu; Sun, 22 Feb 2015 12:32:49 +0100 Message-ID: <54E9BE56.8020507@gmx.at> Date: Sun, 22 Feb 2015 12:32:38 +0100 From: martin rudalics MIME-Version: 1.0 To: =?GB2312?B?1cW6o779?= Subject: Re: bug#19482: Changing to big font cause display problem 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> In-Reply-To: <3EDF6985-A93A-46E9-9083-C2E496AB98C1@icloud.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:CPWfCV0Qn9b20HPVqehnn35hTVCWqlHNqjVCb1GXgrUabVASYcl 3phJaT7FQ7kvqByNxjXoP/hcNAnuSkgUplye2ied0qlDah7eXMPz2OH6gD1StMSu3uwdJm7 C/hXS+axxt7cO1IwlcwSpErk+D+QieTD9VPfc5lFtmouYNXd0yls5WuhxwWvyAacMFb2aL8 Xer1NzQPN+pVPNSPhmmXQ== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 19482 Cc: 19482@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) > That's the fact. Emacs doesn't know the real size of frame and is using a wrong frame size. > This must be the cause of the display problem. So it seems that we have located the bug now. >> Indeed. The problem is to find out what the limits are. First we have to find out whether and how your window manager does tell us the limits and/or why Emacs apparently ignores them. > I will try the Emacs 25. Fine. I'll tell you what to do when you're ready. martin From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 22 07:28:58 2015 Received: (at 19482) by debbugs.gnu.org; 22 Feb 2015 12:28:58 +0000 Received: from localhost ([127.0.0.1]:50538 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YPVeb-0001Wr-W7 for submit@debbugs.gnu.org; Sun, 22 Feb 2015 07:28:58 -0500 Received: from st13p27im-asmtp001.me.com ([17.162.190.63]:60025) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YPVeZ-0001Wh-NG for 19482@debbugs.gnu.org; Sun, 22 Feb 2015 07:28:56 -0500 Received: from [192.168.1.109] (unknown [58.101.25.225]) by st13p27im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Dec 4 2014)) with ESMTPSA id <0NK600F2PALEQ950@st13p27im-asmtp001.me.com> for 19482@debbugs.gnu.org; Sun, 22 Feb 2015 12:27:19 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68,1.0.33,0.0.0000 definitions=2015-02-22_02:2015-02-20,2015-02-22,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1412110000 definitions=main-1502220120 Content-type: text/plain; charset=gb2312 MIME-version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: bug#19482: Changing to big font cause display problem From: =?gb2312?B?1cW6o779?= In-reply-to: <54E9BE56.8020507@gmx.at> Date: Sun, 22 Feb 2015 20:27:13 +0800 Content-transfer-encoding: quoted-printable Message-id: <8BFBB35D-B081-4B88-85A7-6CA28B9362EB@icloud.com> 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> <54E9BE56.8020507@gmx.at> To: martin rudalics X-Mailer: Apple Mail (2.2070.6) X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 19482 Cc: 19482@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) > =D4=DA 2015=C4=EA2=D4=C222=C8=D5=A3=AC19:32=A3=ACmartin rudalics = =D0=B4=B5=C0=A3=BA >=20 >> That's the fact. Emacs doesn't know the real size of frame and is = using a wrong frame size. >> This must be the cause of the display problem. >=20 > So it seems that we have located the bug now. >=20 >>> Indeed. The problem is to find out what the limits are. >=20 > First we have to find out whether and how your window manager does = tell > us the limits and/or why Emacs apparently ignores them. >=20 >> I will try the Emacs 25. >=20 > Fine. I'll tell you what to do when you're ready. >=20 > martin I just installed Emacs 25. It seems that this bug is fixed in this = version.=20 Download from: = http://emacsformacosx.com/emacs-builds/Emacs-2015-02-21_01-40-42-3ebf063-u= niversal.dmg After issuing (set-frame-font "Menlo:size=3D30"), the dumped result: --------------------------------------------------------------- frame pixel: 1553 x 844 cols/lines: 88 x 24 units: 18 x 35 frame text pixel: 1533 x 840 cols/lines: 85 x 24 tool: 0 scroll: 0/0 fringe: 16 border: 2 right: 0 bottom: 0 # parent: nil pixel left: 0 top: 0 size: 1549 x 805 new: 476 char left: 0 top: 0 size: 86 x 23 new: 33 normal: 1.0 x 1.0 new: nil body pixel: 1533 x 770 char: 85 x 22 width left fringe: 8 left margin: 0 right margin: 0 width right fringe: 8 scroll-bar: 0 divider: 0 height header-line: 0 mode-line: 35 divider: 0 # parent: nil pixel left: 0 top: 805 size: 1549 x 35 new: 0 char left: 0 top: 23 size: 1549 x 1 new: 0 normal: 1.0 x 1.0 new: 0 body pixel: 1533 x 35 char: 85 x 1 width left fringe: 8 left margin: 0 right margin: 0 width right fringe: 8 scroll-bar: 0 divider: 0 height header-line: 0 mode-line: 0 divider: 0 Thank you. From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 22 11:27:41 2015 Received: (at 19482) by debbugs.gnu.org; 22 Feb 2015 16:27:41 +0000 Received: from localhost ([127.0.0.1]:50811 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YPZNc-0008Vy-Lh for submit@debbugs.gnu.org; Sun, 22 Feb 2015 11:27:40 -0500 Received: from mailfe05.swip.net ([212.247.154.129]:46735 helo=swip.net) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YPZNa-0008Vj-Ju for 19482@debbugs.gnu.org; Sun, 22 Feb 2015 11:27:39 -0500 X-T2-Spam-Status: No, hits=-0.0 required=5.0 tests=BAYES_20 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 570463449; Sun, 22 Feb 2015 17:27:35 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: bug#19482: Changing to big font cause display problem From: "Jan D." In-Reply-To: <3EDF6985-A93A-46E9-9083-C2E496AB98C1@icloud.com> Date: Sun, 22 Feb 2015 17:27:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <24726EFE-F45F-4F6C-8941-AA1E5457D14F@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> To: =?utf-8?B?5byg5rW35ZCb?= X-Mailer: Apple Mail (2.2070.6) X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 19482 Cc: martin rudalics , 19482@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) > 22 feb 2015 kl. 11:54 skrev =E5=BC=A0=E6=B5=B7=E5=90=9B = : >=20 >=20 >> =E5=9C=A8 2015=E5=B9=B42=E6=9C=8822=E6=97=A5=EF=BC=8C18:00=EF=BC=8Cmart= in rudalics =E5=86=99=E9=81=93=EF=BC=9A >> And a final touch: On X and Windows I have a function called >> `x-frame-geometry' which, far from perfect, allows to retrieve the = sizes >> of the part of a frame not managed by Emacs. I don't have such a >> function for the ns part of Emacs. But to tell whether a frame can = be >> embedded into a display I need to know the size of the display and = the >> sizes of the decorations added by the window manager. Could you = write >> such a function for ns? >>=20 > Sorry, I'm not familiar with object-c. I'm just a basic user of Mac. I added an implementation for NS. When looking at the X version, this does not make sense (except from the = redundant parantesis): outer_height =3D (FRAME_PIXEL_HEIGHT (f) + FRAME_OUTER_TO_INNER_DIFF_Y (f) + FRAME_OUTER_TO_INNER_DIFF_X (f)); What is the connection between height and DIFF_X? It should probably be outer_height =3D FRAME_PIXEL_HEIGHT (f) + 2 * FRAME_OUTER_TO_INNER_DIFF_Y (f); Jan D. From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 22 12:09:32 2015 Received: (at 19482) by debbugs.gnu.org; 22 Feb 2015 17:09:32 +0000 Received: from localhost ([127.0.0.1]:50815 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YPa28-00014F-6V for submit@debbugs.gnu.org; Sun, 22 Feb 2015 12:09:32 -0500 Received: from mout.gmx.net ([212.227.15.19]:55185) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YPa25-000147-T2 for 19482@debbugs.gnu.org; Sun, 22 Feb 2015 12:09:30 -0500 Received: from [188.22.37.188] ([188.22.37.188]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LvENG-1XPg3W46ao-010JHQ; Sun, 22 Feb 2015 18:09:29 +0100 Message-ID: <54EA0D3D.1070709@gmx.at> Date: Sun, 22 Feb 2015 18:09:17 +0100 From: martin rudalics MIME-Version: 1.0 To: =?GB2312?B?1cW6o779?= Subject: Re: bug#19482: Changing to big font cause display problem 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> <54E9BE56.8020507@gmx.at> <8BFBB35D-B081-4B88-85A7-6CA28B9362EB@icloud.com> In-Reply-To: <8BFBB35D-B081-4B88-85A7-6CA28B9362EB@icloud.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:uSTG29022/kWd0ugOpqXAfzzZ9s7POd9OxnY2nWyEtgh6yppzOK vKvfq9UTWyQpwwgL7Ea20ezX/9bO1gqGvRJj9erLdmcBn6BTJaJtsQQULM7QIB112bYd+lz meqEnfGcRAIubFj3bjZhz1VC1MxYYL0NlHRUkrSBhK1ltc9IEVyllCKhldQ/UYyBGHRtw8e TRCnCcguTwxynstwndr/w== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 19482 Cc: 19482@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) > After issuing (set-frame-font "Menlo:size=30"), the dumped result: > --------------------------------------------------------------- > frame pixel: 1553 x 844 cols/lines: 88 x 24 units: 18 x 35 Earlier you had a different default font height here (34 instead of 35): ----------------------------- (2) after issuing (set-frame-font "Menlo:size=30") ---------------------- frame pixel: 1552 x 1194 cols/lines: 86 x 35 units: 18 x 34 Strictly spoken we should be able to explain that. martin From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 22 12:10:42 2015 Received: (at 19482) by debbugs.gnu.org; 22 Feb 2015 17:10:42 +0000 Received: from localhost ([127.0.0.1]:50819 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YPa3F-000168-M4 for submit@debbugs.gnu.org; Sun, 22 Feb 2015 12:10:41 -0500 Received: from mout.gmx.net ([212.227.15.19]:63193) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YPa3C-000160-VM for 19482@debbugs.gnu.org; Sun, 22 Feb 2015 12:10:40 -0500 Received: from [188.22.37.188] ([188.22.37.188]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0Lkwc9-1XrtBp1cGL-00alBr; Sun, 22 Feb 2015 18:10:28 +0100 Message-ID: <54EA0D77.7010009@gmx.at> Date: Sun, 22 Feb 2015 18:10:15 +0100 From: martin rudalics MIME-Version: 1.0 To: "Jan D." , =?UTF-8?B?5byg5rW35ZCb?= Subject: Re: bug#19482: Changing to big font cause display problem 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> In-Reply-To: <24726EFE-F45F-4F6C-8941-AA1E5457D14F@swipnet.se> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:EFXDQgkhcxE2WOAzmG2NzwEi0qdqh0SsWGNnCGQyqnz7FvFpQ6z NNV9OL3ve91JkaM5qcKoCK+hqbhqcwa1JNGHkCmU0Vl91QSNpmDOfc72ugsgKZirJSSA7bH VlJp6VoNRr3hO7KkwaISWr0ABtwrD9gpeMLzgXEWY52dWteGN2rzOmBcB9ECEJ1+zj455hN laxfuZTODVpY8mtbix1Rg== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 19482 Cc: 19482@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) > I added an implementation for NS. Thanks a lot. > When looking at the X version, this does not make sense (except from the redundant parantesis): The parenthesis is here for indentation purposes only. > outer_height = (FRAME_PIXEL_HEIGHT (f) > + FRAME_OUTER_TO_INNER_DIFF_Y (f) > + FRAME_OUTER_TO_INNER_DIFF_X (f)); > > What is the connection between height and DIFF_X? > It should probably be > > outer_height = FRAME_PIXEL_HEIGHT (f) > + 2 * FRAME_OUTER_TO_INNER_DIFF_Y (f); IIUC FRAME_OUTER_TO_INNER_DIFF_Y is the height of title bar, tool bar plus that of one decoration while FRAME_OUTER_TO_INNER_DIFF_X is just the "width" of the decoration which I assumed equal on all other three sides but the top one. I probably should have written outer_height = (FRAME_PIXEL_HEIGHT (f) + FRAME_OUTER_TO_INNER_DIFF_Y (f) + border); instead. Either way I can't add FRAME_OUTER_TO_INNER_DIFF_Y twice. However, this version works only because FRAME_OUTER_TO_INNER_DIFF_X apparently never counts a tool bar on the left or the right. 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? martin From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 22 12:43:38 2015 Received: (at 19482) by debbugs.gnu.org; 22 Feb 2015 17:43:39 +0000 Received: from localhost ([127.0.0.1]:50825 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YPaZ8-0001se-Dn for submit@debbugs.gnu.org; Sun, 22 Feb 2015 12:43:38 -0500 Received: from mailfe08.swip.net ([212.247.154.225]:48535 helo=swip.net) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YPaZ5-0001sV-QR for 19482@debbugs.gnu.org; Sun, 22 Feb 2015 12:43:37 -0500 X-T2-Spam-Status: No, hits=-0.0 required=5.0 tests=BAYES_40 Received: from hosdjarv.se (account mj138573@tele2.se [46.59.42.57] verified) by mailfe08.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 576042257; Sun, 22 Feb 2015 18:43:33 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: bug#19482: Changing to big font cause display problem From: "Jan D." In-Reply-To: <54EA0D77.7010009@gmx.at> Date: Sun, 22 Feb 2015 18:43:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <504DD3FF-BA56-4407-AFE6-CCAA9F90BB31@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> To: martin rudalics X-Mailer: Apple Mail (2.2070.6) X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 19482 Cc: =?utf-8?B?5byg5rW35ZCb?= , 19482@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Hi. > 22 feb 2015 kl. 18:10 skrev martin rudalics : >=20 > IIUC FRAME_OUTER_TO_INNER_DIFF_Y is the height of title bar, tool bar Only for external toolbar. > plus that of one decoration while FRAME_OUTER_TO_INNER_DIFF_X is just > the "width" of the decoration which I assumed equal on all other three > sides but the top one. I probably should have written >=20 > outer_height =3D (FRAME_PIXEL_HEIGHT (f) > + FRAME_OUTER_TO_INNER_DIFF_Y (f) > + border); >=20 > instead. Either way I can't add FRAME_OUTER_TO_INNER_DIFF_Y twice. >=20 > However, this version works only because FRAME_OUTER_TO_INNER_DIFF_X > apparently never counts a tool bar on the left or the right. 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)) > 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. A bit offtopic for this bug anyway. Jan D. From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 22 13:52:53 2015 Received: (at 19482) by debbugs.gnu.org; 22 Feb 2015 18:52:53 +0000 Received: from localhost ([127.0.0.1]:50842 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YPbe8-0003VT-Nq for submit@debbugs.gnu.org; Sun, 22 Feb 2015 13:52:53 -0500 Received: from mout.gmx.net ([212.227.15.19]:50940) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YPbe6-0003VK-88 for 19482@debbugs.gnu.org; Sun, 22 Feb 2015 13:52:50 -0500 Received: from [188.22.37.188] ([188.22.37.188]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0M4WRI-1XcKyF1qXM-00yfTU; Sun, 22 Feb 2015 19:52:43 +0100 Message-ID: <54EA2570.8090504@gmx.at> Date: Sun, 22 Feb 2015 19:52:32 +0100 From: martin rudalics MIME-Version: 1.0 To: "Jan D." Subject: Re: bug#19482: Changing to big font cause display problem 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> In-Reply-To: <504DD3FF-BA56-4407-AFE6-CCAA9F90BB31@swipnet.se> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:14YkvwQ0xMMpIZN/ohB55QzdTAE/9EQUpYMB3vILpfMi7+8plSV nkLX3VNGUWLn2FS6YFzaP/xaHZNDCc7YIwBZVEOCt2+IfXGTsygPUlAPiGx9GrnnjIYnsrx GR8FqcN+q8tSdCAabuN7SYbbwnrZLhFvFELiT+cbSAheqd1XTq/sWxFvK69umyDqUAeyneZ Zl6VZ/3Odhkn/+xAsvpIg== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 19482 Cc: =?UTF-8?B?5byg5rW35ZCb?= , 19482@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) >> 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 ... > 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. >> 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. > A bit offtopic for this bug anyway. True. martin From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 22 21:12:37 2015 Received: (at 19482) by debbugs.gnu.org; 23 Feb 2015 02:12:38 +0000 Received: from localhost ([127.0.0.1]:50961 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YPiVh-0006te-GQ for submit@debbugs.gnu.org; Sun, 22 Feb 2015 21:12:37 -0500 Received: from st13p27im-asmtp002.me.com ([17.162.190.64]:55770) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YPiVe-0006tV-A3 for 19482@debbugs.gnu.org; Sun, 22 Feb 2015 21:12:35 -0500 Received: from [192.168.1.109] (unknown [58.101.27.255]) by st13p27im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Dec 4 2014)) with ESMTPSA id <0NK700GNRCQE9930@st13p27im-asmtp002.me.com> for 19482@debbugs.gnu.org; Mon, 23 Feb 2015 02:11:07 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68,1.0.33,0.0.0000 definitions=2015-02-23_01:2015-02-20,2015-02-22,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1412110000 definitions=main-1502230020 Content-type: text/plain; charset=gb2312 MIME-version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: bug#19482: Changing to big font cause display problem From: =?gb2312?B?1cW6o779?= In-reply-to: <54EA0D3D.1070709@gmx.at> Date: Mon, 23 Feb 2015 10:11:01 +0800 Content-transfer-encoding: quoted-printable Message-id: 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> <54E9BE56.8020507@gmx.at> <8BFBB35D-B081-4B88-85A7-6CA28B9362EB@icloud.com> <54EA0D3D.1070709@gmx.at> To: martin rudalics X-Mailer: Apple Mail (2.2070.6) X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 19482 Cc: 19482@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) > =D4=DA 2015=C4=EA2=D4=C223=C8=D5=A3=AC01:09=A3=ACmartin rudalics = =D0=B4=B5=C0=A3=BA >=20 >> After issuing (set-frame-font "Menlo:size=3D30"), the dumped result: >> --------------------------------------------------------------- >> frame pixel: 1553 x 844 cols/lines: 88 x 24 units: 18 x 35 >=20 > Earlier you had a different default font height here (34 instead of = 35): >=20 > ----------------------------- (2) after issuing (set-frame-font = "Menlo:size=3D30") ---------------------- > frame pixel: 1552 x 1194 cols/lines: 86 x 35 units: 18 x 34 >=20 > Strictly spoken we should be able to explain that. >=20 > martin Sorry, my mistake.=20 I defined a command called "big-font" which actually issues = "(set-frame-font "Monospace:size=3D30")" (I just noticed this). The command doesn't work in Emacs 25. So I have set different fonts for = them. One is courier(18x34). The other is Menlo(18x35). But the display problem is not affected. From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 23 01:22:35 2015 Received: (at 19482) by debbugs.gnu.org; 23 Feb 2015 06:22:35 +0000 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 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 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 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) Message-ID: <54EAC726.8090208@swipnet.se> Date: Mon, 23 Feb 2015 07:22:30 +0100 From: "Jan D." User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: martin rudalics Subject: Re: bug#19482: Changing to big font cause display problem 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> In-Reply-To: <54EA2570.8090504@gmx.at> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 19482 Cc: =?UTF-8?B?5byg5rW35ZCb?= , 19482@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) 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. From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 24 14:10:09 2015 Received: (at 19482) by debbugs.gnu.org; 24 Feb 2015 19:10:09 +0000 Received: from localhost ([127.0.0.1]:57006 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YQKrx-0002j6-4W for submit@debbugs.gnu.org; Tue, 24 Feb 2015 14:10:09 -0500 Received: from mailfe08.swip.net ([212.247.154.225]:59831 helo=swip.net) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YQKrt-0002iW-L0 for 19482@debbugs.gnu.org; Tue, 24 Feb 2015 14:10:07 -0500 X-T2-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00 Received: from hosdjarv.se (account mj138573@tele2.se [46.59.42.57] verified) by mailfe08.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 576625662; Tue, 24 Feb 2015 20:09:58 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: bug#19482: Changing to big font cause display problem From: "Jan D." In-Reply-To: <54EAC726.8090208@swipnet.se> Date: Tue, 24 Feb 2015 20:09:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7F209FD7-19DD-4F47-A8BF-98E88EC65FCB@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> To: martin rudalics X-Mailer: Apple Mail (2.2070.6) X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 19482 Cc: =?utf-8?B?5byg5rW35ZCb?= , 19482@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Hi. > 23 feb 2015 kl. 07:22 skrev Jan D. : >=20 > Hi. >=20 > 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. >>=20 >> ... and external menubar, yes. BTW, when do we get the menu bar in = the >> title bar? One line less to count ... >=20 > 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. I could not get a definite answer to this as the semiautomatic move of = the menubar doesn't happen anymore. Maybe I need a setting. >=20 >>=20 >> > 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)) >>=20 >> Sure. But I probably can't change it without changing its clients as >> well. >=20 > 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. It is a bug, popups will popup at the wrong position. We need to track = all four sides. I'm implementing that. >=20 >>=20 >> >> 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. >>=20 >> 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. >>=20 >=20 > 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. But I still think you are confused about what is outer and inner window = here. In the macro OUTER_TO_INNER_DIFF outer refers to the window that = the windowmanager puts as Emacs parent. "Inner" here is actually the = outermost Emacs created X window, and "outer" is the window manager = window. So outer contains the title bar, but this: outer_width =3D FRAME_PIXEL_WIDTH (f) + 2 * border; outer_height =3D (FRAME_PIXEL_HEIGHT (f) + FRAME_OUTER_TO_INNER_DIFF_Y (f) + FRAME_OUTER_TO_INNER_DIFF_X (f)); is just plain wrong, because for you are calculating something that does = not correspond to any real window. For example, on Gnome 3 the window = manager puts in a window that is 10 pixels wider on both sides, so it = can do shadow effects. But the border is still one or zero pixels. So what you have calculated is not the window manager window sizes, = because inner_to_outer width is not taken into account. There actually = is no window with width FRAME_PIXEL_WIDTH + 2 * border in the Gnome 3 = case. For Gtk+/Motif/Lucid, we create a window outside the frame (i.e. = text editing part) that contains the tool bar if external, menu bar and = scroll bar. But that window is not this size either, the width would in = general contain the scroll bar for example. So what are you trying to calculate? Is it the window manager window = geometry, or the geometry of the largest Emacs created window? Jan D. From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 25 02:34:57 2015 Received: (at 19482) by debbugs.gnu.org; 25 Feb 2015 07:34:57 +0000 Received: from localhost ([127.0.0.1]:57179 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YQWUi-0006G9-Nx for submit@debbugs.gnu.org; Wed, 25 Feb 2015 02:34:57 -0500 Received: from mout.gmx.net ([212.227.15.15]:54008) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YQWUf-0006Fs-UN for 19482@debbugs.gnu.org; Wed, 25 Feb 2015 02:34:54 -0500 Received: from [188.22.238.206] ([188.22.238.206]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0M0gcI-1XX2Wg2AqU-00us6v; Wed, 25 Feb 2015 08:34:44 +0100 Message-ID: <54ED7B0F.2070101@gmx.at> Date: Wed, 25 Feb 2015 08:34:39 +0100 From: martin rudalics MIME-Version: 1.0 To: "Jan D." Subject: Re: bug#19482: Changing to big font cause display problem 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> In-Reply-To: <7F209FD7-19DD-4F47-A8BF-98E88EC65FCB@swipnet.se> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:PRVCF45FCL4t1cYvigQXAqmRwK4Wi1Q48BPqZFbzSmAVZJ0bZd1 WscNO9A5NwO7uHTL+Fv02+PjbVtHvFYeEcgjTIs2BnkyBt6Gc5tDi2dIzy5KvZY6+qHwK2W PTnl4bEO11TebtVWvuUOpNcOw/zEnf/BNlFTsxyZH1E3RPoQv/MmAyd41juMz29P1ATCnKv o24GSWu6PkOiBS+kBH7OQ== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 19482 Cc: 19482@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) > It is a bug, popups will popup at the wrong position. We need to track all four sides. > I'm implementing that. Thanks. > But I still think you are confused about what is outer and inner > window here. 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. `x-frame-geometry' should return in 'frame-outer-size' the size of the _outer window_ including any external toolbar or menubar "attached to that window" (I'm not interested in "floating" bars). This way, Emacs can check whether the outer window fits conceptually into the working area of its display. > In the macro OUTER_TO_INNER_DIFF outer refers to the > window that the windowmanager puts as Emacs parent. "Inner" here is > actually the outermost Emacs created X window, and "outer" is the > window manager window. So outer contains the title bar, IIUC the only problem is whether the "window manager window" does contain the external toolbar/mmenubar. The title bar and the external borders are definitely part of the window manager window. > but this: > > outer_width = FRAME_PIXEL_WIDTH (f) + 2 * border; > outer_height = (FRAME_PIXEL_HEIGHT (f) > + FRAME_OUTER_TO_INNER_DIFF_Y (f) > + FRAME_OUTER_TO_INNER_DIFF_X (f)); > > > is just plain wrong, because for you are calculating something that > does not correspond to any real window. For example, on Gnome 3 the > window manager puts in a window that is 10 pixels wider on both sides, > so it can do shadow effects. But the border is still one or zero > pixels. FRAME_OUTER_TO_INNER_DIFF_Y gives me only the offset of the top left corner, that is, the difference of the top edge of the outer window and the inner 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? > 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. The only thing I can do is multiply it by two. As mentioned earlier, if these differences are not symmetric, for example, because one border is larger than the other, the information provided is wrong. Again, it's the best approximation I can come up with so far. > There > actually is no window with width FRAME_PIXEL_WIDTH + 2 * border in the > Gnome 3 case. Are you sure? Does FRAME_OUTER_TO_INNER_DIFF_X not include the extra 10 pixels you mentioned above? > For Gtk+/Motif/Lucid, we create a window outside the > frame (i.e. text editing part) that contains the tool bar if external, > menu bar and scroll bar. But that window is not this size either, the > width would in general contain the scroll bar for example. That would be devastating. Scroll bars are part of the inner window. > So what are you trying to calculate? Is it the window manager window > geometry, or the geometry of the largest Emacs created window? The sizes of the outer window aka window manager window. The size of the largest Emacs created window is returned by `x-frame-geometry' for comparison purpose only (via 'frame-inner-size'). martin From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 25 04:20:23 2015 Received: (at 19482) by debbugs.gnu.org; 25 Feb 2015 09:20:23 +0000 Received: from localhost ([127.0.0.1]:57297 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YQY8k-0000Vu-1Y for submit@debbugs.gnu.org; Wed, 25 Feb 2015 04:20:22 -0500 Received: from mailfe07.swip.net ([212.247.154.193]:60410 helo=swip.net) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YQY8g-0000Vc-KV for 19482@debbugs.gnu.org; Wed, 25 Feb 2015 04:20:20 -0500 X-T2-Spam-Status: No, hits=-0.0 required=5.0 tests=BAYES_20 Received: from hosdjarv.se (account mj138573@tele2.se [46.59.42.57] verified) by mailfe07.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 574489875; Wed, 25 Feb 2015 10:20:09 +0100 Received: from jdvpro.hq.ismobile.com (unknown [176.57.193.190]) (Authenticated sender: jhd) by hosdjarv.se (Postfix) with ESMTPSA id 6EC801A01E5; Wed, 25 Feb 2015 09:20:09 +0000 (UTC) Message-ID: <54ED93C5.7020307@swipnet.se> Date: Wed, 25 Feb 2015 10:20:05 +0100 From: "Jan D." User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: martin rudalics Subject: Re: bug#19482: Changing to big font cause display problem 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> In-Reply-To: <54ED7B0F.2070101@gmx.at> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 19482 Cc: 19482@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) martin rudalics skrev den 2015-02-25 08:34: > > It is a bug, popups will popup at the wrong position. We need to > track all four sides. > > I'm implementing that. > > Thanks. > > > But I still think you are confused about what is outer and inner > > window here. > > 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. > `x-frame-geometry' should return in 'frame-outer-size' the size of the > _outer window_ including any external toolbar or menubar "attached to > that window" (I'm not interested in "floating" bars). This way, Emacs > can check whether the outer window fits conceptually into the working > area of its display. > > > In the macro OUTER_TO_INNER_DIFF outer refers to the > > window that the windowmanager puts as Emacs parent. "Inner" here is > > actually the outermost Emacs created X window, and "outer" is the > > window manager window. So outer contains the title bar, > > 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. > 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. > > > but this: > > > > outer_width = FRAME_PIXEL_WIDTH (f) + 2 * border; > > outer_height = (FRAME_PIXEL_HEIGHT (f) > > + FRAME_OUTER_TO_INNER_DIFF_Y (f) > > + FRAME_OUTER_TO_INNER_DIFF_X (f)); > > > > > > is just plain wrong, because for you are calculating something that > > does not correspond to any real window. For example, on Gnome 3 the > > window manager puts in a window that is 10 pixels wider on both sides, > > so it can do shadow effects. But the border is still one or zero > > pixels. > > FRAME_OUTER_TO_INNER_DIFF_Y gives me only the offset of the top left > corner, that is, the difference of the top edge of the outer window and > the inner window. You must specify what you mean by outer and inner. FRAME_OUTER_TO_INNER_DIFF_Y gives the diff between the outmost Emacs created window and 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. Only borders do. > > > 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 only thing I can do is multiply > it by two. As mentioned earlier, if these differences are not > symmetric, for example, because one border is larger than the other, the > information provided is wrong. Again, it's the best approximation I can > come up with so far. > > > There > > actually is no window with width FRAME_PIXEL_WIDTH + 2 * border in the > > Gnome 3 case. > > Are you sure? Does FRAME_OUTER_TO_INNER_DIFF_X not include the extra 10 > pixels you mentioned above? Yes they do. > > > For Gtk+/Motif/Lucid, we create a window outside the > > frame (i.e. text editing part) that contains the tool bar if external, > > menu bar and scroll bar. But that window is not this size either, the > > width would in general contain the scroll bar for example. > > 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. Only Emacs native scrollbar are attached to the inner Emacs window, as well as non-external (i.e. text) menu and non-external toolbar. > > > So what are you trying to calculate? Is it the window manager window > > geometry, or the geometry of the largest Emacs created window? > > The sizes of the outer window aka window manager window. The size of > the largest Emacs created window is returned by `x-frame-geometry' for > comparison purpose only (via 'frame-inner-size'). But for frame-inner-size you subtract menu and tool bar. So this is not the size of the largest Emacs created window. What are you doing with these sizes? Jan D. From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 25 05:33:27 2015 Received: (at 19482) by debbugs.gnu.org; 25 Feb 2015 10:33:27 +0000 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 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 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 Message-ID: <54EDA4E1.2060304@gmx.at> Date: Wed, 25 Feb 2015 11:33:05 +0100 From: martin rudalics MIME-Version: 1.0 To: "Jan D." Subject: Re: bug#19482: Changing to big font cause display problem 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> In-Reply-To: <54ED93C5.7020307@swipnet.se> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:52QGn3IekvHh6bIytweQmrIkvx60D7U3odihP4exXFZzAKxYdOZ EZ64aRFBsTOAt/mcPYUxAxCdsWBlCgHdbkp6sq55JbmXOcGs7Y2xQXCHom1gwZw5IZiBYS8 qx2uA3J/gTxFP3MfLlWi+ysuTKoImfe0PfoKw48AQUOdYktYyazVA000nsAFETrDsvFgPqc rXl3XdvLNtCuwVKJ+SaSw== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 19482 Cc: 19482@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) >> 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 From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 25 10:28:09 2015 Received: (at 19482) by debbugs.gnu.org; 25 Feb 2015 15:28:09 +0000 Received: from localhost ([127.0.0.1]:57894 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YQdse-00043g-A5 for submit@debbugs.gnu.org; Wed, 25 Feb 2015 10:28:09 -0500 Received: from mailfe08.swip.net ([212.247.154.225]:37031 helo=swip.net) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YQdsa-00043A-Lg for 19482@debbugs.gnu.org; Wed, 25 Feb 2015 10:28:06 -0500 X-T2-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00 Received: from hosdjarv.se (account mj138573@tele2.se [46.59.42.57] verified) by mailfe08.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 576859983; Wed, 25 Feb 2015 16:27:56 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: bug#19482: Changing to big font cause display problem From: "Jan D." In-Reply-To: <54EDA4E1.2060304@gmx.at> Date: Wed, 25 Feb 2015 16:27:55 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: 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> To: martin rudalics X-Mailer: Apple Mail (2.2070.6) X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 19482 Cc: 19482@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Hi. > 25 feb 2015 kl. 11:33 skrev martin rudalics : >=20 > >> 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. >=20 > Then how do I get the size of the outer window (the size of the object > returned by FRAME_OUTER_WINDOW)? >=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. > >> 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. >=20 > Are you sure? Like a gazillion percent sure. > External menu and tool bars bars are normally in between > title bar and the inner window so how can they not be counted? --------------------------------------------------------- | Window manager window, title bar | -------------------------------------------------------- | | Emacs outer window, menu bar =20 | | tool bar | | ------------------------------------------------------ | | | Emacs inner window, text and scrollbar | | | 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. The non-external tool bar, the non-external menubar are in the inner = window. But toolkit menubar/toolbar are in the outer window. >=20 > >> 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. >=20 > Where does Emacs set external borders? Do we really control that? >=20 In xfns.c, for the toolkit (Motif/Lucid case): XtSetArg (al[ac], XtNborderWidth, f->border_width); ac++; for the non-toolkit, and tooltip case (xfns.c) in the call to = XCreateWindow. For the Gtk+ case we don't set any, the default is taken from wathever = theme is in place. The border is usually 0 pixel. > > You must specify what you mean by outer and > > inner. >=20 > I did that and it's still cited at the top of this post. >=20 > > FRAME_OUTER_TO_INNER_DIFF_Y gives the diff between the outmost > > Emacs created window and the window manager window. >=20 > 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). Correct. > What's missing is the diff between the _bottom edge_ of the outmost > created window and that of the window manager window. Yes. >=20 > >> 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? > > >=20 > > 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. >=20 > I am interested in the size of the "window manager window". Ok. >=20 > > Only borders do. >=20 > I also need title bar, external tool and menu bar. 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 > >> > 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. >=20 > 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? No, because that is not true. > And > that the "outmost Emacs created window" is the one whose sizes are > specified by FRAME_PIXEL_WIDTH and FRAME_PIXEL_HEIGHT? Yes, that is FRAME_OUTER_WINDOW. > If so, then >=20 > "outer window" is equivalent to "window manager window" No. >=20 > and >=20 > "inner window" is equivalent to "outmost Emacs created window" >=20 No. There are three windows involved, se figure above. > >> Are you sure? Does FRAME_OUTER_TO_INNER_DIFF_X not include the = extra 10 > >> pixels you mentioned above? > > > > Yes they do. >=20 > Then my calculation should handle this case (and obviously seems to = fail > for the external border at the bottom of such a frame). >=20 > >> 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. >=20 > 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. I was wrong, scrollbars are on the inner window. Don't know where I got = that from. >=20 > > as well as non-external (i.e. text) menu and non-external toolbar. >=20 > These are part of the inner window. Yes, the non-external are. The external are not. >=20 > > But for frame-inner-size you subtract menu and tool bar. So this is > > not the size of the largest Emacs created window. >=20 > 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. >=20 > > What are you doing with these sizes? >=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 This is a job for the window manager. Some window managers constrain = the size of Emacs, some do not. 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? 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). > Also I want the sizes of external tool and menu bar for debugging = things > like the various maximized/fullsize variants. That makes sense. Jan D. From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 25 12:33:48 2015 Received: (at 19482) by debbugs.gnu.org; 25 Feb 2015 17:33:48 +0000 Received: from localhost ([127.0.0.1]:58019 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YQfqF-0007UH-Ha for submit@debbugs.gnu.org; Wed, 25 Feb 2015 12:33:48 -0500 Received: from mout.gmx.net ([212.227.17.20]:60671) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YQfqD-0007U2-Bw for 19482@debbugs.gnu.org; Wed, 25 Feb 2015 12:33:46 -0500 Received: from [188.22.238.206] ([188.22.238.206]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M6P5z-1Xc1zh14O3-00yOfU; Wed, 25 Feb 2015 18:33:34 +0100 Message-ID: <54EE0767.1090407@gmx.at> Date: Wed, 25 Feb 2015 18:33:27 +0100 From: martin rudalics MIME-Version: 1.0 To: "Jan D." Subject: Re: bug#19482: Changing to big font cause display problem 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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:U8U/Q9HiUmeXqiqU1q2CA3HsujEz7LaOkFJ6PYtRvhexyGarqyO UymmbYiWtXw3+VRcEnYULvxGPwH0BKK60EtkRwbm9+J570kP+FNjHztRuGkEUEE+Kx8vxho I9juIE73uCbI73tvSoFURVBLgFXr0XuWp/5Xn7o1dzBLsbpflMYOMB0mhKPHaHOvb2mXP0v mWUwKFOyj8axlulrCxDPA== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 19482 Cc: 19482@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) >> Then how do I get the size of the outer window (the size of the object >> returned by FRAME_OUTER_WINDOW)? >> > > 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. With "borders" you mean external borders, I presume. 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? 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? >>>> 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? > > Like a gazillion percent sure. 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. I say that the window manager window contains the title bar and the Emacs outer window. >> External menu and tool bars bars are normally in between >> title bar and the inner window so how can they not be counted? > > --------------------------------------------------------- > | Window manager window, title bar > | -------------------------------------------------------- > | | Emacs outer window, menu bar > | | tool bar > | | ------------------------------------------------------ > | | | Emacs inner window, text and scrollbar > | | | > 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. 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? > 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. But it's still where the internal borders are? >> I also need title bar, external tool and menu bar. > > 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. Then we can do nothing in these cases. >> 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. >> > > This is a job for the window manager. Some window managers constrain the size of Emacs, some do not. 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. 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. > 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? 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. > 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). The OP proposed an option to do that. martin From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 25 13:25:14 2015 Received: (at 19482) by debbugs.gnu.org; 25 Feb 2015 18:25:14 +0000 Received: from localhost ([127.0.0.1]:58053 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YQge1-0000GV-On for submit@debbugs.gnu.org; Wed, 25 Feb 2015 13:25:14 -0500 Received: from mailfe09.swip.net ([212.247.155.1]:48099 helo=swip.net) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YQgdx-0000GF-UP for 19482@debbugs.gnu.org; Wed, 25 Feb 2015 13:25:11 -0500 X-T2-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00 Received: from hosdjarv.se (account mj138573@tele2.se [46.59.42.57] verified) by mailfe09.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 402767117; Wed, 25 Feb 2015 19:25:02 +0100 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: bug#19482: Changing to big font cause display problem From: "Jan D." In-Reply-To: <54EE0767.1090407@gmx.at> Date: Wed, 25 Feb 2015 19:25:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <384E8844-0873-4204-89D0-A120E94683C9@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> To: martin rudalics X-Mailer: Apple Mail (2.2070.6) X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 19482 Cc: 19482@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) > 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)? > >> > > > > 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. Yes. > 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? 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. > 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? 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). 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 > >>>> 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? > > > > 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. No, the window manager contains them both, the title bar above Emacs = outer window. > I say that the window manager window > contains the title bar and the Emacs outer window. Right. >=20 > >> External menu and tool bars bars are normally in between > >> title bar and the inner window so how can they not be counted? > > > > --------------------------------------------------------- > > | Window manager window, title bar > > | -------------------------------------------------------- > > | | Emacs outer window, menu bar > > | | tool bar > > | | ------------------------------------------------------ > > | | | Emacs inner window, text and scrollbar > > | | | > > >=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. 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 > > 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? They are in the inner window. >=20 > >> I also need title bar, external tool and menu bar. > > > > 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. Right. >=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. > >> > > > > 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. Some window managers already do that for you. > 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. Then how do you allow for spanning between monitors? >=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. Jan D. From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 25 14:01:13 2015 Received: (at 19482) by debbugs.gnu.org; 25 Feb 2015 19:01:13 +0000 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 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 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 Message-ID: <54EE1BE2.2060008@gmx.at> Date: Wed, 25 Feb 2015 20:00:50 +0100 From: martin rudalics MIME-Version: 1.0 To: "Jan D." Subject: Re: bug#19482: Changing to big font cause display problem 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> In-Reply-To: <384E8844-0873-4204-89D0-A120E94683C9@swipnet.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:JWfsMc0YAkdFdiw6Qh70UgnMBBnM0BuyZ1ZQswEBKJjxThLjHff 7HvutNElQ1A2eZgNCzPZ/GL7KM4cr4o/Tn3fZkm2yoJKBywugUAQlM4qCdS89EIxkUua7s3 EJa5JvqkyVp3oNfvVc+YQbQ2Qgyl5uWao87Tw9KfUpYCvXnLMa+r+9d25xkxWKRUQkzvvlJ sX62gWoyF7NpGspDNc5hQ== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 19482 Cc: 19482@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) >> 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 From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 25 14:18:06 2015 Received: (at 19482) by debbugs.gnu.org; 25 Feb 2015 19:18:06 +0000 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 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 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 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: bug#19482: Changing to big font cause display problem From: "Jan D." In-Reply-To: <384E8844-0873-4204-89D0-A120E94683C9@swipnet.se> Date: Wed, 25 Feb 2015 20:17:53 +0100 Content-Transfer-Encoding: quoted-printable 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> To: martin rudalics X-Mailer: Apple Mail (2.2070.6) X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 19482 Cc: 19482@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) 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 From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 25 15:23:01 2015 Received: (at 19482) by debbugs.gnu.org; 25 Feb 2015 20:23:01 +0000 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 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 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 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: bug#19482: Changing to big font cause display problem From: "Jan D." In-Reply-To: <54EE1BE2.2060008@gmx.at> Date: Wed, 25 Feb 2015 21:22:48 +0100 Content-Transfer-Encoding: quoted-printable 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> To: martin rudalics X-Mailer: Apple Mail (2.2070.6) X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 19482 Cc: 19482@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) 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. From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 27 03:30:54 2015 Received: (at 19482) by debbugs.gnu.org; 27 Feb 2015 08:30:54 +0000 Received: from localhost ([127.0.0.1]:59229 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YRGJx-0000mj-MA for submit@debbugs.gnu.org; Fri, 27 Feb 2015 03:30:54 -0500 Received: from mout.gmx.net ([212.227.17.22]:53707) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YRGJq-0000mQ-Ee for 19482@debbugs.gnu.org; Fri, 27 Feb 2015 03:30:48 -0500 Received: from [194.118.143.137] ([194.118.143.137]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MFi1J-1YFQLL2ugv-00EeP4; Fri, 27 Feb 2015 09:30:38 +0100 Message-ID: <54F02B23.9040504@gmx.at> Date: Fri, 27 Feb 2015 09:30:27 +0100 From: martin rudalics MIME-Version: 1.0 To: "Jan D." Subject: Re: bug#19482: Changing to big font cause display problem References: <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> <0EC97186-BC13-4ABB-A86C-B1AA5287748B@swipnet.se> In-Reply-To: <0EC97186-BC13-4ABB-A86C-B1AA5287748B@swipnet.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:DmyG6R1JgoKOQUhcEYyEWRraGv7i5IEqV5enX6KVVwFyjPYAg2X F3dnjHO1OVyxE2hNYp5lJf0fEocatR3Fz8XrpcXOXhjQOcTyTHyk7cQoQSgHcMCe5UqJ7Fd zquRY7AvMzSaVqTt5Y2tboVOE9Q04Rg+OjU5LhF6mzuy1i+ERtWIKuTcKX8S964dMhbwWG1 80RjOW3EWKRYFC3byRvLQ== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 19482 Cc: 19482@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) >> 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. Here the border appears above the title bar so it's drawn around the window manager window. Do you really see the external border below the title bar? > 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. Then strictly spoken `set-default-font' should not ask the window manager to change the size of our window. martin From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 27 03:31:10 2015 Received: (at 19482) by debbugs.gnu.org; 27 Feb 2015 08:31:10 +0000 Received: from localhost ([127.0.0.1]:59233 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YRGKD-0000na-Hk for submit@debbugs.gnu.org; Fri, 27 Feb 2015 03:31:09 -0500 Received: from mout.gmx.net ([212.227.17.21]:63396) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YRGKB-0000n2-Ch for 19482@debbugs.gnu.org; Fri, 27 Feb 2015 03:31:07 -0500 Received: from [194.118.143.137] ([194.118.143.137]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MBrCt-1YKM1a1RNn-00Ajx0; Fri, 27 Feb 2015 09:30:53 +0100 Message-ID: <54F02B33.5000408@gmx.at> Date: Fri, 27 Feb 2015 09:30:43 +0100 From: martin rudalics MIME-Version: 1.0 To: "Jan D." Subject: Re: bug#19482: Changing to big font cause display problem References: <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> <866CADAE-2B20-42FF-BCAB-E5D9DFAA4AFD@swipnet.se> In-Reply-To: <866CADAE-2B20-42FF-BCAB-E5D9DFAA4AFD@swipnet.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:pLcHqYZyq81crUmX/+Jv2w0Ad4/rvk/KWw3JmtXqvRSbeBnT7gF mXBH7JBkVrdM/f4fjc7sBmUeedjGuXMn5FaCFfQrvUZ1gsbpIQ6Rtk88uoMC7aMD9Bb/M8a qBJ1/O3haZqRIwDW2v8iq9/wvB8EEaUDG2t+zW9JLaPg2i+U0pTJnHqgynTUOk2b3PtxzDd 4fRi9sDVGg+6nU/oGDUow== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 19482 Cc: 19482@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) > I redid the whole INNER_TO_OUTER thing, and now handle all sides. > The macros INNER_TO_OUTER are removed. Thanks. I'm a bit lost currently because there seem to be problems here, at least with my GTK+3 build on the Xfce desktop. I've tried to debug x_real_pos_and_offsets with emacs -Q but still am not able to find out what's wrong. Maybe you can help with the following two issues. (1) `x-frame-geometry' reports an external border width of zero for a normal, non-maximized frame. That's clearly wrong, the width is 5 pixels. I have no idea how to track down what XGetWindowAttributes retrieves here. (2) `x-frame-geometry' reports a title height of 5. This is wrong - the title height is 20 pixels. I don't yet understand how x_real_pos_and_offsets works but I strongly suppose that if (top_offset_y) *top_offset_y = -outer_x; should be if (top_offset_y) *top_offset_y = -outer_y; at least. Also, these two assignments outer_width = FRAME_PIXEL_WIDTH (f) + 2 * border + right_off + left_off; outer_height = FRAME_PIXEL_HEIGHT (f) + 2 * border + top_off + bottom_off; should _not_ use FRAME_PIXEL_HEIGHT and FRAME_PIXEL_WIDTH because that would mean that I counter-check our calculations of frame sizes from these calculations. What we should use here are the 'width' and 'height' attributes as returned by XWindowAttributes. I haven't checked yet but do we conceptually assume that FRAME_PIXEL_WIDTH (f) == atts.width FRAME_PIXEL_HEIGHT (f) == atts.height Or does something additionally come into play here? Thanks, martin From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 27 12:49:48 2015 Received: (at 19482) by debbugs.gnu.org; 27 Feb 2015 17:49:48 +0000 Received: from localhost ([127.0.0.1]:60182 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YRP2p-00009J-Td for submit@debbugs.gnu.org; Fri, 27 Feb 2015 12:49:48 -0500 Received: from mailfe07.swip.net ([212.247.154.193]:51350 helo=swip.net) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YRP2m-000093-UE for 19482@debbugs.gnu.org; Fri, 27 Feb 2015 12:49:46 -0500 X-T2-Spam-Status: No, hits=-0.0 required=5.0 tests=BAYES_20 Received: from hosdjarv.se (account mj138573@tele2.se [46.59.42.57] verified) by mailfe07.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 575220623; Fri, 27 Feb 2015 18:49:36 +0100 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: bug#19482: Changing to big font cause display problem From: "Jan D." In-Reply-To: <54F02B23.9040504@gmx.at> Date: Fri, 27 Feb 2015 18:49:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2401B659-BBAD-4D97-A1FE-EC95D0D40FC9@swipnet.se> References: <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> <0EC97186-BC13-4ABB-A86C-B1AA5287748B@swipnet.se> <54F02B23.9040504@gmx.at> To: martin rudalics X-Mailer: Apple Mail (2.2070.6) X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 19482 Cc: 19482@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) > 27 feb 2015 kl. 09:30 skrev martin rudalics : >=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. >=20 > Here the border appears above the title bar so it's drawn around the > window manager window. Do you really see the external border below = the > title bar? No, but thats because I have a hard time finding a window manager that = does not override the border width and sets it to 0, jsu because it = looks bad. What you see is probably not the border, but the window = manager decorations. >=20 > > 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. >=20 > Then strictly spoken `set-default-font' should not ask the window > manager to change the size of our window. That is a separate issue. It is up tp the application if it want to = request a new size. But it is up to the window manager if it wants to = grant or constrain that request. Jan D. From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 27 12:53:05 2015 Received: (at 19482) by debbugs.gnu.org; 27 Feb 2015 17:53:05 +0000 Received: from localhost ([127.0.0.1]:60187 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YRP60-0000EH-Jc for submit@debbugs.gnu.org; Fri, 27 Feb 2015 12:53:04 -0500 Received: from mailfe08.swip.net ([212.247.154.225]:45593 helo=swip.net) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YRP5t-0000Di-L0 for 19482@debbugs.gnu.org; Fri, 27 Feb 2015 12:53:03 -0500 X-T2-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00 Received: from hosdjarv.se (account mj138573@tele2.se [46.59.42.57] verified) by mailfe08.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 577487206; Fri, 27 Feb 2015 18:52:50 +0100 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: bug#19482: Changing to big font cause display problem From: "Jan D." In-Reply-To: <54F02B33.5000408@gmx.at> Date: Fri, 27 Feb 2015 18:52:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6FED55D8-36C4-4D3D-9935-E3D428D1896F@swipnet.se> References: <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> <866CADAE-2B20-42FF-BCAB-E5D9DFAA4AFD@swipnet.se> <54F02B3 3.5000408@gmx.at> To: martin rudalics X-Mailer: Apple Mail (2.2070.6) X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 19482 Cc: 19482@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) > 27 feb 2015 kl. 09:30 skrev martin rudalics : >=20 > > I redid the whole INNER_TO_OUTER thing, and now handle all sides. > > The macros INNER_TO_OUTER are removed. >=20 > Thanks. I'm a bit lost currently because there seem to be problems > here, at least with my GTK+3 build on the Xfce desktop. I've tried to > debug x_real_pos_and_offsets with emacs -Q but still am not able to = find > out what's wrong. Maybe you can help with the following two issues. >=20 > (1) `x-frame-geometry' reports an external border width of zero for a > normal, non-maximized frame. That's clearly wrong, the width is 5 > pixels. I have no idea how to track down what XGetWindowAttributes > retrieves here. As I said in another mail, this is probably the window manager = decorations, not a window border. 5 pixels is a large window border, = but a reasonable window manager decoration. However, I added the window manager window border to the calculations, = but I suspect it is 0 all the time. In theory it could be something else. >=20 > (2) `x-frame-geometry' reports a title height of 5. This is wrong - = the > title height is 20 pixels. I don't yet understand how > x_real_pos_and_offsets works but I strongly suppose that >=20 > if (top_offset_y) *top_offset_y =3D -outer_x; >=20 > should be >=20 > if (top_offset_y) *top_offset_y =3D -outer_y; >=20 > at least. >=20 Typo, fixed now. > Also, these two assignments >=20 > outer_width =3D FRAME_PIXEL_WIDTH (f) + 2 * border + right_off + = left_off; > outer_height =3D FRAME_PIXEL_HEIGHT (f) + 2 * border + top_off + = bottom_off; >=20 > should _not_ use FRAME_PIXEL_HEIGHT and FRAME_PIXEL_WIDTH because that > would mean that I counter-check our calculations of frame sizes from > these calculations. What we should use here are the 'width' and = 'height' > attributes as returned by XWindowAttributes. Indeed. >=20 > I haven't checked yet but do we conceptually assume that >=20 > FRAME_PIXEL_WIDTH (f) =3D=3D atts.width > FRAME_PIXEL_HEIGHT (f) =3D=3D atts.height >=20 > Or does something additionally come into play here? attts.height contains the external menu bar and tool bar, but = PIXEL_HEIGHT does not. I did not think that one through. Jan D. From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 27 14:56:39 2015 Received: (at 19482) by debbugs.gnu.org; 27 Feb 2015 19:56:39 +0000 Received: from localhost ([127.0.0.1]:60221 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YRR1b-0003HH-86 for submit@debbugs.gnu.org; Fri, 27 Feb 2015 14:56:39 -0500 Received: from mout.gmx.net ([212.227.17.21]:56798) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YRR1Y-0003Gw-QX for 19482@debbugs.gnu.org; Fri, 27 Feb 2015 14:56:37 -0500 Received: from [178.189.200.198] ([178.189.200.198]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LZmd6-1Xmd5533Nc-00lRNE; Fri, 27 Feb 2015 20:56:27 +0100 Message-ID: <54F0CA67.4050608@gmx.at> Date: Fri, 27 Feb 2015 20:49:59 +0100 From: martin rudalics MIME-Version: 1.0 To: "Jan D." Subject: Re: bug#19482: Changing to big font cause display problem References: <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> <866CADAE-2B20-42FF-BCAB-E5D9DFAA4AFD@swipnet.se> <54F02B3 3.5000408@gmx.at> <6FED55D8-36C4-4D3D-9935-E3D428D1896F@swipnet.se> In-Reply-To: <6FED55D8-36C4-4D3D-9935-E3D428D1896F@swipnet.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:3D2tSS2ZsFQ4uXGxVf4/NFZGoqPAHOZ8iPNuLNc9aL9JmPvjI6x 0Gf296wKc90hxFKMEORowtZWt0gTs0hf52SF1h8eEe6x8xqNr06Vx4P7RG4VPq3WTdV2L1x 8p1MXdIYRLFOwpwcFLCBuP6jakY/lf47GPial+urY4Pt995isBowuFwoaxr8l6TIkYZmWuU dQx20GhFQwzDL+uIp8Y/A== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 19482 Cc: 19482@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) >> (1) `x-frame-geometry' reports an external border width of zero for a >> normal, non-maximized frame. That's clearly wrong, the width is 5 >> pixels. I have no idea how to track down what XGetWindowAttributes >> retrieves here. > > As I said in another mail, this is probably the window manager decorations, not a window border. 5 pixels is a large window border, but a reasonable window manager decoration. > However, I added the window manager window border to the calculations, but I suspect it is 0 all the time. > In theory it could be something else. In my book the border is that thing I have to drag in order to resize a window with the mouse. Is that wrong? Does that mean that the border reported by XGetWindowAttributes is not the same as the border reported by XGetGeometry? In this case we should probably not ignore the eight argument of the latter. >> (2) `x-frame-geometry' reports a title height of 5. This is wrong - the >> title height is 20 pixels. I don't yet understand how >> x_real_pos_and_offsets works but I strongly suppose that >> >> if (top_offset_y) *top_offset_y = -outer_x; >> >> should be >> >> if (top_offset_y) *top_offset_y = -outer_y; >> >> at least. >> > > Typo, fixed now. Thanks. >> Also, these two assignments >> >> outer_width = FRAME_PIXEL_WIDTH (f) + 2 * border + right_off + left_off; >> outer_height = FRAME_PIXEL_HEIGHT (f) + 2 * border + top_off + bottom_off; >> >> should _not_ use FRAME_PIXEL_HEIGHT and FRAME_PIXEL_WIDTH because that >> would mean that I counter-check our calculations of frame sizes from >> these calculations. What we should use here are the 'width' and 'height' >> attributes as returned by XWindowAttributes. > > Indeed. > >> >> I haven't checked yet but do we conceptually assume that >> >> FRAME_PIXEL_WIDTH (f) == atts.width >> FRAME_PIXEL_HEIGHT (f) == atts.height >> >> Or does something additionally come into play here? > > attts.height contains the external menu bar and tool bar, but PIXEL_HEIGHT does not. I did not think that one through. OK. I'll try to play around with these. martin From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 27 15:29:42 2015 Received: (at 19482) by debbugs.gnu.org; 27 Feb 2015 20:29:42 +0000 Received: from localhost ([127.0.0.1]:60244 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YRRXZ-00046X-Uh for submit@debbugs.gnu.org; Fri, 27 Feb 2015 15:29:42 -0500 Received: from mailfe04.swip.net ([212.247.154.97]:36822 helo=swip.net) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YRRXW-00046H-RM for 19482@debbugs.gnu.org; Fri, 27 Feb 2015 15:29:40 -0500 X-T2-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00 Received: from hosdjarv.se (account mj138573@tele2.se [46.59.42.57] verified) by mailfe04.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 574918408; Fri, 27 Feb 2015 21:29:30 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: bug#19482: Changing to big font cause display problem From: "Jan D." X-Mailer: iPad Mail (12B466) In-Reply-To: <54F0CA67.4050608@gmx.at> Date: Fri, 27 Feb 2015 21:29:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <83C4500A-4001-49C5-8670-6678BEC58DAC@swipnet.se> References: <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> <866CADAE-2B20-42FF-BCAB-E5D9DFAA4AFD@swipnet.se> <54F02B3 3.5000408@gmx.at> <6FED55D8-36C4-4D3D-9935-E3D428D1896F@swipnet.se> <54F0CA 67.4050608@gmx.at> To: martin rudalics X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 19482 Cc: "19482@debbugs.gnu.org" <19482@debbugs.gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Hi.=20 > 27 feb 2015 kl. 20:49 skrev martin rudalics : >=20 > >> (1) `x-frame-geometry' reports an external border width of zero for a > >> normal, non-maximized frame. That's clearly wrong, the width is 5 > >> pixels. I have no idea how to track down what XGetWindowAttributes= > >> retrieves here. > > > > As I said in another mail, this is probably the window manager decoratio= ns, not a window border. 5 pixels is a large window border, but a reasonabl= e window manager decoration. > > However, I added the window manager window border to the calculations, b= ut I suspect it is 0 all the time. > > In theory it could be something else. >=20 > In my book the border is that thing I have to drag in order to resize a > window with the mouse. Is that wrong? Does that mean that the border > reported by XGetWindowAttributes is not the same as the border reported > by XGetGeometry? In this case we should probably not ignore the eight > argument of the latter. The thing you drag to resize is not the X11 window border, it is a decoratio= n drawn by the window manager in the window manager window. The border from X= GetGeometry is the same as the one in XGetWindowAttributes. Jan D.=20= From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 01 10:15:18 2015 Received: (at 19482) by debbugs.gnu.org; 1 Mar 2015 15:15:18 +0000 Received: from localhost ([127.0.0.1]:33428 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YS5aP-00052z-OQ for submit@debbugs.gnu.org; Sun, 01 Mar 2015 10:15:18 -0500 Received: from mout.gmx.net ([212.227.15.18]:58089) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YS5aN-00052j-FE for 19482@debbugs.gnu.org; Sun, 01 Mar 2015 10:15:16 -0500 Received: from [194.118.137.119] ([194.118.137.119]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MVvB2-1XzX883T0S-00X6Wj; Sun, 01 Mar 2015 16:15:08 +0100 Message-ID: <54F32CF1.3070509@gmx.at> Date: Sun, 01 Mar 2015 16:14:57 +0100 From: martin rudalics MIME-Version: 1.0 To: "Jan D." Subject: Re: bug#19482: Changing to big font cause display problem References: <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> <866CADAE-2B20-42FF-BCAB-E5D9DFAA4AFD@swipnet.se> <54F02B3 3.5000408@gmx.at> <6FED55D8-36C4-4D3D-9935-E3D428D1896F@swipnet.se> <54F0CA67.4050608@gmx.at> In-Reply-To: <54F0CA67.4050608@gmx.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:9VSd2IYsaHx0ZBbHtey7vleZsCcGfqdiRBIIG7uE2K/tJuWHaeb hCadCfw/sarfbejKw3iX9XzzOVRevM++dHb5Ml5LCuLFOvR9R+PxFdqe9K9dc5yQ2U/zy5V HmNKVLE1RXhUCwf3IChO07vCyd6aqwY/MBH9OfT2tGSEBXNPpsjvCYXWOSaMSzVjxY/aNEB dUfyziQ3WWCVI2j4Bq8mA== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 19482 Cc: 19482@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Hi Jan For my Gtk+ frame I currently get the following values for (x-frame-geometry): (frame-outer-size 762 . 729) (external-border-size 0 . 0) (title-height . 25) (menu-bar-external . t) (menu-bar-size 752 . 25) (tool-bar-external . t) (tool-bar-position . top) (tool-bar-size 752 . 44) (frame-inner-size 752 . 630) Now the sum of inner frame, tool bar, menu bar and title bar heights gets me 724 (630 + 44 + 25 + 25) which means there are five pixels missing wrt to the height of the outer frame. These are obviously from the bottom of the frame (bottom_off being 5 here) while apparently the five pixels of the decoration at the top of the frame are not counted in top_off. The 5 + 5 missing pixels on the left and right of the frame come from left_off and right_off, respectively. The results for Lucid, Motif and without toolkit frames are similar. So I'd like to conclude that the size of my decorations are 5 everywhere but I cannot find the 5 pixels from the decoration at the top. 25 pixels for the title bar sound reasonable, it appears quite as large as the menu bar. Any ideas? Thanks, martin From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 01 11:19:11 2015 Received: (at 19482) by debbugs.gnu.org; 1 Mar 2015 16:19:11 +0000 Received: from localhost ([127.0.0.1]:33457 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YS6aE-0006ci-KA for submit@debbugs.gnu.org; Sun, 01 Mar 2015 11:19:10 -0500 Received: from mailfe03.swip.net ([212.247.154.65]:37976 helo=swip.net) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YS6aC-0006cG-99 for 19482@debbugs.gnu.org; Sun, 01 Mar 2015 11:19:09 -0500 X-T2-Spam-Status: No, hits=-0.0 required=5.0 tests=BAYES_40 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 410303848; Sun, 01 Mar 2015 17:18:59 +0100 Message-ID: <54F33BEF.20403@swipnet.se> Date: Sun, 01 Mar 2015 17:18:55 +0100 From: "Jan D." User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: martin rudalics Subject: Re: bug#19482: Changing to big font cause display problem References: <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> <866CADAE-2B20-42FF-BCAB-E5D9DFAA4AFD@swipnet.se> <54F02B3 3.5000408@gmx.at> <6FED55D8-36C4-4D3D-9935-E3D428D1896F@swipnet.se> <54F0CA67.4050608@gmx.at> <54F32CF1.3070509@gmx.at> In-Reply-To: <54F32CF1.3070509@gmx.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 19482 Cc: 19482@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) martin rudalics skrev 2015-03-01 16:14: > Hi Jan > Hi. > For my Gtk+ frame I currently get the following values for > (x-frame-geometry): > > (frame-outer-size 762 . 729) > (external-border-size 0 . 0) > (title-height . 25) > (menu-bar-external . t) > (menu-bar-size 752 . 25) > (tool-bar-external . t) > (tool-bar-position . top) > (tool-bar-size 752 . 44) > (frame-inner-size 752 . 630) > > Now the sum of inner frame, tool bar, menu bar and title bar heights > gets me 724 (630 + 44 + 25 + 25) which means there are five pixels > missing wrt to the height of the outer frame. These are obviously from > the bottom of the frame (bottom_off being 5 here) while apparently the > five pixels of the decoration at the top of the frame are not counted in > top_off. The 5 + 5 missing pixels on the left and right of the frame > come from left_off and right_off, respectively. The results for Lucid, > Motif and without toolkit frames are similar. > > So I'd like to conclude that the size of my decorations are 5 everywhere > but I cannot find the 5 pixels from the decoration at the top. 25 > pixels for the title bar sound reasonable, it appears quite as large as > the menu bar. Any ideas? > We can only calculate the difference between Emacs top and the window manager window top. So the 5 pixels you are looking for are part of title-height. title-height should really be named "whatever the window manager window puts above the top of our Emacs window". It can be title bar, title bar + decoration, or just about anything. We can't know. Jan D. From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 10 10:36:29 2015 Received: (at 19482) by debbugs.gnu.org; 10 Mar 2015 14:36:29 +0000 Received: from localhost ([127.0.0.1]:41814 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YVLGi-0006KX-Bq for submit@debbugs.gnu.org; Tue, 10 Mar 2015 10:36:29 -0400 Received: from st13p27im-asmtp001.me.com ([17.162.190.63]:58949) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YVLGc-0006KC-6u for 19482@debbugs.gnu.org; Tue, 10 Mar 2015 10:36:22 -0400 Received: from [192.168.1.115] (unknown [218.109.253.191]) by st13p27im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Dec 4 2014)) with ESMTPSA id <0NL000BJC3865930@st13p27im-asmtp001.me.com> for 19482@debbugs.gnu.org; Tue, 10 Mar 2015 14:36:11 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68,1.0.33,0.0.0000 definitions=2015-03-10_05:2015-03-10,2015-03-10,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1412110000 definitions=main-1503100148 Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: bug#19482: Changing to big font cause display problem From: =?gb2312?B?1cW6o779?= In-reply-to: <7F209FD7-19DD-4F47-A8BF-98E88EC65FCB@swipnet.se> Date: Tue, 10 Mar 2015 22:36:02 +0800 Content-transfer-encoding: 7bit Message-id: <45FCBE39-1812-49AA-83C8-37578292F34C@icloud.com> 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> To: "Jan D." X-Mailer: Apple Mail (2.2070.6) X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 19482 Cc: martin rudalics , 19482@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) In Emacs 24.4.91, this bug still exist. Will it be fixed in 24.5? From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 10 14:48:00 2015 Received: (at 19482) by debbugs.gnu.org; 10 Mar 2015 18:48:00 +0000 Received: from localhost ([127.0.0.1]:41921 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YVPCB-0007Wu-VK for submit@debbugs.gnu.org; Tue, 10 Mar 2015 14:48:00 -0400 Received: from mout.gmx.net ([212.227.15.15]:65341) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YVPCA-0007Wf-Ry for 19482@debbugs.gnu.org; Tue, 10 Mar 2015 14:47:59 -0400 Received: from [88.117.87.76] ([88.117.87.76]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MKIEQ-1YTklV2PB8-001mRt; Tue, 10 Mar 2015 19:47:51 +0100 Message-ID: <54FF3C54.8010601@gmx.at> Date: Tue, 10 Mar 2015 19:47:48 +0100 From: martin rudalics MIME-Version: 1.0 To: =?UTF-8?B?5byg5rW35ZCb?= , "Jan D." Subject: Re: bug#19482: Changing to big font cause display problem 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> <45FCBE39-1812-49AA-83C8-37578292F34C@icloud.com> In-Reply-To: <45FCBE39-1812-49AA-83C8-37578292F34C@icloud.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:fZG4beFmlvbNGLF5tz5rhLBMOELPMm3yjisQAzB89DC+JmTFi7Z hp9oNatXcU0GJpsLfMEHo/6+uft0vH3G+R5s+IhoYhzHE96K+vXv5Hhdkguym4IdA13USAY 0bYP4iZgEn4KT6o98mk+Ngb1j58RZAzyCGOkq0Az6mBPZKTjiEnkl36ihafXc+CzUDZsWqp tNRdspLpMneGxZz4+rbXA== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 19482 Cc: 19482@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) > In Emacs 24.4.91, this bug still exist. Will it be fixed in 24.5? I don't have any clue what might have made it disappear in Emacs 25. Maybe Jan can help (I suppose he made the corresponding change). You could try to bisect Emacs 25 and find the most recent build where it did not work. But the subsequent change might be to big in order to get safely applied to Emacs 24.5 so I cannot really recommend it. martin From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 12 01:15:04 2015 Received: (at 19482) by debbugs.gnu.org; 12 Mar 2015 05:15:05 +0000 Received: from localhost ([127.0.0.1]:43331 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YVvSZ-0000yH-BC for submit@debbugs.gnu.org; Thu, 12 Mar 2015 01:15:04 -0400 Received: from mailfe05.swip.net ([212.247.154.129]:48145 helo=swip.net) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YVvSV-0000xi-7F for 19482@debbugs.gnu.org; Thu, 12 Mar 2015 01:15:00 -0400 X-T2-Spam-Status: No, hits=-0.0 required=5.0 tests=BAYES_40 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 575092821; Thu, 12 Mar 2015 06:14:51 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: bug#19482: Changing to big font cause display problem From: "Jan D." In-Reply-To: <54FF3C54.8010601@gmx.at> Date: Thu, 12 Mar 2015 06:14:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0AC0106E-BEDD-4682-888B-7C836F4A680A@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> <45FCBE39-1812-49AA-83C8-37578292F34C@icloud.com> <54FF3C54.8010601@gmx.at> To: martin rudalics X-Mailer: Apple Mail (2.2070.6) X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 19482 Cc: =?utf-8?B?5byg5rW35ZCb?= , 19482@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Hi. > 10 mar 2015 kl. 19:47 skrev martin rudalics : >=20 > > In Emacs 24.4.91, this bug still exist. Will it be fixed in 24.5? >=20 > I don't have any clue what might have made it disappear in Emacs 25. > Maybe Jan can help (I suppose he made the corresponding change). I know which change it is, but it is a bit late for 24.5. After all, it = is no crash. A small resize corrects the frame. >=20 > You could try to bisect Emacs 25 and find the most recent build where = it > did not work. But the subsequent change might be to big in order to = get > safely applied to Emacs 24.5 so I cannot really recommend it. It is not big, but as it involves resizing it may have consequences. Jan D. From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 12 06:13:49 2015 Received: (at 19482) by debbugs.gnu.org; 12 Mar 2015 10:13:49 +0000 Received: from localhost ([127.0.0.1]:43460 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YW07h-0008Qe-9a for submit@debbugs.gnu.org; Thu, 12 Mar 2015 06:13:49 -0400 Received: from mout.gmx.net ([212.227.17.20]:62871) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YW07e-0008QN-PG for 19482@debbugs.gnu.org; Thu, 12 Mar 2015 06:13:47 -0400 Received: from [188.23.123.192] ([188.23.123.192]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Mh9cj-1YrfqB2caH-00MMHc; Thu, 12 Mar 2015 11:13:34 +0100 Message-ID: <550166E5.9010200@gmx.at> Date: Thu, 12 Mar 2015 11:13:57 +0100 From: martin rudalics MIME-Version: 1.0 To: "Jan D." Subject: Re: bug#19482: Changing to big font cause display problem 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> <45FCBE39-1812-49AA-83C8-37578292F34C@icloud.com> <54FF3C54.8010601@gmx.at> <0AC0106E-BEDD-4682-888B-7C836F4A680A@swipnet.se> In-Reply-To: <0AC0106E-BEDD-4682-888B-7C836F4A680A@swipnet.se> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:4iCFPg8Z6gOXAUwmlkaIZr1EJ5awKjF1/exnBT54MghUumjbToq QCVoEzk8KSy6LEOlppMI0PVY72P6WKUHnqTwiBqXns8fsn1rFpGNHcAZ8bzaZqF0oj1WWmU LrEBSx0xPYWAFZuzqC9LOgyuCesMpSlZQ/zgc1m+3okuCimlLuXgbf6WU1LqWWwunGvetjc Xj/w3IZLRmXp1jRiaWhCg== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 19482 Cc: =?UTF-8?B?5byg5rW35ZCb?= , 19482@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) > I know which change it is, but it is a bit late for 24.5. After all, > it is no crash. A small resize corrects the frame. Could you please install a reference to this bug either in the ChangeLog or in the code? Then we could close this bug. Thanks, martin From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 12 12:52:23 2015 Received: (at 19482) by debbugs.gnu.org; 12 Mar 2015 16:52:23 +0000 Received: from localhost ([127.0.0.1]:44164 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YW6LO-00037n-NI for submit@debbugs.gnu.org; Thu, 12 Mar 2015 12:52:23 -0400 Received: from mtaout26.012.net.il ([80.179.55.182]:39229) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YW6LL-00037Y-JQ for 19482@debbugs.gnu.org; Thu, 12 Mar 2015 12:52:20 -0400 Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0NL300M00YOT8100@mtaout26.012.net.il> for 19482@debbugs.gnu.org; Thu, 12 Mar 2015 18:52:53 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NL300EUMYW5WR70@mtaout26.012.net.il>; Thu, 12 Mar 2015 18:52:53 +0200 (IST) Date: Thu, 12 Mar 2015 18:52:08 +0200 From: Eli Zaretskii Subject: Re: bug#19482: Changing to big font cause display problem In-reply-to: <550166E5.9010200@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Message-id: <83ioe640qv.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8BIT 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> <45FCBE39-1812-49AA-83C8-37578292F34C@icloud.com> <54FF3C54.8010601@gmx.at> <0AC0106E-BEDD-4682-888B-7C836F4A680A@swipnet.se> <550166E5.9010200@gmx.at> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 19482 Cc: netjune@icloud.com, jan.h.d@swipnet.se, 19482@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Thu, 12 Mar 2015 11:13:57 +0100 > From: martin rudalics > Cc: 张海君 , > 19482@debbugs.gnu.org > > > I know which change it is, but it is a bit late for 24.5. After all, > > it is no crash. A small resize corrects the frame. > > Could you please install a reference to this bug either in the ChangeLog > or in the code? Then we could close this bug. I think we should wait until 24.5 is released (should be soonish), and then backport the fix to the emacs-24 branch. _Then_ we can close the bug. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 12 14:22:02 2015 Received: (at 19482) by debbugs.gnu.org; 12 Mar 2015 18:22:03 +0000 Received: from localhost ([127.0.0.1]:44218 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YW7kA-0008Qj-As for submit@debbugs.gnu.org; Thu, 12 Mar 2015 14:22:02 -0400 Received: from mailfe07.swip.net ([212.247.154.193]:35123 helo=swip.net) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YW7k6-0008QJ-Uv for 19482@debbugs.gnu.org; Thu, 12 Mar 2015 14:22:00 -0400 X-T2-Spam-Status: No, hits=-0.0 required=5.0 tests=BAYES_40 Received: from hosdjarv.se (account mj138573@tele2.se [46.59.42.57] verified) by mailfe07.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 578551265; Thu, 12 Mar 2015 19:21:51 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: bug#19482: Changing to big font cause display problem From: "Jan D." In-Reply-To: <550166E5.9010200@gmx.at> Date: Thu, 12 Mar 2015 19:21:50 +0100 Content-Transfer-Encoding: 7bit Message-Id: <0DF923DE-2904-4895-9D57-EC0FCBE7C7ED@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> <45FCBE39-1812-49AA-83C8-37578292F34C@icloud.com> <54FF3C54.8010601@gmx.at> <0AC0106E-BEDD-4682-888B-7C836F4A680A@swipnet.se> <550166E5.9010200@gmx.at> To: martin rudalics X-Mailer: Apple Mail (2.2070.6) X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 19482 Cc: =?utf-8?B?5byg5rW35ZCb?= , 19482@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) > 12 mar 2015 kl. 11:13 skrev martin rudalics : > > > I know which change it is, but it is a bit late for 24.5. After all, > > it is no crash. A small resize corrects the frame. > > Could you please install a reference to this bug either in the ChangeLog > or in the code? Then we could close this bug. Done. Jan D. From debbugs-submit-bounces@debbugs.gnu.org Wed May 25 17:14:11 2016 Received: (at control) by debbugs.gnu.org; 25 May 2016 21:14:11 +0000 Received: from localhost ([127.0.0.1]:38689 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1b5g82-0007Yj-R4 for submit@debbugs.gnu.org; Wed, 25 May 2016 17:14:11 -0400 Received: from mail-wm0-f50.google.com ([74.125.82.50]:37765) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1b5g81-0007YX-7t for control@debbugs.gnu.org; Wed, 25 May 2016 17:14:09 -0400 Received: by mail-wm0-f50.google.com with SMTP id z87so76795726wmh.0 for ; Wed, 25 May 2016 14:14:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=sender:date:message-id:to:from:subject; bh=zaYPWdzdbrCvMeDoIA1t3MrX54uQPeL6JExsPfgLJRo=; b=vpcgunIO/OgKFb/8GYGRS/b4nutF0rPNjIakNJhg1yMoof437DgahXQ/0MxK44jQzA PK2qiqzX53EimYr8ib7V0xrlrPw12Y5Wq23nTamQUXoaq0HfZ1AcZmaUMLOqUOHOD1RT kAS/KmZx6C0pE8UBXxGrhNgmaFeZuKfFyx5nJuWuguSK6ufr3hIgcrhLvb5EBWbIkSuM /VuUWybmXAUoLh9pz7BX+JJyc8J0fImhtTKSEWv8EMMSbtgGOIdxggzeZ4GbL+dgBw98 yVlyV++RZ2qM8NOoOud98U1+e76bjWJWWkC8mMTBiKm1SvDJbdAMX7DDxA4aFtUML7+0 GZZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:message-id:to:from:subject; bh=zaYPWdzdbrCvMeDoIA1t3MrX54uQPeL6JExsPfgLJRo=; b=XHT1M57eGwV/tYzLWsXzYXYnhf12ZV1AXiP1AR5g9oA1PhzLDGjwtADJtIQMblYhiH n6Rf1owxon2Mb1CPniYPDA+r/k+nV2RcjDJlvrRmwpCqN7LtVsFVXBCR9T6KqXvVkKwy LUEJBXTyWtSeLrtRUjemLbDVCLbhPbFNOy9Dxms1FuIOVzqgIrkofcF5/HaywePhFt52 e1bfngKnoP3BKRkqrBee0u7QO/YRe0TYLwnijowO/A4mEPZJN3X7G1iejLE3ec8420AC 5cmSTVvQ3VGVOAEfQ64NkOZ/BgJE607lXN/aBuZks6Gmh2rbF+NYJBrbYJWKiNcfMIpS unYw== X-Gm-Message-State: ALyK8tJfq7vI2fdle7xWJ1rsRv2G42BXwPMawovaE33977TlvZWxMb2a+Unnp7wLCg4d1Q== X-Received: by 10.194.114.228 with SMTP id jj4mr5863069wjb.121.1464210843576; Wed, 25 May 2016 14:14:03 -0700 (PDT) Received: from breton.holly.idiocy.org (ip6-2001-08b0-03f8-8129-7175-fea4-ded1-da32.holly.idiocy.org. [2001:8b0:3f8:8129:7175:fea4:ded1:da32]) by smtp.gmail.com with ESMTPSA id 63sm15825wmz.5.2016.05.25.14.14.02 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 May 2016 14:14:02 -0700 (PDT) Date: Wed, 25 May 2016 22:14:02 +0100 Message-Id: To: control@debbugs.gnu.org From: Alan Third Subject: control message for bug #19482 X-Spam-Score: -0.5 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) close 19482 25.1 From unknown Tue Aug 19 09:32:06 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Thu, 23 Jun 2016 11:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator