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: Thu, 6 Mar 2014 10:25:30 -0800 (PST) Message-ID: <8be91728-fcea-4e74-afff-db6a55b52985@default> References: <53143D5C.7020000@gmx.at> <5314CBE1.6050905@gmx.at> <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> 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 1394130381 25780 80.91.229.3 (6 Mar 2014 18:26:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 6 Mar 2014 18:26:21 +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 Thu Mar 06 19:26: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 1WLczv-0003cV-Pu for geb-bug-gnu-emacs@m.gmane.org; Thu, 06 Mar 2014 19:26:24 +0100 Original-Received: from localhost ([::1]:59159 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WLczv-0003Zm-9L for geb-bug-gnu-emacs@m.gmane.org; Thu, 06 Mar 2014 13:26:23 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39841) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WLczj-0003V8-Kp for bug-gnu-emacs@gnu.org; Thu, 06 Mar 2014 13:26:20 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WLczb-00050M-1D for bug-gnu-emacs@gnu.org; Thu, 06 Mar 2014 13:26:11 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:52451) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WLcza-00050E-P1 for bug-gnu-emacs@gnu.org; Thu, 06 Mar 2014 13:26:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WLcza-0004pm-72 for bug-gnu-emacs@gnu.org; Thu, 06 Mar 2014 13:26: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: Thu, 06 Mar 2014 18:26: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.139413033818542 (code B ref 16923); Thu, 06 Mar 2014 18:26:02 +0000 Original-Received: (at 16923) by debbugs.gnu.org; 6 Mar 2014 18:25:38 +0000 Original-Received: from localhost ([127.0.0.1]:53633 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WLczB-0004oz-5i for submit@debbugs.gnu.org; Thu, 06 Mar 2014 13:25:37 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:27994) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WLcz8-0004oq-JO for 16923@debbugs.gnu.org; Thu, 06 Mar 2014 13:25:35 -0500 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 s26IPW8l018758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 6 Mar 2014 18:25:33 GMT Original-Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s26IPVuJ011094 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Mar 2014 18:25:32 GMT Original-Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s26IPVDd022810; Thu, 6 Mar 2014 18:25:31 GMT In-Reply-To: <5318AFD9.4000208@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:86609 Archived-At: > > I was pretty sure that the mode line also disappears in some cases > > when moving to a different node. But I definitely do not see that > > now, so I guess I was mistaken about that. >=20 > (1) The mode line disappears only when the frame size remains the same. > Check this please via the arguments you pass (to `set-frame-size' or > whatever you use). >=20 > (2) Everything else is drawn correctly, there's no area with background > space only, as you claimed earlier. >=20 > Is that correct (from your experience, so far)? You might want to > attach a screenshot. Yes, that is what I was saying. However, testing by printing the sizes as messages shows that I was wrong (once again). The mode line can disappear, it seems, either when the size is the same or when it increases. Here are some debug messages, where =3D=3D=3D=3D=3D=3D means the size was n= ot changed and /////// means that it was changed. The old and new sizes are also noted. These resizings were not associated with losing the mode line: CUR: (81 63) NEW: (76 63) ////////////////////// CUR: (76 61) NEW: (81 63) ////////////////////// These, immediately after those, were: CUR: (81 61) NEW: (81 63) ////////////////////// CUR: (81 63) NEW: (81 63) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D That is, the mode line was lost when the height changed from 61 to 63, and it remained lost when the size was not changed, on the next call to `set-frame-size'. In the following sequence of resizings, starting with a visible mode line, only this change caused the mode line to disappear. And it reappeared at the next resizing. CUR: (72 20) NEW: (72 22) ---------------- CUR: (81 63) NEW: (72 63) ////////////////////// CUR: (72 61) NEW: (72 53) ////////////////////// CUR: (72 51) NEW: (72 62) ////////////////////// CUR: (72 60) NEW: (72 63) ////////////////////// CUR: (72 61) NEW: (72 22) ////////////////////// CUR: (72 20) NEW: (72 22) ////////////////////// CUR: (72 22) NEW: (72 47) ////////////////////// --------------- That was using Info. Note that though the `height' parameter value was slightly increased when the mode line was lost, I saw no apparent change in the frame size. Dunno what that means. > > Actually, now I can repro it more simply, without using Info. In my > > setup, if I do M-: (fit-frame) more than once in the same frame, the > > mode line sometimes disappears. For most buffers/frames, it disappear= s. > > But not always. It does not disappear for `list-faces-display', for > > some reason. (It does disappear for `list-colors-display'.) With this test of repeating M-: (fit-frame), this is what I see. The (240 2) messages are from inputting (fit-frame) into the minibuffer frame, for M-:. The minibuffer frame is 240 chars wide and 2 chars high. Evaluating... CUR: (95 62) NEW: (95 73) ////////////////////// Buffer `*Pp Eval Output*' is in mode `Emacs-Lisp'. For info on the mode: = `C-h m'. nil CUR: (240 2) NEW: (240 2) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Evaluating... CUR: (95 71) NEW: (95 73) ////////////////////// Buffer `*Pp Eval Output*' is in mode `Emacs-Lisp'. For info on the mode: = `C-h m'. nil Again, there was no apparent change in the frame height, in spite of the change in `height' parameter value. The first frame-fit, from height 62 to 73, did represent a size change. The second, from 71 to 73, did not show any size change. The only change I noticed was the mode line disappearing. > Add the following function to your .emacs ... >=20 > (defun window--resize-root-window=20 > (window delta horizontal ignore pixelwise) > ...) >=20 > ... and post the contents of the buffer *window-frame-dump* after a > fatal resize operation here (but make sure to not resize any frame again > _before_ getting hold of that buffer's contents!!!). I tried that, but buffer *window-frame-dump* never was filled with any text. And I never saw any "fatal resize". IOW, evaluating that defun did not have any effect that I noticed. I did still continue to observe the behavior I have recorded above, however. IOW, the mode line continued to disappear in the same way, with no changes that I could see. Do I need to do something more than just evaluate that defun? Do I need to restart Emacs and do that first or something? (You mentioned putting it in .emacs, instead of just evaluating it. I just evaluated it.)