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#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations Date: Fri, 21 Mar 2014 18:42:30 +0100 Message-ID: <532C7A06.6080703@gmx.at> References: <87bnx1me40.fsf@capuchin.co.uk> <532ABA74.5060206@gmx.at> <21290.56690.254740.791923@capuchin.co.uk> <532AE836.2030907@gmx.at> <21290.64241.176419.931155@capuchin.co.uk> <532B4016.7010508@gmx.at> <21291.20160.94341.637290@capuchin.co.uk> <532BF24A.6090703@gmx.at> <21292.6903.499178.348@capuchin.co.uk> <532C5595.2090800@gmx.at> <21292.28324.463848.983080@capuchin.co.uk> 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 1395423793 10668 80.91.229.3 (21 Mar 2014 17:43:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 21 Mar 2014 17:43:13 +0000 (UTC) Cc: 17046@debbugs.gnu.org To: Robert Marshall Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Mar 21 18:43: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 1WR3TV-0002uo-Nk for geb-bug-gnu-emacs@m.gmane.org; Fri, 21 Mar 2014 18:43:21 +0100 Original-Received: from localhost ([::1]:54011 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WR3TV-0007he-8b for geb-bug-gnu-emacs@m.gmane.org; Fri, 21 Mar 2014 13:43:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40631) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WR3TK-0007h3-8Z for bug-gnu-emacs@gnu.org; Fri, 21 Mar 2014 13:43:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WR3TC-0001VZ-Tu for bug-gnu-emacs@gnu.org; Fri, 21 Mar 2014 13:43:10 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:42656) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WR3TC-0001VQ-QL for bug-gnu-emacs@gnu.org; Fri, 21 Mar 2014 13:43:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WR3TC-0003pW-BG for bug-gnu-emacs@gnu.org; Fri, 21 Mar 2014 13:43: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: Fri, 21 Mar 2014 17:43:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17046 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 17046-submit@debbugs.gnu.org id=B17046.139542375914681 (code B ref 17046); Fri, 21 Mar 2014 17:43:02 +0000 Original-Received: (at 17046) by debbugs.gnu.org; 21 Mar 2014 17:42:39 +0000 Original-Received: from localhost ([127.0.0.1]:43838 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WR3So-0003oh-94 for submit@debbugs.gnu.org; Fri, 21 Mar 2014 13:42:38 -0400 Original-Received: from mout.gmx.net ([212.227.17.22]:61981) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WR3Sk-0003oS-Q7 for 17046@debbugs.gnu.org; Fri, 21 Mar 2014 13:42:36 -0400 Original-Received: from [62.47.252.94] ([62.47.252.94]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MDV5t-1WJZky1Umj-00GsHk; Fri, 21 Mar 2014 18:42:33 +0100 In-Reply-To: <21292.28324.463848.983080@capuchin.co.uk> X-Provags-ID: V03:K0:NPI/maC7WmSHkjVV1HuowrKxJtVZXC18Ar7vmpO4hVA6ybNbnLX 5OfbWEMfw0Hsjt+zkXcUC4kFdRnzwsq0p2VWe0k96nw6wIn8xvXIzTXsfzIEnhyGIHvyDiq uk8In1hMJRcv+nHY9H22Ynohi8SX2CVt9oc1ZYjKZ+PTzbjGAatKcUs9gMn72Llq8xNULUC NI/E3MJzRw/SaFpWZecyA== 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:87113 Archived-At: > Sorry for the confusion I've caused here - those 3 buttons belong to > another application whose window I have shaded (so that the rest of it > is not visible). Ahh... OK. > The emacs scroll bars and fringe disappear when the > window gets the maximise command. But they do so only on this "bad" frame, I suppose. Maximizing a "good" frame doesn't cause them to disappear. > You mean before exiting emacs and that saving the desktop file and > with an un'maximised' bad frame? I get (evaluating it in*scratch*) > (see end of message - maybe I've misunderstood you here and you wanted > the output with just one window in the bad frame - the output from > that option is at the end) You've done everything as I wanted, thanks. This one reveals a strange bug, namely in the last line of > # parent: nil > pixel left: 0 top: 630 size: 992 x 18 new: 0 > char left: 0 top: 35 size: 992 x 1 new: 240 instead of 992 the minibuffer window should have a character width of 124, like the other windows. Unfortunately, this gives no clue at all since we don't even record the minibuffer sizes in window states :-( I suspect it's a problem the dump can't handle because at the time it dumped the value the minibuffer was in an inconsistent state. So all we have is a root window with 34 lines an upper window with 17 and a lower window with 18 lines and these get recorded correctly. > So just one buffer in the frame split into 2 side by side windows > (with the issues with two windows I'd been using split-window-below > and displaying another buffer in the second window)....... > > In attempting to restart to do this test I was unable to replicate the > error for some time, ... which I expected ... > I started emacs 3-4 times without the problem, > eventually I got a bad frame and got the results below: ... which I didn't expect. But again the values look correct and even the minibuffer window has the correct char width now, > # parent: nil > pixel left: 0 top: 630 size: 992 x 18 new: 0 > char left: 0 top: 35 size: 124 x 1 new: 124 namely 124 as in 124 x 1. > Restarted emacs and it came up with a bad frame, in case I misunderstood > (1) here's window--dump-frame with just one window visible in the frame And the frame dump reveals no problems. I'm just as puzzled as before. Juanma must likely help now for the HOWTO: Can you reproduce the problem with an empty .emacs, just loading the desktop file. And can you try with your usual .emacs but deferring loading the desktop file until you have seen your initial frame. martin