[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows

From: martin rudalics
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

>   > 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]