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 16:07:01 +0100 Message-ID: <532C5595.2090800@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> 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 1395414499 16086 80.91.229.3 (21 Mar 2014 15:08:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 21 Mar 2014 15:08:19 +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 16:08:27 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 1WR13U-0003n7-Cp for geb-bug-gnu-emacs@m.gmane.org; Fri, 21 Mar 2014 16:08:20 +0100 Original-Received: from localhost ([::1]:53248 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WR13T-00064c-V1 for geb-bug-gnu-emacs@m.gmane.org; Fri, 21 Mar 2014 11:08:19 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33840) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WR13J-00064B-R5 for bug-gnu-emacs@gnu.org; Fri, 21 Mar 2014 11:08:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WR13C-0008Ae-G2 for bug-gnu-emacs@gnu.org; Fri, 21 Mar 2014 11:08:09 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:42525) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WR13C-00089y-CR for bug-gnu-emacs@gnu.org; Fri, 21 Mar 2014 11:08:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WR13B-00037j-VP for bug-gnu-emacs@gnu.org; Fri, 21 Mar 2014 11:08: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 15:08:01 +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.139541442811931 (code B ref 17046); Fri, 21 Mar 2014 15:08:01 +0000 Original-Received: (at 17046) by debbugs.gnu.org; 21 Mar 2014 15:07:08 +0000 Original-Received: from localhost ([127.0.0.1]:43707 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WR12J-00036M-TC for submit@debbugs.gnu.org; Fri, 21 Mar 2014 11:07:08 -0400 Original-Received: from mout.gmx.net ([212.227.15.18]:54459) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WR12G-00036A-8e for 17046@debbugs.gnu.org; Fri, 21 Mar 2014 11:07:05 -0400 Original-Received: from [62.47.252.94] ([62.47.252.94]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MWTfu-1WcWa503MQ-00XftR; Fri, 21 Mar 2014 16:07:03 +0100 In-Reply-To: <21292.6903.499178.348@capuchin.co.uk> X-Provags-ID: V03:K0:gnvJNwpAmNpVcj00pCN8HXwtKjHQ6J6ye3Yf9F8AYevvPp6IlfZ rKokhTtYAEsIoN3y5U1bXegDA5mabpHp/YZE7UrV+9edpv1d4zeCocJ3W1jzg5bnb5qApDF PbVWOu55mKZgd5mY/i1+v7pdVBu3hhuEuI3cH9RmFxQcvaiDjEutuAguU5m2te98RMJOMRy G1DfEP7cbxcOjIsIE92nA== 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:87104 Archived-At: > > Once more (I'm confused): What I wanted you to try is to get that bad > > frame (the one without title decoration and without minibuffer) back on > > screen. Let's call this the "bad base state". Now please in that state > > do: > > > > (1) Apply your window manager's key shortcut to maximize it and then the > > shortcut to restore its normal size. Do title bar or minibuffer > > come back? > > No both in the 'maximized' state and on restored the window is exactly > the same (though in a different position relative to the rest of the > screen). The one difference is that the emacs frame which was > originally showing two windows Do you mean the "bad base state" frame was showing two windows before maximization? Or do you mean the frame whose state was saved and should have been restored was showing two windows? Or does the "second window" refer to the minibuffer window? > now only shows one window. I'm > including a screenshot of the maximised state. Other applications > maximise as expected - as does emacs when the desktop isn't loaded. > (I commented in a previous message that maximise isn't working > properly when the frame is in this state). You mean it simply does not maximize, as can be seen on the screenshot. Are the three buttons (minimize, maximize, delete) on the right of the toolbar something you've seen before on your system? I don't see them on the screenshot you sent earlier. What happens when you click on them? Finally, there are no scroll bars and no right fringes on this frame which probably count as more bugs. > Is the maximise state happening but the border is only giving a > partial window and the other buffer is there but the frame cuts off > visibility? The frame dump you sent earlier indicates that the Emacs frame/window handling code considers everything in order. This means that the bug happens either in the communcation between window manager and Emacs or that Emacs doesn't redraw the frame orderly. But all this is dwarfed by the fact that there's no title line and the strange buttons on the right of the frame. > > (2) In the bad base state type F11. Does anything change? Type F11 > > again. Does anything change this time? > > Exactly the same behaviour as in case (1) Remarkable. One clue less for the disappearance of the title line. > I exited the bad state emacs but with only one window shown in the > frame and then restarted emacs and the frame was displayed correctly! > I then displayed another buffer in a second window in that frame and > exited again. On a restart the problem was back. I can only assure you that yours is the strangest behavior I've seen over the past year. > The problem only seems to occur when the frame is trying to show 2 > buffers? OK. I'm happy that the problem is reliably repeatable. So please proceed as follows: (1) In the frame whose state you save, just before exiting it, do `window--dump-frame' and post the contents of the *window-frame-dump* buffer here and also the value of `desktop-saved-frameset' for control. (2) Repeat the experiment with two side-by-side windows (that is call `split-window-right' before saving the desktop) and proceed as described in (1). Thanks, martin