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#16923: 24.3.50; reression: `set-frame-size' loses mode line Date: Sun, 09 Mar 2014 19:13:25 +0100 Message-ID: <531CAF45.4090307@gmx.at> References: <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> <03e5d7cc-2348-42e4-9e39-1166b120ea2b@default> <531B7564.6030700@gmx.at> <68c9bbe6-4347-4b80-8860-8b76e08f1137@default> <531C72F2.4080608@gmx.at> <2bd68fd8-79a5-49be-80fe-c53d4a689320@default> 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 1394388855 14036 80.91.229.3 (9 Mar 2014 18:14:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 9 Mar 2014 18:14:15 +0000 (UTC) Cc: 16923@debbugs.gnu.org To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Mar 09 19:14:22 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 1WMiEw-0002PM-2M for geb-bug-gnu-emacs@m.gmane.org; Sun, 09 Mar 2014 19:14:22 +0100 Original-Received: from localhost ([::1]:45057 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WMiEv-0007DG-Et for geb-bug-gnu-emacs@m.gmane.org; Sun, 09 Mar 2014 14:14:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39953) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WMiEk-0007Bm-VM for bug-gnu-emacs@gnu.org; Sun, 09 Mar 2014 14:14:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WMiEc-0000HN-Ns for bug-gnu-emacs@gnu.org; Sun, 09 Mar 2014 14:14:10 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:57157) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WMiEc-0000HF-Jc for bug-gnu-emacs@gnu.org; Sun, 09 Mar 2014 14:14:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WMiEb-0001c0-UL for bug-gnu-emacs@gnu.org; Sun, 09 Mar 2014 14:14:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 09 Mar 2014 18:14: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.13943888146130 (code B ref 16923); Sun, 09 Mar 2014 18:14:01 +0000 Original-Received: (at 16923) by debbugs.gnu.org; 9 Mar 2014 18:13:34 +0000 Original-Received: from localhost ([127.0.0.1]:58339 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WMiE8-0001al-Vp for submit@debbugs.gnu.org; Sun, 09 Mar 2014 14:13:33 -0400 Original-Received: from mout.gmx.net ([212.227.17.21]:53198) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WMiE6-0001ab-9C for 16923@debbugs.gnu.org; Sun, 09 Mar 2014 14:13:31 -0400 Original-Received: from [188.23.124.201] ([188.23.124.201]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MNw0t-1WGwXC02TD-007Wq4; Sun, 09 Mar 2014 19:13:29 +0100 In-Reply-To: <2bd68fd8-79a5-49be-80fe-c53d4a689320@default> X-Provags-ID: V03:K0:dLNfn5cR4+DPiCs5aiamrCBqgLGrthm39PIfhK5ofYasmnMu9fO k4lEtUmfPiBi0YosRJ2zv2LgzjT7GOtOF81LuB17AZdceHZImAYn0R9FNSrhCTMUesgFDpb oc5oprvtSAG9YQKjIBa7W2F3B1CyrET5Y675Kix7i6DIgRwIP6QUMCMjzdDLcQZaWYDTfzY Dfxwm3XhgVQdi3jU+6X4Q== 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:86687 Archived-At: > I cannot be sure that something, somewhere else did not issue another call > of `set-frame-size', no. My debugging is limited to `fit-frame' calls. But you can make sure that that something, somewhere is not part of your code? > Yes. But again, where does the dump show a _request_ of 59? What line > 48 shows is the _result_ of resizing to 59. And again, IIRC that was > the right thing to do - the only place where the mode line disappeared > in this debug file is at the end. But I am repeating what I've already > repeated. Your assertion of how you obtained the dump permits such the conclusion that 59 was the requested size. In your bis dump it's 69. >> Line 138 is from the first `window--dump-frame' call following the >> _second_ `set-frame-size' resize request you recorded. I'm talking >> about the _first_ `set-frame-size' request you recorded. > > As I said, IIRC, there was no problem with that first `set-frame-size' > (before line 48). The mode line did not disappear at that resizing. But the dump was inconsistent with what you saw. > I made another test. I removed the form feed from `window-dump-frame' > and I have `fit-frame' call `window-dump-frame' only once before and once > after `set-frame-size'. And I have `fit-frame' print the requested new > width and height, before calling `set-frame-size'. Very good. > I tested it using `C-x C-_', which is bound to `fit-frame'. See attached. Fine. But I need a couple of tests in sequence. Seven as the last time might be good - I want to know whether the w32-rect problem shows up as well. In your first test it did - but not immediately. In the present tests it did not. > It shows that the height, as reported by `window--dump-frame', changed > from 69 to 62 after the dump that reported the result of the first > `set-frame-size'. Why that would be is a mystery to me. > > It shows that the resulting height of the second `set-frame-size', which > caused the mode line to disappear, is correct: 69. (But the starting > height, according to `window--dump-frame', was unexpected - see above.) I think both problems disappear when you set `w32-enable-frame-resize-hack' to nil. Please do that and repeat the simple C-x C-_ test two times (I only need to see one ------------ between two dumps). For the moment, this is the most important test. > The two attachments show the same test, repeated. But here is some > more info that may help: > > If I just repeat calls to `fit-frame' when the frame is already the > right size then the mode line does not disappear. To manifest the > problem, I must first manually resize the frame (e.g. with the mouse) > so that `fit-frame' will actually resize it (change its size). Then, > after that first `fit-frame' resizes it correctly, a second `fit-frame' > leads to the debug output attached: the mode line is lost, and the > dump output from `fit-frame' BEFORE the `set-frame-size' shows an > incorrect height value. This would be fine but I don't see that anywhere in the dumps. That is, I see that you request 101 columns and get 104 but that might be another issue. > IOW, it seems that what is needed is first (a) an actual change in > frame size by `set-frame-size' and then (b) a `set-frame-size' that > does not actually change the size. Both (a) and (b) seem necessary > to lose the mode line. If I start with a frame that already has the > target size (i.e., it has already been fit), then repeating `fit-frame' > has no visible effect, including no loss of the mode line. Can you provide a dump of that sequence supported by a good explanation of what you did? > Note too that even though the dump shows an incorrect height value, > there is nothing visual that corresponds to this: The frame height > after the frame is fit (correctly) does not visibly change when the > second `fit-frame' is called. The only visible effect of the second > `fit-frame' is that the mode line disappears. > > IOW, `fit-frame', and thus `set-frame-size', seem to be doing their > job correctly. As you point out, and as these dumps show once again, > something internal in Emacs seems to think that the height is less > than it actually is (by 6 units, in this case). The new, requested > frame height is applied correctly. Obviously, if Emacs (1) stores inside a bad value you do not see and you (2) ask it to change the frame size to itself, then (3) Emacs might surprise you with a frame with the bad value stored in (1). That's what we have to find out. Thanks, martin