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: Mon, 10 Mar 2014 10:04:36 +0100 Message-ID: <531D8024.6000501@gmx.at> References: <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> <531CAF45.4090307@gmx.at> 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 1394442316 12111 80.91.229.3 (10 Mar 2014 09:05:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 10 Mar 2014 09:05:16 +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 Mon Mar 10 10:05: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 1WMw9C-0003Zz-5l for geb-bug-gnu-emacs@m.gmane.org; Mon, 10 Mar 2014 10:05:22 +0100 Original-Received: from localhost ([::1]:47511 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WMw9B-00086I-Lp for geb-bug-gnu-emacs@m.gmane.org; Mon, 10 Mar 2014 05:05:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56014) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WMw91-00082k-3F for bug-gnu-emacs@gnu.org; Mon, 10 Mar 2014 05:05:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WMw8t-0002C0-OO for bug-gnu-emacs@gnu.org; Mon, 10 Mar 2014 05:05:11 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:57504) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WMw8t-00029j-Kk for bug-gnu-emacs@gnu.org; Mon, 10 Mar 2014 05:05:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WMw8s-0003Wf-SX for bug-gnu-emacs@gnu.org; Mon, 10 Mar 2014 05:05:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 10 Mar 2014 09:05: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.139444229213514 (code B ref 16923); Mon, 10 Mar 2014 09:05:02 +0000 Original-Received: (at 16923) by debbugs.gnu.org; 10 Mar 2014 09:04:52 +0000 Original-Received: from localhost ([127.0.0.1]:58683 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WMw8g-0003Vr-Uq for submit@debbugs.gnu.org; Mon, 10 Mar 2014 05:04:52 -0400 Original-Received: from mout.gmx.net ([212.227.15.15]:53935) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WMw8c-0003Vf-Nn for 16923@debbugs.gnu.org; Mon, 10 Mar 2014 05:04:48 -0400 Original-Received: from [188.23.120.186] ([188.23.120.186]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M6fXs-1X8Bfq3Hm8-00wTaN; Mon, 10 Mar 2014 10:04:43 +0100 In-Reply-To: X-Provags-ID: V03:K0:78LA7TV0FLOGWSR7WqPc6XwZ4DoLp+99Py7KLrrZ1RSs4pnG8nZ ugTVfC8jzrV6ygwjNGSim3M+f7iiUlRLv492JqHjsAp7RL0NRdnzyEFGtmY9RPPGhI/t1e9 C5SW9rwmBs71/QvMSf5Rcvb2K8m+4KokfCzZK8AoFxSz9aMrBSvgKBnd7k2xuuynrq+gopF C5vifYGfB5eEZcjagIdYw== 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:86711 Archived-At: > My code also calls `set-frame-size' on `minibuffer-exit-hook', to reset > the minibuffer frame size. That's it. > > However, my code also calls `modify-frame-parameters' in many contexts > and locations. I tested again, after removing two of those from > functions on `post-command-hook', including resizing the minibuffer frame > - see attached (*-04.txt), which shows the same problem as before. > I believe that I have eliminated all other uses of > `modify-frame-parameters' from the test. > > But if, for example, you have a suggested `defadvice' or something for > `set-frame-size' and `modify-frame-parameters' or whatever, I can try > that too. I don't use advices so I can't suggest anything. The only correct approach is to run Emacs under gdb. >> 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. > > Unclear. Please be clear about just what sequence of just which tests > you need. Something like the sequence of the first seven tests you sent me, aka throw-emacs-bug-16923.txt, however, with your new approach (only one call of `window--dump-frame', show arguments of `set-frame-size'). I say "something like" because I don't think that you can reproduce the exactly same sequence of events as in throw-emacs-bug-16923.txt. >> Please do that and repeat the simple C-x C-_ test two times (I only need >> to see one ------------ between two dumps). > > Attached, as *-05.txt. As mentioned before, that stops the mode line > from disappearing, and it breaks thumbifying. OK. I don't have the slightest idea how this can have worked for you as intended. > ::: Requested WIDTH: 101, HEIGHT: 69 > > frame pixel: 728 x 804 cols/lines: 104 x 67 units: 7 x 12 > frame text pixel: 707 x 804 cols/lines: 101 x 67 > tool: 0 scroll: 21 fringe: 0 border: 0 right: 2 bottom: 2 > w32-rect: (0 0 736 884), (0 0 728 804) > # parent: nil > pixel left: 0 top: 0 size: 728 x 804 new: 0 > char left: 0 top: 0 size: 104 x 67 new: 0 > normal: 1.0 x 1.0 new: 0 > body pixel: 707 x 790 char: 101 x 65 > width left fringe: 0 left margin: 0 right margin: 0 > width right fringe: 0 scroll-bar: 21 divider: 0 > height header-line: 0 mode-line: 14 divider: 0 > > ------------ Here you should see 101 columns and 69 lines, but according to what gets printed below you see 97 columns and 59 lines - ten lines less than requested. How many lines do you really see here, say by comparing the numbers of the lines on top and bottom of the throw-fit-frm.el window? If you really see 69 lines, then please call `window--frame-dump' on that frame interactively here. If it still prints 59 lines, we at least have found a stable configuration where the dump produces a result that does not match what you see. > frame pixel: 679 x 708 cols/lines: 97 x 59 units: 7 x 12 > frame text pixel: 658 x 708 cols/lines: 94 x 59 > tool: 0 scroll: 21 fringe: 0 border: 0 right: 2 bottom: 2 > w32-rect: (0 0 687 788), (0 0 679 708) > # parent: nil > pixel left: 0 top: 0 size: 679 x 708 new: 0 > char left: 0 top: 0 size: 97 x 59 new: 0 > normal: 1.0 x 1.0 new: 0 > body pixel: 658 x 694 char: 94 x 57 > width left fringe: 0 left margin: 0 right margin: 0 > width right fringe: 0 scroll-bar: 21 divider: 0 > height header-line: 0 mode-line: 14 divider: 0 I just see the same problem as with the `w32-enable-frame-resize-hack' t case, that is, the size of the frame recorded does not match the size of the frame you requested. >> 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. > > No, I already stated that that corresponds to the (correct) frame fitting. > By correct I mean that the frame size changed and the mode line was not > lost. By correct I mean that you have to get the size you requested. As long as I cannot resolve the size mystery I cannot continue investigating the mode line bug - it's the former that might cause the later. > And as you have now requested multiple dump files, you had better > cite just which file you are referring to from now on, when you make such > comments. I assume that you meant throw-emacs-bug-16923-ter.txt here. > That file shows a correct resizing with no mode-line loss, followed by > no size change but with mode-line loss. I always refer to what you send me along with the mail. And in the mail you said > The two attachments show the same test, repeated. without further specification so I didn't care. IIUC you mean that the dumps from throw-emacs-bug-16923-bis.txt reflect a change of the frame size while that of throw-emacs-bug-16923-ter.txt reflect a mode line loss without frame size change and was done immediately after the former. Is that so? >> > 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? > > What sequence? I provided a good explanation of what I did. > Please be specific about just what recipe you want followed. The sequence of actions starting with "IOW, it seems that what is needed is first (a) an actual change in frame size ...". > Emacs has so far never surprised me with the wrong frame size. So far, > it has resized the frame as I expectd each time. The only problem is the > loss of the mode line - not the size of the frame. Unfortunately, I can't reproduce that here. martin