From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code Date: Thu, 12 Dec 2013 11:17:46 +0100 Message-ID: <52A98D4A.5000000@gmx.at> References: <746cd4cb-c69d-4cff-8dee-f7ccde3cb2f4@default> <52A1E5A6.3010901@gmx.at> <52A1F967.5070403@gmx.at> <6ee939f5-138d-4e5c-830e-8a20f8e45bea@default> <52A207C5.4070404@gmx.at> <12e899a3-dbf2-4b44-9b87-a0b9fc24f317@default> <52A2EE7B.4030105@gmx.at> <723644fb-f171-4bed-b8d0-7f9a1c8b9f7d@default> <52A4428F.4030101@gmx.at> <600e7b0c-73bb-4163-8d03-a8579f250045@default> <52A4B23E.9080609@gmx.at> <837gbeymiy.fsf@gnu.org> <52A60DD2.1020303@gmx.at> <83r49lxsxf.fsf@gnu.org> <52A6ED85.8020206@gmx.at> <52A6F1C4.3040803@gmx.at> <941b1292-a5c6-442d-afe8-d83aebf4b41c@default> <52A734F2.8020203@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1386843499 24267 80.91.229.3 (12 Dec 2013 10:18:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 12 Dec 2013 10:18:19 +0000 (UTC) Cc: 16028@debbugs.gnu.org To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Dec 12 11:18:24 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Vr3La-0003lN-HV for geb-bug-gnu-emacs@m.gmane.org; Thu, 12 Dec 2013 11:18:22 +0100 Original-Received: from localhost ([::1]:34801 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vr3LZ-0007di-Ib for geb-bug-gnu-emacs@m.gmane.org; Thu, 12 Dec 2013 05:18:21 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41596) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vr3LO-0007dY-TX for bug-gnu-emacs@gnu.org; Thu, 12 Dec 2013 05:18:18 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vr3LH-0003rM-7S for bug-gnu-emacs@gnu.org; Thu, 12 Dec 2013 05:18:10 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:58957) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vr3LH-0003rI-3Z for bug-gnu-emacs@gnu.org; Thu, 12 Dec 2013 05:18:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Vr3LG-0006AC-HY for bug-gnu-emacs@gnu.org; Thu, 12 Dec 2013 05:18:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 12 Dec 2013 10:18:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 16028 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 16028-submit@debbugs.gnu.org id=B16028.138684348223686 (code B ref 16028); Thu, 12 Dec 2013 10:18:02 +0000 Original-Received: (at 16028) by debbugs.gnu.org; 12 Dec 2013 10:18:02 +0000 Original-Received: from localhost ([127.0.0.1]:44743 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vr3LF-00069x-39 for submit@debbugs.gnu.org; Thu, 12 Dec 2013 05:18:01 -0500 Original-Received: from mout.gmx.net ([212.227.17.21]:56663) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vr3LD-00069n-8C for 16028@debbugs.gnu.org; Thu, 12 Dec 2013 05:17:59 -0500 Original-Received: from [62.47.39.63] ([62.47.39.63]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MRCCJ-1Vz7Pd2nRn-00UbfW for <16028@debbugs.gnu.org>; Thu, 12 Dec 2013 11:17:58 +0100 In-Reply-To: X-Provags-ID: V03:K0:knEElb5WtXHzZFtF5F8tlHgIw0tMwwVbhIX4cts8/0YRGHbgeNH 5mahYUjqqWcNYUreSuhVV7+SUcfqWjPaar4Z29lxxCMEeroDg+wHzsEbJqpyjrX5Rlxl07J nipauJPopM/E3Cqlu6kfghXLhYqx/spkKzW9musyZpQGE1yDws0YepLtUguOZzfEyqBOM2Y dfD2NWTuCM8EaNSBVZYAQ== X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:81806 Archived-At: > Unfortunately, that did not work at all. It made a big mess, in > all Emacs versions. For one thing, each shrinking/enlargement > magnified the scale of zoom out/in over the previous one. > > I.e., each shrinking/enlargement was greater than the > enlargement/shrinking that immediately preceded it (not just > greater than the last shrinking/enlargement). Which also demonstrates how fragile your code is. You maybe rely on some undocumented behavior, namely that setting the font size can set the scrollbar width too, despite of the fact that you explicitly set the scrollbar width to some specific value before. And your code might easily fail with toolkits that want to handle the scrollbar width themselves. The trap your code fell into can be roughly described as follows: (1) You ask for changing the pixel size of a frame by setting the font size. Emacs passes the request on to the window manager but on Windows it does _not_ store the new pixel size of the frame. (2) You ask for changing the pixel size of a frame by setting the scrollbar width. Now before my changes, (2) asked the window manager to change the pixel size of the frame based on its line/column sizes multiplied by the default font sizes. After my changes, (2) asks to change the pixel size of the frame directly from the previously calculated pixel sizes. However, since on Windows (1) does not record the change of the pixel size caused by setting the font size, the request in (2) will be based on the pixel size of the frame before (1) was issued. I don't know how to fix this properly. IIUC Emacs cannot wait until Windows passes the new sizes back to it in (1) just as it does on other systems. The sit-for I proposed earlier could work around this. If OTOH I restore the calculation for (2) to use the line/column values, people who want to change the scrollbar width exactly by pixels are lost. martin