From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#16923: 24.3.50; reression: `set-frame-size' loses mode line Date: Sat, 8 Mar 2014 11:12:05 -0800 (PST) Message-ID: <03e5d7cc-2348-42e4-9e39-1166b120ea2b@default> References: <29b76228-778a-4aea-8fe4-5abedb5b6795@default> <531589F3.1050300@gmx.at> <70615a8e-3923-40c3-bfbc-af0a305cd6df@default> <5316D1B5.8040801@gmx.at> <53176AF2.9010800@gmx.at> <53177AEF.9050106@gmx.at> <3f31643f-2638-4ada-8dc4-b3069f3a82fc@default> <531780D7.6070109@gmx.at> <291bd9d5-923f-440a-821a-06f585557e67@default> <5318AFD9.4000208@gmx.at> <8be91728-fcea-4e74-afff-db6a55b52985@default> <5318C478.1090007@gmx.at> <0f1c6cae-f9cd-4a2b-a662-bcc4116daafc@default> <5318E810.7000705@gmx.at> <531977B2.8030109@gmx.at> <531A0655.5040400@gmx.at> <5e0232ee-58e3-42a3-8102-e12e8e605b2b@default> <531A11BE.5070300@gmx.at> <738285f8-0119-49cd-b5b5-7e9607fadff3@default> <531ADEBC.9030200@gmx.at> <1cb471a0-5db3-4c77-90ff-ed8aa2c9bd0b@default> <531B6875.6030406@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1394305996 4836 80.91.229.3 (8 Mar 2014 19:13:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 8 Mar 2014 19:13:16 +0000 (UTC) Cc: 16923@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Mar 08 20:13:24 2014 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 1WMMgU-0001tX-4w for geb-bug-gnu-emacs@m.gmane.org; Sat, 08 Mar 2014 20:13:22 +0100 Original-Received: from localhost ([::1]:41562 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WMMgT-0005Ov-LO for geb-bug-gnu-emacs@m.gmane.org; Sat, 08 Mar 2014 14:13:21 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58882) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WMMgI-0005NA-On for bug-gnu-emacs@gnu.org; Sat, 08 Mar 2014 14:13:19 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WMMg9-0000eX-VM for bug-gnu-emacs@gnu.org; Sat, 08 Mar 2014 14:13:10 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:55752) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WMMg9-0000eS-S9 for bug-gnu-emacs@gnu.org; Sat, 08 Mar 2014 14:13:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WMMg9-0007I1-KO for bug-gnu-emacs@gnu.org; Sat, 08 Mar 2014 14:13:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 08 Mar 2014 19:13:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 16923 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 16923-submit@debbugs.gnu.org id=B16923.139430593227954 (code B ref 16923); Sat, 08 Mar 2014 19:13:01 +0000 Original-Received: (at 16923) by debbugs.gnu.org; 8 Mar 2014 19:12:12 +0000 Original-Received: from localhost ([127.0.0.1]:56934 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WMMfM-0007Gn-3o for submit@debbugs.gnu.org; Sat, 08 Mar 2014 14:12:12 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:26489) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WMMfJ-0007Gc-4N for 16923@debbugs.gnu.org; Sat, 08 Mar 2014 14:12:09 -0500 Original-Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s28JC7o8001381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 8 Mar 2014 19:12:08 GMT Original-Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s28JC5U0014364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 8 Mar 2014 19:12:06 GMT Original-Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s28JC5fp028819; Sat, 8 Mar 2014 19:12:05 GMT In-Reply-To: <531B6875.6030406@gmx.at> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6680.5000 (x86)] X-Source-IP: acsinet22.oracle.com [141.146.126.238] 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:86670 Archived-At: > I see 42 calls of `window--dump-frame' which from what you say above > means that for every `fit-frame' there are 6 calls of > `window--dump-frame'. Does that mean there are 6 `set-frame-size' > requests per each `fit-frame' call? No, it does not. You asked me to invoke `window--dump-frame' multiple times before and after each invocation of `fit-frame'. I figured 3 times would be enough to satisfy that (so 6 times per `fit-frame'). Did I misunderstand the request? > Note: I'm not interested in `fit-frame' or how you calculate frame > sizes. I'm only interested in your calls of `set-frame-size' or > whatever you use to resize your frame. How many such calls are there in > throw-emacs-bug-16923? And how can I attribute any of these calls to a > frame without a mode line? There is one `set-frame-size' per `fit-frame' call. So seven calls to `set-frame-size'. I don't recall exactly, and I see that I did not mention it in my report with `throw-emacs-bug-16923' (though I mentioned all of the rest of this), just how many of the seven `fit-frame' invocations resulted in loss of the mode line. I believe that only the last invocation lost the mode line, but I am not sure to remember correctly. IIRC, I believed that I stopped as soon as I got one mode line disappearance, but I couldn't swear that that is the case. I should have noted that in my report. > > You say that you "assume that Emacs sent so many resize requests in > > a row that it was able to confuse Windows". What do you mean to draw > > attention to here: the number of requests in a row >=20 > The number. >=20 > > or the rapidity or > > frequency of resize requests? What constitutes a "row", i.e., until > > interrupted by what? >=20 > By redisplay. Doesn't redisplay occur if the Info node changes? At any rate, as I said, I just hit `s RET' repeatedly to search for the same string. Sometimes that string was found more than once in the same node, sometimes not. > > Based on what I say above, I do not see how it could be that either > > a high cadence or a high number of successive `fit-frame' calls could > > be overwhelming redisplay. But I am entirely ignorant about redisplay= , > > and I am not very clear about what you are asking here. >=20 > The problem is not in redisplay. The problem is the number of resize > requests sent in succession to the window manager before redisplay > occurs. On Windows this is the number of calls of AdjustWindowRect > which corresponds to the number of calls of `set-frame-size'. Redisplay > should occur only after Emacs has negotiated with Windows for each of > these calls. >=20 > Anyway. Beginning with the fourth "------------" on line 271 of > throw-emacs-bug-16923 the height difference of window and client > rectangle is 56 and not 80 as before. Unless we can resolve that > mystery it hardly make sense to experiment any further. OK. Let me know if you want me to try something else.