From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code Date: Fri, 13 Dec 2013 12:51:05 +0200 Message-ID: <83mwk558iu.fsf@gnu.org> 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> <52AADD97.5060801@gmx.at> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1386931935 19748 80.91.229.3 (13 Dec 2013 10:52:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 13 Dec 2013 10:52:15 +0000 (UTC) Cc: 16028@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Dec 13 11:52:18 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 1VrQLv-0006Ao-LB for geb-bug-gnu-emacs@m.gmane.org; Fri, 13 Dec 2013 11:52:15 +0100 Original-Received: from localhost ([::1]:41428 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VrQLv-0002Jj-97 for geb-bug-gnu-emacs@m.gmane.org; Fri, 13 Dec 2013 05:52:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41577) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VrQLn-0002JO-Eo for bug-gnu-emacs@gnu.org; Fri, 13 Dec 2013 05:52:11 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VrQLi-00052A-SQ for bug-gnu-emacs@gnu.org; Fri, 13 Dec 2013 05:52:07 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:60823) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VrQLi-000520-P9 for bug-gnu-emacs@gnu.org; Fri, 13 Dec 2013 05:52:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VrQLi-000454-CE for bug-gnu-emacs@gnu.org; Fri, 13 Dec 2013 05:52:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Dec 2013 10:52: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.138693186815621 (code B ref 16028); Fri, 13 Dec 2013 10:52:02 +0000 Original-Received: (at 16028) by debbugs.gnu.org; 13 Dec 2013 10:51:08 +0000 Original-Received: from localhost ([127.0.0.1]:46609 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VrQKp-00043s-Pr for submit@debbugs.gnu.org; Fri, 13 Dec 2013 05:51:08 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:61957) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VrQKn-00043j-0s for 16028@debbugs.gnu.org; Fri, 13 Dec 2013 05:51:06 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MXQ00700RDYVH00@a-mtaout20.012.net.il> for 16028@debbugs.gnu.org; Fri, 13 Dec 2013 12:51:03 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MXQ007X6RH2KKB0@a-mtaout20.012.net.il>; Fri, 13 Dec 2013 12:51:03 +0200 (IST) In-reply-to: <52AADD97.5060801@gmx.at> X-012-Sender: halo1@inter.net.il 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:81865 Archived-At: > Date: Fri, 13 Dec 2013 11:12:39 +0100 > From: martin rudalics > CC: drew.adams@oracle.com, 16028@debbugs.gnu.org > > > 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. I'd say we should try that. > 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. I don't see experts on board who would know how to do that. > (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. We could uncomment that code and see what trouble, if any, it causes.