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 12:14:40 -0700 (PDT) Message-ID: 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> <531CAF45.4090307@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="__1394392478142332abhmp0014.oracle.com" X-Trace: ger.gmane.org 1394392520 19992 80.91.229.3 (9 Mar 2014 19:15:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 9 Mar 2014 19:15:20 +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 20:15:28 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 1WMjC4-000705-3g for geb-bug-gnu-emacs@m.gmane.org; Sun, 09 Mar 2014 20:15:28 +0100 Original-Received: from localhost ([::1]:45210 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WMjC3-00025D-IW for geb-bug-gnu-emacs@m.gmane.org; Sun, 09 Mar 2014 15:15:27 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51905) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WMjBo-00024s-Fm for bug-gnu-emacs@gnu.org; Sun, 09 Mar 2014 15:15:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WMjBf-0003Oy-FD for bug-gnu-emacs@gnu.org; Sun, 09 Mar 2014 15:15:12 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:57203) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WMjBf-0003Ob-Ak for bug-gnu-emacs@gnu.org; Sun, 09 Mar 2014 15:15:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WMjBe-0003RS-Rx for bug-gnu-emacs@gnu.org; Sun, 09 Mar 2014 15:15:03 -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 19:15: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.139439248513188 (code B ref 16923); Sun, 09 Mar 2014 19:15:02 +0000 Original-Received: (at 16923) by debbugs.gnu.org; 9 Mar 2014 19:14:45 +0000 Original-Received: from localhost ([127.0.0.1]:58385 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WMjBM-0003Qd-6E for submit@debbugs.gnu.org; Sun, 09 Mar 2014 15:14:45 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:29314) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WMjBI-0003QO-Vb for 16923@debbugs.gnu.org; Sun, 09 Mar 2014 15:14:42 -0400 Original-Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s29JEdKL029260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 9 Mar 2014 19:14:40 GMT Original-Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s29JEcRK007709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 9 Mar 2014 19:14:39 GMT Original-Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s29JEc84007703; Sun, 9 Mar 2014 19:14:38 GMT In-Reply-To: <531CAF45.4090307@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: ucsinet21.oracle.com [156.151.31.93] 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:86694 Archived-At: --__1394392478142332abhmp0014.oracle.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > > 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. >=20 > But you can make sure that that something, somewhere is not part of your > code? 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 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 o= nce > > after `set-frame-size'. And I have `fit-frame' print the requested ne= w > > width and height, before calling `set-frame-size'. >=20 > Very good. >=20 > > I tested it using `C-x C-_', which is bound to `fit-frame'. See > > attached. >=20 > 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. > > 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', whi= ch > > caused the mode line to disappear, is correct: 69. (But the starting > > height, according to `window--dump-frame', was unexpected - see above.= ) >=20 > I think both problems What are "both problems"? I have seen only one problem, AFAIK: loss of the mode line. > 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). Attached, as *-05.txt. As mentioned before, that stops the mode line from disappearing, and it breaks thumbifying. > For the moment, this is the most important test. >=20 > > 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. >=20 > 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. 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. > > 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. >=20 > 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. > > 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. >=20 > 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. 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. --__1394392478142332abhmp0014.oracle.com Content-Type: text/plain; charset=Windows-1252; name="throw-emacs-bug-16923-04.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="throw-emacs-bug-16923-04.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 684 cols/lines: 104 x 57 units: 7 x 12 frame text pixel: 707 x 684 cols/lines: 101 x 57 tool: 0 scroll: 21 fringe: 0 border: 0 right: 2 bottom: 2 w32-rect: (0 0 736 764), (0 0 728 684) # parent: nil pixel left: 0 top: 0 size: 728 x 684 new: 0 char left: 0 top: 0 size: 104 x 57 new: 0 normal: 1.0 x 1.0 new: 0 body pixel: 707 x 670 char: 101 x 55 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 --__1394392478142332abhmp0014.oracle.com Content-Type: text/plain; charset=Windows-1252; name="throw-emacs-bug-16923-05.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="throw-emacs-bug-16923-05.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 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 ------------ 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 ::: Requested WIDTH: 101, HEIGHT: 69 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 736 884), (0 0 728 804) # 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 --__1394392478142332abhmp0014.oracle.com--