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 07:34:54 -0800 (PST) Message-ID: <1cb471a0-5db3-4c77-90ff-ed8aa2c9bd0b@default> References: <04dda5ae-8b70-42f5-ae09-c1d05ebc9297@default> <5314DB5D.50709@gmx.at> <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> 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 1394292976 31563 80.91.229.3 (8 Mar 2014 15:36:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 8 Mar 2014 15:36: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 16:36:23 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 1WMJIV-000604-3h for geb-bug-gnu-emacs@m.gmane.org; Sat, 08 Mar 2014 16:36:23 +0100 Original-Received: from localhost ([::1]:40988 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WMJIU-0005IS-Mk for geb-bug-gnu-emacs@m.gmane.org; Sat, 08 Mar 2014 10:36:22 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57944) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WMJIJ-0005IE-Cm for bug-gnu-emacs@gnu.org; Sat, 08 Mar 2014 10:36:19 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WMJIA-0002Qf-Qp for bug-gnu-emacs@gnu.org; Sat, 08 Mar 2014 10:36:11 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:55520) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WMJIA-0002Qb-N8 for bug-gnu-emacs@gnu.org; Sat, 08 Mar 2014 10:36:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WMJIA-0004r3-7E for bug-gnu-emacs@gnu.org; Sat, 08 Mar 2014 10:36:02 -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 15:36:02 +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.139429290218575 (code B ref 16923); Sat, 08 Mar 2014 15:36:02 +0000 Original-Received: (at 16923) by debbugs.gnu.org; 8 Mar 2014 15:35:02 +0000 Original-Received: from localhost ([127.0.0.1]:56702 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WMJHB-0004pC-3W for submit@debbugs.gnu.org; Sat, 08 Mar 2014 10:35:02 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:35492) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WMJH9-0004p3-DK for 16923@debbugs.gnu.org; Sat, 08 Mar 2014 10:35:00 -0500 Original-Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s28FYuNd002232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 8 Mar 2014 15:34:57 GMT Original-Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s28FYtOS006178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 8 Mar 2014 15:34:56 GMT Original-Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s28FYtYe009410; Sat, 8 Mar 2014 15:34:55 GMT In-Reply-To: <531ADEBC.9030200@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: ucsinet22.oracle.com [156.151.31.94] 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:86656 Archived-At: > From the backtrace you attached earlier it's clearly visible that in 21 > calls the value is 56. And as I remarked earlier, this value is Windows > internal. So unless we have some proof that Emacs is asking Windows to > do something like enlarging the title bar or wrapping the menu bar, we > must assume that Emacs sent so many resize requests in a row that it was > able to confuse Windows. >=20 > I have no idea how often you ask for changing the frame size in one and > the same redisplay cycle. On Windows, without ConfigureNotify events, I > wouldn't issue more than one request per frame in one redisplay cycle. > Everything else means asking for trouble. In the debug output I sent, file throw-emacs-bug-16923.txt, you see, as I mentioned, seven calls to `fit-frame' (each "------------" in the file). I was doing `s RET' in Info, non-incrementally searching for the next occurrence of a string ("terminals"). Each press of `s' entailed a single call to `fit-frame'. In some cases a second occurrence was found in the same node, so any `s' and its `fit-frame' other than the first in such a node is essentially a no-op (except for the bug side effect of removing the mode line). Does that respond to your question about how often frame resizing is requested per "redisplay cycle"? I do not know the period, whether in terms of a number of input events or elapsed time, of a "redisplay cycle", but I can say that my pressing of `s' determined the calls to `fit-frame': one per press. And in the other test I did earlier, just using `M-: (fit-frame)' twice in the same frame, the number of calls to `fit-frame' was two. 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 or the rapidity or frequency of resize requests? What constitutes a "row", i.e., until interrupted by what? 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.