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: Sun, 9 Mar 2014 09:35:40 -0700 (PDT) Message-ID: <2bd68fd8-79a5-49be-80fe-c53d4a689320@default> References: <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> <03e5d7cc-2348-42e4-9e39-1166b120ea2b@default> <531B7564.6030700@gmx.at> <68c9bbe6-4347-4b80-8860-8b76e08f1137@default> <531C72F2.4080608@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="__1394382937949257797abhmp0018.oracle.com" X-Trace: ger.gmane.org 1394382978 17767 80.91.229.3 (9 Mar 2014 16:36:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 9 Mar 2014 16:36:18 +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 Sun Mar 09 17:36:25 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 1WMgi8-0003bb-9V for geb-bug-gnu-emacs@m.gmane.org; Sun, 09 Mar 2014 17:36:24 +0100 Original-Received: from localhost ([::1]:44744 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WMgi7-0006Gg-UC for geb-bug-gnu-emacs@m.gmane.org; Sun, 09 Mar 2014 12:36:23 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51169) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WMghv-0006EV-Uz for bug-gnu-emacs@gnu.org; Sun, 09 Mar 2014 12:36:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WMghn-0003CI-5F for bug-gnu-emacs@gnu.org; Sun, 09 Mar 2014 12:36:11 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:57124) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WMghn-0003CE-1V for bug-gnu-emacs@gnu.org; Sun, 09 Mar 2014 12:36:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WMghm-00079j-Dh for bug-gnu-emacs@gnu.org; Sun, 09 Mar 2014 12:36:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 09 Mar 2014 16: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.139438294727474 (code B ref 16923); Sun, 09 Mar 2014 16:36:02 +0000 Original-Received: (at 16923) by debbugs.gnu.org; 9 Mar 2014 16:35:47 +0000 Original-Received: from localhost ([127.0.0.1]:58306 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WMghW-000791-0O for submit@debbugs.gnu.org; Sun, 09 Mar 2014 12:35:46 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:46439) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WMghS-00078n-6W for 16923@debbugs.gnu.org; Sun, 09 Mar 2014 12:35:44 -0400 Original-Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s29GZdei001760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 9 Mar 2014 16:35:40 GMT Original-Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s29GZci5022346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 9 Mar 2014 16:35:39 GMT Original-Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s29GZc3Q010067; Sun, 9 Mar 2014 16:35:38 GMT In-Reply-To: <531C72F2.4080608@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: acsinet21.oracle.com [141.146.126.237] 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:86683 Archived-At: --__1394382937949257797abhmp0018.oracle.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > >> This means that the frame size changes across the "------------" on l= ine > >> 91. And it changes again across the next two "------------"'s. Can = you > >> explain that? >=20 > It's important to get a trace of _every_ call of `set-frame-size' for > that frame - no matter where it comes from. Are you sure you did that? 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. > And I take it granted that for each `set-frame-size' you inserted a > "------------" in the buffer, then three identical `window--dump-frame' > outputs before the call to `set-frame-size' each preceded by a form feed > and then three identical `window--dump-frame' outputs after the call to > `set-frame-size' each preceded by a form feed too. =20 Correct, wrt the call to `set-frame-size' within `fit-frame'. See above. > Then you did the same for the next `set-frame-size' call. Can you > confirm that? If not, please elaborate. Yes, AFAIK, IIRC. And as I've already confirmed several times now. > >> If it's caused by the window manager, then you should > >> notice that the heights don't fit already there (you got 51 lines > >> instead of the 59 you requested). > > > > What shows a request of 59 and a result of 51? I see `51' on line 93, > > which I guess you are saying is the resulting frame size (?). But > > resulting from what size request? Where do you see the `59' as an > > indication of what size was requested? >=20 > On line 48: > frame pixel: 627 x 856 cols/lines: 75 x 59 units: 8 x 14 >=20 > From the interpretation I gave above this line results from the first > `window--dump-frame' call following the very first `set-frame-size' call > you recorded. Can you see that? Is my interpretation correct? 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. > > What I think I see instead is this: > > 3 calls to w32* before the resize request, showing a height of 51, > > followed by 3 more calls to w32* after the resize request, showing > > a height of 59 (starting on line 138). >=20 > 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 it's possible that I am not remembering correctly. (So I repeated the test - below.) > And please make only one call of `window--dump-frame' before and one > call after each `set-frame-size' call. And please don't insert any form > feeds - they might easily corrupt any communication about which line of > dumped text we are on. >=20 > ... But what apparently happened is that after > the last (of six) `window--dump-frame' calles belonging to the first > `set-frame-size' request and before the first `window--dump-frame' call > belonging to the second `set-frame-size' request the size of the frame > changed as in lines 78 to 104 of throw-emacs-bug-16923.txt: > ... > And this change is unexplained yet. What height did you see and > what height did you expect to see at the time you hit `s' before the > "------------" was drawn in this excerpt - 59 or 51 lines? Dunno. --- 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'. I tested it using `C-x C-_', which is bound to `fit-frame'. See attached. 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.) 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. 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. 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. HTH. --__1394382937949257797abhmp0018.oracle.com Content-Type: text/plain; charset=Windows-1252; name="throw-emacs-bug-16923-bis.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="throw-emacs-bug-16923-bis.txt" ------------ 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 ::: Requested WIDTH: 101, HEIGHT: 69 frame pixel: 728 x 828 cols/lines: 104 x 69 units: 7 x 12 frame text pixel: 707 x 828 cols/lines: 101 x 69 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 828 new: 0 char left: 0 top: 0 size: 104 x 69 new: 0 normal: 1.0 x 1.0 new: 0 body pixel: 707 x 814 char: 101 x 67 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 ------------ frame pixel: 728 x 744 cols/lines: 104 x 62 units: 7 x 12 frame text pixel: 707 x 744 cols/lines: 101 x 62 tool: 0 scroll: 21 fringe: 0 border: 0 right: 2 bottom: 2 w32-rect: (0 0 736 824), (0 0 728 744) # parent: nil pixel left: 0 top: 0 size: 728 x 744 new: 0 char left: 0 top: 0 size: 104 x 62 new: 0 normal: 1.0 x 1.0 new: 0 body pixel: 707 x 730 char: 101 x 60 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 ::: Requested WIDTH: 101, HEIGHT: 69 frame pixel: 728 x 828 cols/lines: 104 x 69 units: 7 x 12 frame text pixel: 707 x 828 cols/lines: 101 x 69 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 828 new: 0 char left: 0 top: 0 size: 104 x 69 new: 0 normal: 1.0 x 1.0 new: 0 body pixel: 707 x 814 char: 101 x 67 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 --__1394382937949257797abhmp0018.oracle.com Content-Type: text/plain; charset=Windows-1252; name="throw-emacs-bug-16923-ter.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="throw-emacs-bug-16923-ter.txt" ------------ 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 ::: Requested WIDTH: 101, HEIGHT: 69 frame pixel: 728 x 828 cols/lines: 104 x 69 units: 7 x 12 frame text pixel: 707 x 828 cols/lines: 101 x 69 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 828 new: 0 char left: 0 top: 0 size: 104 x 69 new: 0 normal: 1.0 x 1.0 new: 0 body pixel: 707 x 814 char: 101 x 67 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 ------------ frame pixel: 686 x 756 cols/lines: 98 x 63 units: 7 x 12 frame text pixel: 665 x 756 cols/lines: 95 x 63 tool: 0 scroll: 21 fringe: 0 border: 0 right: 2 bottom: 2 w32-rect: (0 0 694 836), (0 0 686 756) # parent: nil pixel left: 0 top: 0 size: 686 x 756 new: 0 char left: 0 top: 0 size: 98 x 63 new: 0 normal: 1.0 x 1.0 new: 0 body pixel: 665 x 742 char: 95 x 61 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 ::: Requested WIDTH: 101, HEIGHT: 69 frame pixel: 728 x 828 cols/lines: 104 x 69 units: 7 x 12 frame text pixel: 707 x 828 cols/lines: 101 x 69 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 828 new: 0 char left: 0 top: 0 size: 104 x 69 new: 0 normal: 1.0 x 1.0 new: 0 body pixel: 707 x 814 char: 101 x 67 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 --__1394382937949257797abhmp0018.oracle.com--