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: Fri, 13 Dec 2013 11:12:39 +0100 Message-ID: <52AADD97.5060801@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> <52A98D4A.5000000@gmx.at> <8361qu6n3o.fsf@gnu.org> <52A9FC22.2030301@gmx.at> <831u1h7voj.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1386929597 25372 80.91.229.3 (13 Dec 2013 10:13:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 13 Dec 2013 10:13:17 +0000 (UTC) Cc: 16028@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Dec 13 11:13:21 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 1VrPkH-00034v-Ik for geb-bug-gnu-emacs@m.gmane.org; Fri, 13 Dec 2013 11:13:21 +0100 Original-Received: from localhost ([::1]:41206 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VrPkG-0000aZ-WB for geb-bug-gnu-emacs@m.gmane.org; Fri, 13 Dec 2013 05:13:21 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34225) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VrPk5-0000ML-Th for bug-gnu-emacs@gnu.org; Fri, 13 Dec 2013 05:13:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VrPjy-0002Pq-K5 for bug-gnu-emacs@gnu.org; Fri, 13 Dec 2013 05:13:09 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:60791) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VrPjy-0002Pk-G4 for bug-gnu-emacs@gnu.org; Fri, 13 Dec 2013 05:13:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VrPjx-000345-T7 for bug-gnu-emacs@gnu.org; Fri, 13 Dec 2013 05:13:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Dec 2013 10:13:01 +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.138692957111761 (code B ref 16028); Fri, 13 Dec 2013 10:13:01 +0000 Original-Received: (at 16028) by debbugs.gnu.org; 13 Dec 2013 10:12:51 +0000 Original-Received: from localhost ([127.0.0.1]:46577 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VrPji-00033X-96 for submit@debbugs.gnu.org; Fri, 13 Dec 2013 05:12:50 -0500 Original-Received: from mout.gmx.net ([212.227.17.20]:55241) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VrPjf-00033M-6V for 16028@debbugs.gnu.org; Fri, 13 Dec 2013 05:12:44 -0500 Original-Received: from [62.47.62.238] ([62.47.62.238]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MLj5z-1Vr8kk3RmF-000rkO for <16028@debbugs.gnu.org>; Fri, 13 Dec 2013 11:12:42 +0100 In-Reply-To: <831u1h7voj.fsf@gnu.org> X-Provags-ID: V03:K0:GyTytGBnzKHIq1KXnT1xS1gg//588bfd2YKRxji6HPFeUWPm06L 7tPar3rqUEL+p85lKH0uWXqdXcifo0w5hlYIg4IXYXtljQSCzIN22uU8ctsuBFzWx3gn0sU aDHq1C57Nslya5G8tG0D7NPbqscnA7UBp+uEthMQeic88s+w3HyxpD4Wb5+TiHUNq4mfz2r q9/GwjcBErn7jh8Km/+0g== 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:81860 Archived-At: > But if we somehow could provide Drew with the frame dimensions that > _should_ have resulted from the two changes his code does, then he > could add a call to set-frame-size to request precisely those > dimensions, and that should fix his problem, no? I'm not sure. In principle Drew should be able to thumbify as follows: (1) Save the current pixel sizess, font and scrollbar width. (2) Set the new font size. (3) Set the new scrollbar width. (4) Set the new pixel sizes to some calculated from the ones saved in (1) and the scale factor used in (2). To dethumbify he would have to (5) Set the new font size to the one saved in (1). (6) Set the new scrollbar width to the one saved in (1). (7) Set the new frame pixel sizes to the ones saved in (1). I don't know whether this correctly restores window start positions but at least it seems the only sane way to fix his problem with the current trunk. We could obviously store the new pixel values and either let any size changing functions use the new values or provide a Lisp interface to them and let Drew use that value in his calculations. Doing so would, however, not eliminate the fact that the state of Emacs is inconsistent while a resize operation is pending because the value returned by `frame-pixel-height' is not in line with that of `frame-height'. The programmer would still have to be aware of this inconsistency and explaining such a thing in the manual or a doc-string would be quite a nuisance. BTW, when creating a new frame, the inconsistency should be observable on GNU/Linux as well. I see only two ways to solve this inconsistency: (1) Find some way to synch with the window manager as we do on GNU/Linux. (2) Apply the size changes with the commented-out code. The comment motivating why we should not do this on Windows because of the menubar wrapping issue doesn't make sense to me anyway: If we and Windows can handle wrapping, we'll do that when Windows gets back to us. And the worst thing that could happen to us is that parts of the frame (including the modeline) might get obscured. But this is something I plan to do anyway when shrinking a frame below the minimum size to accomodate all of its windows. WDYT? martin