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

[Robert Marshall]

On starting emacs with desktop enabled the frame appears normal until
loading is complete when the window title/ iconize button etc disappears
together with the minibuffer. I have a screenshot of the frame (if
needed for clarity)

Commenting out these lines in .emacs gets rid of the problem

(desktop-save-mode 1)
(add-to-list 'desktop-globals-to-save 'compile-command)
(add-to-list 'desktop-globals-to-save 'compile-history)

though there's rather a lot of buffers created when those lines are
present!

If I create another frame that appears normal.

initial-frame-alist ;; is set to
((menu-bar-lines . 1) (background-color . "mint cream") (width . 120) (foreground-color . "DarkOrchid1") (font . "Inconsolata-12") (alpha . 90))

default-frame-alist ;; is set to
((menu-bar-lines . 1) (background-color . "mint cream") (foreground-color . "DarkOrchid1") (font . "Inconsolata-12") (width . 80) (alpha . 90))

I did a build from bzr which produced this problem my previous build
(Dec 23rd 2013) didn't have this issue

In GNU Emacs 24.3.50.2 (i686-pc-linux-gnu, GTK+ Version 3.8.6)
of 2014-03-14 on poulenc
Repository revision: 116756 ***@gmx.at-20140314103846-ytcz7b30ocmzo8jh
Windowing system distributor `The X.Org Foundation', version 11.0.11405000
System Description: Ubuntu 13.10

Important settings:
value of $LANG: en_GB.UTF-8
locale-coding-system: utf-8-unix

Major mode: Emacs-Lisp

Minor modes in effect:
diff-auto-refine-mode: t
shell-dirtrack-mode: t
which-function-mode: t
global-hi-lock-mode: t
hi-lock-mode: t
desktop-save-mode: t
recentf-mode: t
show-paren-mode: t
tooltip-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t

Recent input:
<select-window> <help-echo> <select-window> <help-echo>
C-x 5 2 <switch-frame> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <menu-bar> <help-menu> <se
nd-emacs-bug-report>

Recent messages:
Indentation variables are now local.
Indentation setup for shell type sh
Parsing archive file...done.
Mark set [2 times]
Setting up indent for shell type sh
Indentation variables are now local.
Indentation setup for shell type sh
Wrote /home/robert/.emacs.desktop.lock
Desktop: 1 frame, 265 buffers restored.
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

Features:
(shadow sort mail-extr warnings emacsbug message cl-macs gv rfc822 mml
mml-sec mm-decode mm-bodies mm-encode mailabbrev gmm-utils mailheader
sendmail mail-utils arc-mode archive-mode make-mode autorevert
filenotify score-mode tar-mode vc-bzr js thingatpt diff-mode nxml-uchnm
rng-xsd xsd-regexp rng-cmpct rng-nxml rng-valid rng-loc rng-uri
rng-parse nxml-parse rng-match rng-dt rng-util rng-pttrn nxml-ns
nxml-mode nxml-outln nxml-rap nxml-util nxml-glyph nxml-enc xmltok
vc-cvs texinfo dired-aux vc-svn perl-mode gud nroff-mode org-element
org-rmail org-mhe org-irc org-info org-gnus org-docview doc-view
jka-compr image-mode org-bibtex bibtex org-bbdb org-w3m org org-macro
org-footnote org-pcomplete org-list org-faces org-entities noutline
outline easy-mmode org-version ob-emacs-lisp ob ob-tangle org-src ob-ref
ob-lob ob-table ob-keys ob-exp ob-comint ob-core ob-eval org-compat
org-macs org-loaddefs format-spec find-func flyspell ispell tex-mode
compile shell pcomplete sgml-mode info sh-script smie executable vc-dir
ewoc vc vc-dispatcher vc-git which-func imenu cc-langs cc-mode cc-fonts
cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs
dired-x dired python comint ring ansi-color twittering-mode advice
identica-mode json url-http tls url-auth mail-parse rfc2231 rfc2047
rfc2045 ietf-drums url-gw url url-proxy url-privacy url-expand
url-methods url-history url-cookie url-domsuf url-util url-parse
auth-source eieio byte-opt bytecomp byte-compile cconv eieio-core
gnus-util mm-util help-fns mail-prsvr password-cache url-vars mailcap
longlines parse-time xml cl solar cal-dst cal-bahai cal-hebrew
cal-julian holidays hol-loaddefs diary-lib diary-loaddefs cal-menu
calendar cal-loaddefs server tbemail org-install hi-lock desktop
frameset recentf tree-widget wid-edit cl-loaddefs cl-lib easymenu paren
time-date tooltip electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel x-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list newcomment lisp-mode prog-mode register page menu-bar
rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax
facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak
czech european ethiopic indian cyrillic chinese case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer nadvice loaddefs button
faces cus-face macroexp files text-properties overlay sha1 md5 base64
format env code-pages mule custom widget hashtable-print-readable
backquote make-network-process dbusbind gfilenotify dynamic-setting
system-font-setting font-render-setting move-toolbar gtk x-toolkit x
multi-tty emacs)

[martin rudalics]

Post by Robert Marshall
On starting emacs with desktop enabled the frame appears normal until
loading is complete when the window title/ iconize button etc disappears
together with the minibuffer. I have a screenshot of the frame (if
needed for clarity)

Can you please do M-: (window--dump-frame) in that frame and post the
contents of the buffer *window-frame-dump* here.

Thanks, martin

[Robert Marshall]

Post by martin rudalics

Post by Robert Marshall
On starting emacs with desktop enabled the frame appears normal until
loading is complete when the window title/ iconize button etc disappears
together with the minibuffer. I have a screenshot of the frame (if
needed for clarity)

Can you please do M-: (window--dump-frame) in that frame and post the
contents of the buffer *window-frame-dump* here.

Here it is:

frame pixel: 992 x 648 cols/lines: 124 x 36 units: 8 x 18
frame text pixel: 960 x 648 cols/lines: 120 x 36
tool: 0 scroll: 16 fringe: 16 border: 0 right: 0 bottom: 0

#<window 3 on .emacs> parent: nil
pixel left: 0 top: 0 size: 992 x 630 new: 561
char left: 0 top: 0 size: 124 x 35 new: 34
normal: 1.0 x 1.0 new: ignore
body pixel: 960 x 612 char: 120 x 34
width left fringe: 8 left margin: 0 right margin: 0
width right fringe: 8 scroll-bar: 16 divider: 0
height header-line: 0 mode-line: 18 divider: 0

#<window 4 on *Minibuf-0*> parent: nil
pixel left: 0 top: 630 size: 992 x 18 new: 0
char left: 0 top: 35 size: 992 x 1 new: 0
normal: 1.0 x 1.0 new: 0
body pixel: 960 x 18 char: 120 x 1
width left fringe: 8 left margin: 0 right margin: 0
width right fringe: 8 scroll-bar: 16 divider: 0
height header-line: 0 mode-line: 0 divider: 0

[martin rudalics]

Post by Robert Marshall
frame pixel: 992 x 648 cols/lines: 124 x 36 units: 8 x 18
frame text pixel: 960 x 648 cols/lines: 120 x 36
tool: 0 scroll: 16 fringe: 16 border: 0 right: 0 bottom: 0
#<window 3 on .emacs> parent: nil
pixel left: 0 top: 0 size: 992 x 630 new: 561
char left: 0 top: 0 size: 124 x 35 new: 34
normal: 1.0 x 1.0 new: ignore
body pixel: 960 x 612 char: 120 x 34
width left fringe: 8 left margin: 0 right margin: 0
width right fringe: 8 scroll-bar: 16 divider: 0
height header-line: 0 mode-line: 18 divider: 0
#<window 4 on *Minibuf-0*> parent: nil
pixel left: 0 top: 630 size: 992 x 18 new: 0
char left: 0 top: 35 size: 992 x 1 new: 0
normal: 1.0 x 1.0 new: 0
body pixel: 960 x 18 char: 120 x 1
width left fringe: 8 left margin: 0 right margin: 0
width right fringe: 8 scroll-bar: 16 divider: 0
height header-line: 0 mode-line: 0 divider: 0

Thanks. According to that dump you should see the minibuffer. What
does evaluating

M-: (frame-parameter nil 'minibuffer)

give? The fact that no title bar is visible is even more strange. Do
you see menu bar and scroll bar normally? Post your screenshot, it's
simpler than telling details. And what happens when you maximize the
frame and restore its normal size immediately afterwards?

martin

[Robert Marshall]

Post by martin rudalics
Thanks. According to that dump you should see the minibuffer.

Definitely no minibuffer, I had to do the M-: commands very carefully
as I couldn't see what I was typing!

Post by martin rudalics
What
does evaluating
M-: (frame-parameter nil 'minibuffer)

Unfortunately after Juanma's suggested change (and then reverting it
and an emacs restart) I get the frame *with* a minibuffer but without
the window decorations.

When that command gives me:

#<window 4 on *Minibuf-0*>

but that is probably not relevant in the new situation

Post by martin rudalics
give? The fact that no title bar is visible is even more strange. Do
you see menu bar and scroll bar normally? Post your screenshot, it's
simpler than telling details.

(sorry I wasn't sure if you needed to do something special to
associate an image with a bug report, I'm just attaching it to the
email) I'm attaching the screenshot together with a normal emacs frame
for comparison

[martin rudalics]

Post by Robert Marshall

Post by martin rudalics
Thanks. According to that dump you should see the minibuffer.

Definitely no minibuffer, I had to do the M-: commands very carefully
as I couldn't see what I was typing!

Sorry, I forgot. You can always insert such text in *scratch* and
evaluate it there.

Post by Robert Marshall
(sorry I wasn't sure if you needed to do something special to
associate an image with a bug report, I'm just attaching it to the
email) I'm attaching the screenshot together with a normal emacs frame
for comparison

Very good. It's still a complete mystery to me how the title line can
disappear. Usually this happens only when the window manager thinks
(because Emacs told him) that the frame is fullscreen.

Post by Robert Marshall
I'm running with a fairly standard kde plasma desktop - so the bit
above the menu bar is all missing (and the left hand frame is the
faulty one)

Post by martin rudalics
And what happens when you maximize the
frame and restore its normal size immediately afterwards?

Ah now that's interesting! When I maximize - selecting the relevant
frame in the toolbar and using that popup WM menu option (I've also
tried using M-<f10> and get the same result) the frame moves to the
top left of the screen but *doesn't* maximise it remains (AFAICT)
the same size and the minibuffer now disappears!

Sorry. How can a non-existent minibuffer disappear?

Post by Robert Marshall
With no minibuffer I
then get
#<window 4 on *Minibuf-1*>
for the frame parameter. When I take off maximisation the minibuffer
is restored - but still no window decorations. Is this a kde/plasma
bug - or maybe a gtk/plasma bug?

As a rule, the title bar should disappear if and only if Emacs asked for
the frame to become fullscreen where it doesn't matter if the frame
actually is fullscreen. For example, here on Windows I can make a frame
fullscreen via F11, maximize and demaximize it via Windows commands and
get a normal-sized frame without title. So far I've not been able to
produce a similar behavior on GTK.

martin

[Robert Marshall]

Post by martin rudalics
Very good. It's still a complete mystery to me how the title line can
disappear. Usually this happens only when the window manager thinks
(because Emacs told him) that the frame is fullscreen.

Even when I maximize (with a unbuggy frame) I still see the title
line, is this windows vs kde? I can't see anything in kde system
settings which might affect this.

Post by martin rudalics

Post by Robert Marshall
I'm running with a fairly standard kde plasma desktop - so the bit
above the menu bar is all missing (and the left hand frame is the
faulty one)

Post by martin rudalics
And what happens when you maximize the
frame and restore its normal size immediately afterwards?

Ah now that's interesting! When I maximize - selecting the relevant
frame in the toolbar and using that popup WM menu option (I've also
tried using M-<f10> and get the same result) the frame moves to the
top left of the screen but *doesn't* maximise it remains (AFAICT)
the same size and the minibuffer now disappears!

Sorry. How can a non-existent minibuffer disappear?

Sorry the context is after putting desktop-restore-frames to nil _on
startup_ the frame came up ok (as I said in the snipped bit of the
message you were replying to:

Unfortunately after Juanma's suggested change (and then reverting it
and an emacs restart) I get the frame *with* a minibuffer but without
the window decorations.)

so it is there at startup but on 'maximize' (which isn't really
maximize) it disappears.

Having just tried it again (and the exit put desktop-saved-frameset
back). I'm again getting a single frame with no decorations and no
minibuffer I'll save that desktop file - it looks to me as if there's
only one frame now in the desktop file (at least there's only one
frameset--id which I assume is the determinant)

(setq desktop-saved-frameset [frameset 1 (21291 19570 712781 440000) (desktop . "206") "***@poulenc" nil nil ((((font-backend xft x) (font . "-unknown-Inconsolata-normal-normal-normal-*-16-*-*-*-m-0-iso10646-1") (font-parameter . "Inconsolata-12") (border-width . 0) (internal-border-width . 0) (right-divider-width . 0) (bottom-divider-width . 0) (vertical-scroll-bars . right) (foreground-color . "DarkOrchid1") (background-color . "mint cream") (mouse-color . "#221f1e") (border-color . "black") (screen-gamma) (line-spacing) (left-fringe . 8) (right-fringe . 8) (scroll-bar-foreground . "#221f1e") (scroll-bar-background . "grey75") (menu-bar-lines . 1) (tool-bar-lines . 1) (title) (wait-for-wm . t) (fullscreen) (tool-bar-position . top) (icon-type . t) (auto-raise) (auto-lower) (cursor-type . box) (scroll-bar-width . 16) (alpha . 90) (horizontal-scroll-bars . t) (display-type . color) (background-mode . light) (cursor-color . "#221f1e") (sticky) (environment) (frameset--id . "DA9D-E03E-DF32-EAB7") (frameset--mini t . t) (modeline . t) (minibuffer . t) (unsplittable) (icon-name) (visibility . icon) (display . ":0") (explicit-name) (height . 30) (width . 120)) ((min-height . 8) (min-width . 10) (min-height-ignore . 4) (min-width-ignore . 6) (min-height-safe . 2) (min-width-safe . 2) (min-pixel-height . 144) (min-pixel-width . 80) (min-pixel-height-ignore . 72) (min-pixel-width-ignore . 48) (min-pixel-height-safe . 36) (min-pixel-width-safe . 16)) vc (pixel-width . 992) (pixel-height . 522) (total-width . 124) (total-height . 29) (normal-height . 1.0) (normal-width . 1.0) (combination-limit) (leaf (pixel-width . 992) (pixel-height . 275) (total-width . 124) (total-height . 15) (normal-height . 0.5172413793103448) (normal-width . 1.0) (buffer "WikipediaApplet.cpp" (selected . t) (hscroll . 0) (fringes 8 8 nil) (margins nil) (scroll-bars 16 2 t nil) (vscroll . 0) (dedicated) (point . 20906) (start . 20858))) (leaf (last . t) (pixel-width . 992) (pixel-height . 247) (total-width . 124) (total-height . 14) (normal-height . 0.4827586206896552) (normal-width . 1.0) (buffer ".emacs" (selected) (hscroll . 0) (fringes 8 8 nil) (margins nil) (scroll-bars 16 2 t nil) (vscroll . 0) (dedicated) (point . 3612) (start . 3165)))))])

Robert
--
Links and things http://rms

[Juanma Barranquero]

Post by Robert Marshall
Having just tried it again (and the exit put desktop-saved-frameset
back). I'm again getting a single frame with no decorations and no
minibuffer I'll save that desktop file - it looks to me as if there's
only one frame now in the desktop file (at least there's only one
frameset--id which I assume is the determinant)

Yes, one frame:

[frameset
1
(21291 19570 712781 440000)
(desktop . "206")
"***@poulenc" nil nil
((;; ********** FRAME 1
((font-backend xft x)
(font . "-unknown-Inconsolata-normal-normal-normal-*-16-*-*-*-m-0-iso10646-1")
(font-parameter . "Inconsolata-12")
(border-width . 0)
(internal-border-width . 0)
(right-divider-width . 0)
(bottom-divider-width . 0)
(vertical-scroll-bars . right)
(foreground-color . "DarkOrchid1")
(background-color . "mint cream")
(mouse-color . "#221f1e")
(border-color . "black")
(screen-gamma)
(line-spacing)
(left-fringe . 8)
(right-fringe . 8)
(scroll-bar-foreground . "#221f1e")
(scroll-bar-background . "grey75")
(menu-bar-lines . 1)
(tool-bar-lines . 1)
(title)
(wait-for-wm . t)
(fullscreen)
(tool-bar-position . top)
(icon-type . t)
(auto-raise)
(auto-lower)
(cursor-type . box)
(scroll-bar-width . 16)
(alpha . 90)
(horizontal-scroll-bars . t)
(display-type . color)
(background-mode . light)
(cursor-color . "#221f1e")
(sticky)
(environment)
(frameset--id . "DA9D-E03E-DF32-EAB7")
(frameset--mini t . t)
(modeline . t)
(minibuffer . t)
(unsplittable)
(icon-name)
(visibility . icon)
(display . ":0")
(explicit-name)
(height . 30)
(width . 120))
;; ********** WINDOW TREE 1
((min-height . 8)
(min-width . 10)
(min-height-ignore . 4)
(min-width-ignore . 6)
(min-height-safe . 2)
(min-width-safe . 2)
(min-pixel-height . 144)
(min-pixel-width . 80)
(min-pixel-height-ignore . 72)
(min-pixel-width-ignore . 48)
(min-pixel-height-safe . 36)
(min-pixel-width-safe . 16))
vc
(pixel-width . 992)
(pixel-height . 522)
(total-width . 124)
(total-height . 29)
(normal-height . 1.0)
(normal-width . 1.0)
(combination-limit)
(leaf (pixel-width . 992)
(pixel-height . 275)
(total-width . 124)
(total-height . 15)
(normal-height . 0.5172413793103448)
(normal-width . 1.0)
(buffer "WikipediaApplet.cpp" (selected . t)
(hscroll . 0)
(fringes 8 8 nil)
(margins nil)
(scroll-bars 16 2 t nil)
(vscroll . 0)
(dedicated)
(point . 20906)
(start . 20858)))
(leaf (last . t)
(pixel-width . 992)
(pixel-height . 247)
(total-width . 124)
(total-height . 14)
(normal-height . 0.4827586206896552)
(normal-width . 1.0)
(buffer ".emacs" (selected)
(hscroll . 0)
(fringes 8 8 nil)
(margins nil)
(scroll-bars 16 2 t nil)
(vscroll . 0)
(dedicated)
(point . 3612)
(start . 3165)))))]

Anyway, I'm having trouble understanding how it happens. Could you
please make a step-by-step description, starting with a minimal .emacs
and detailing everything you do until you see the problem?

TIA,

J

[Robert Marshall]

Post by Juanma Barranquero
Anyway, I'm having trouble understanding how it happens. Could you
please make a step-by-step description, starting with a minimal .emacs
and detailing everything you do until you see the problem?

Me2! Do you want me also to start with an empty .emacs.desktop file?
It may take a little time to replicate from a clean sheet but I'll
give it a go.


Robert

[Juanma Barranquero]

Post by Robert Marshall
Me2! Do you want me also to start with an empty .emacs.desktop file?

With no desktop file, yes.

Post by Robert Marshall
It may take a little time to replicate from a clean sheet but I'll
give it a go.

It's the best way to isolate what's relevant to the bug and what's not.

Thanks,

J

[martin rudalics]

Post by Robert Marshall
[frameset
1
(21291 19570 712781 440000)
(desktop . "206")
((;; ********** FRAME 1
(total-height . 29)

...

Post by Robert Marshall
(total-height . 15)

...

Post by Robert Marshall
(total-height . 14)

A frame with a 15 lines window above and a 14 lines window below. Looks
normal to me.

martin

[martin rudalics]

Post by Robert Marshall
Even when I maximize (with a unbuggy frame) I still see the title
line, is this windows vs kde? I can't see anything in kde system
settings which might affect this.

Maximizing preserves the title. Fullscreen (via F11) doesn't.

Post by Robert Marshall

Post by martin rudalics
Sorry. How can a non-existent minibuffer disappear?

Sorry the context is after putting desktop-restore-frames to nil _on
startup_ the frame came up ok (as I said in the snipped bit of the
Unfortunately after Juanma's suggested change (and then reverting it
and an emacs restart) I get the frame *with* a minibuffer but without
the window decorations.)
so it is there at startup but on 'maximize' (which isn't really
maximize) it disappears.
Having just tried it again (and the exit put desktop-saved-frameset
back). I'm again getting a single frame with no decorations and no
minibuffer I'll save that desktop file - it looks to me as if there's
only one frame now in the desktop file (at least there's only one
frameset--id which I assume is the determinant)

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?

(2) In the bad base state type F11. Does anything change? Type F11
again. Does anything change this time?

For me the only explanation for a missing title in a normal-sized frame
is fullscreen mode gone astray. Does anyone have a better explanation?

Thanks, martin

[martin rudalics]

Post by martin rudalics
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
(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.

Post by martin rudalics
(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

[Robert Marshall]

Post by martin rudalics

Post by martin rudalics
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
(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.

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). The emacs scroll bars and fringe disappear when the
window gets the maximise command.

When the maximise happens - as you see the frame doesn't appear to
change size but it does relocate - it starts off in the centre of the
screen and f11 causes it to move to the top left of the screen - so
the correct place - if only the rest of the frame were the correct
size! It would appear that the frame is only showing part of what
should be there - on further experimentation I've managed to
'maximise' so that the top window appears ok but the lower window only
displays a few lines with no mode line visible and C-x o takes me into
that area of around 3.5 lines and I could scroll up and down in that
window without a mode line.

Post by martin rudalics

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.

Post by martin rudalics
(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
(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.

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)

frame pixel: 992 x 648 cols/lines: 124 x 36 units: 8 x 18
frame text pixel: 960 x 648 cols/lines: 120 x 36
tool: 0 scroll: 16 fringe: 16 border: 0 right: 0 bottom: 0

#<window 7> parent: nil
pixel left: 0 top: 0 size: 992 x 630 new: 992
char left: 0 top: 0 size: 124 x 35 new: 124
normal: 1.0 x 1.0 new: nil

#<window 3 on .emacs> parent: #<window 7>
pixel left: 0 top: 0 size: 992 x 314 new: 992
char left: 0 top: 0 size: 124 x 17 new: 124
normal: 1.0 x 0.5 new: nil
body pixel: 960 x 296 char: 120 x 16
width left fringe: 8 left margin: 0 right margin: 0
width right fringe: 8 scroll-bar: 16 divider: 0
height header-line: 0 mode-line: 18 divider: 0

#<window 8 on *scratch*> parent: #<window 7>
pixel left: 0 top: 314 size: 992 x 316 new: 992
char left: 0 top: 17 size: 124 x 18 new: 124
normal: 1.0 x 0.5 new: nil
body pixel: 960 x 298 char: 120 x 16
width left fringe: 8 left margin: 0 right margin: 0
width right fringe: 8 scroll-bar: 16 divider: 0
height header-line: 0 mode-line: 18 divider: 0

#<window 4 on *Minibuf-0*> parent: nil
pixel left: 0 top: 630 size: 992 x 18 new: 0
char left: 0 top: 35 size: 992 x 1 new: 240
normal: 1.0 x 1.0 new: 0
body pixel: 960 x 18 char: 120 x 1
width left fringe: 8 left margin: 0 right margin: 0
width right fringe: 8 scroll-bar: 16 divider: 0
height header-line: 0 mode-line: 0 divider: 0

I then exit and here is desktop-saved-frameset

Post by martin rudalics
(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).

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, I started emacs 3-4 times without the problem,
eventually I got a bad frame and got the results below:

frame pixel: 992 x 648 cols/lines: 124 x 36 units: 8 x 18
frame text pixel: 960 x 648 cols/lines: 120 x 36
tool: 0 scroll: 16 fringe: 16 border: 0 right: 0 bottom: 0

#<window 11> parent: nil
pixel left: 0 top: 0 size: 992 x 630 new: 992
char left: 0 top: 0 size: 124 x 35 new: 124
normal: 1.0 x 1.0 new: 1.0

#<window 3 on .emacs> parent: #<window 11>
pixel left: 0 top: 0 size: 496 x 630 new: 496
char left: 0 top: 0 size: 62 x 35 new: 62
normal: 0.5 x 1.0 new: 0.5
body pixel: 464 x 612 char: 58 x 34
width left fringe: 8 left margin: 0 right margin: 0
width right fringe: 8 scroll-bar: 16 divider: 0
height header-line: 0 mode-line: 18 divider: 0

#<window 12 on .emacs> parent: #<window 11>
pixel left: 496 top: 0 size: 496 x 630 new: 496
char left: 62 top: 0 size: 62 x 35 new: 62
normal: 0.5 x 1.0 new: 0.5
body pixel: 464 x 612 char: 58 x 34
width left fringe: 8 left margin: 0 right margin: 0
width right fringe: 8 scroll-bar: 16 divider: 0
height header-line: 0 mode-line: 18 divider: 0

#<window 4 on *Minibuf-0*> parent: nil
pixel left: 0 top: 630 size: 992 x 18 new: 0
char left: 0 top: 35 size: 124 x 1 new: 124
normal: 1.0 x 1.0 new: 0
body pixel: 960 x 18 char: 120 x 1
width left fringe: 8 left margin: 0 right margin: 0
width right fringe: 8 scroll-bar: 16 divider: 0
height header-line: 0 mode-line: 0 divider: 0

(setq desktop-saved-frameset [frameset 1 (21292 27767 934040 895000) (desktop . "206") "***@poulenc" nil nil ((((font-backend xft x) (font . "-unknown-Inconsolata-normal-normal-normal-*-16-*-*-*-m-0-iso10646-1") (font-parameter . "Inconsolata-12") (border-width . 0) (internal-border-width . 0) (right-divider-width . 0) (bottom-divider-width . 0) (vertical-scroll-bars . right) (foreground-color . "DarkOrchid1") (background-color . "mint cream") (mouse-color . "#221f1e") (border-color . "black") (screen-gamma) (line-spacing) (left-fringe . 8) (right-fringe . 8) (scroll-bar-foreground . "#221f1e") (scroll-bar-background . "grey75") (menu-bar-lines . 1) (tool-bar-lines . 1) (title) (wait-for-wm . t) (fullscreen) (tool-bar-position . top) (icon-type . t) (auto-raise) (auto-lower) (cursor-type . box) (scroll-bar-width . 16) (alpha . 90) (horizontal-scroll-bars . t) (display-type . color) (background-mode . light) (cursor-color . "#221f1e") (sticky) (environment) (maximized) (frameset--id . "C8B6-55AF-6CE3-E1B1") (frameset--mini t . t) (modeline . t) (minibuffer . t) (unsplittable) (icon-name) (visibility . icon) (display . ":0") (explicit-name) (height . 37) (width . 120)) ((min-height . 4) (min-width . 20) (min-height-ignore . 2) (min-width-ignore . 12) (min-height-safe . 1) (min-width-safe . 4) (min-pixel-height . 72) (min-pixel-width . 160) (min-pixel-height-ignore . 36) (min-pixel-width-ignore . 96) (min-pixel-height-safe . 18) (min-pixel-width-safe . 32)) hc (pixel-width . 992) (pixel-height . 648) (total-width . 124) (total-height . 36) (normal-height . 1.0) (normal-width . 1.0) (combination-limit) (leaf (pixel-width . 496) (pixel-height . 648) (total-width . 62) (total-height . 36) (normal-height . 1.0) (normal-width . 0.5) (buffer ".emacs" (selected . t) (hscroll . 0) (fringes 8 8 nil) (margins nil) (scroll-bars 16 2 t nil) (vscroll . 0) (dedicated) (point . 4262) (start . 3837))) (leaf (last . t) (pixel-width . 496) (pixel-height . 648) (total-width . 62) (total-height . 36) (normal-height . 1.0) (normal-width . 0.5) (buffer ".emacs" (selected) (hscroll . 0) (fringes 8 8 nil) (margins nil) (scroll-bars 16 2 t nil) (vscroll . 0) (dedicated) (point . 4262) (start . 3837)))))])


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

frame pixel: 992 x 666 cols/lines: 124 x 37 units: 8 x 18
frame text pixel: 960 x 666 cols/lines: 120 x 37
tool: 0 scroll: 16 fringe: 16 border: 0 right: 0 bottom: 0

#<window 3 on *scratch*> parent: nil
pixel left: 0 top: 0 size: 992 x 648 new: 648
char left: 0 top: 0 size: 124 x 36 new: 34
normal: 1.0 x 1.0 new: nil
body pixel: 960 x 630 char: 120 x 35
width left fringe: 8 left margin: 0 right margin: 0
width right fringe: 8 scroll-bar: 16 divider: 0
height header-line: 0 mode-line: 18 divider: 0

#<window 4 on *Minibuf-0*> parent: nil
pixel left: 0 top: 648 size: 992 x 18 new: 0
char left: 0 top: 36 size: 124 x 1 new: 1
normal: 1.0 x 1.0 new: 0
body pixel: 960 x 18 char: 120 x 1
width left fringe: 8 left margin: 0 right margin: 0
width right fringe: 8 scroll-bar: 16 divider: 0
height header-line: 0 mode-line: 0 divider: 0

And on exit .emacs.desktop contains

(setq desktop-saved-frameset [frameset 1 (21292 27934 99775 17000) (desktop . "206") "***@poulenc" nil nil ((((font-backend xft x) (font . "-unknown-Inconsolata-normal-normal-normal-*-16-*-*-*-m-0-iso10646-1") (font-parameter . "Inconsolata-12") (border-width . 0) (internal-border-width . 0) (right-divider-width . 0) (bottom-divider-width . 0) (vertical-scroll-bars . right) (foreground-color . "DarkOrchid1") (background-color . "mint cream") (mouse-color . "#221f1e") (border-color . "black") (screen-gamma) (line-spacing) (left-fringe . 8) (right-fringe . 8) (scroll-bar-foreground . "#221f1e") (scroll-bar-background . "grey75") (menu-bar-lines . 1) (tool-bar-lines . 1) (title) (wait-for-wm . t) (fullscreen) (tool-bar-position . top) (icon-type . t) (auto-raise) (auto-lower) (cursor-type . box) (scroll-bar-width . 16) (alpha . 90) (horizontal-scroll-bars . t) (display-type . color) (background-mode . light) (cursor-color . "#221f1e") (sticky) (environment) (maximized) (frameset--id . "C8B6-55AF-6CE3-E1B1") (frameset--mini t . t) (modeline . t) (minibuffer . t) (unsplittable) (icon-name) (visibility . t) (display . ":0") (explicit-name) (height . 37) (width . 120) (left . 590) (top . 94)) ((min-height . 4) (min-width . 10) (min-height-ignore . 2) (min-width-ignore . 6) (min-height-safe . 1) (min-width-safe . 2) (min-pixel-height . 72) (min-pixel-width . 80) (min-pixel-height-ignore . 36) (min-pixel-width-ignore . 48) (min-pixel-height-safe . 18) (min-pixel-width-safe . 16)) leaf (pixel-width . 992) (pixel-height . 648) (total-width . 124) (total-height . 36) (normal-height . 1.0) (normal-width . 1.0) (buffer ".emacs" (selected . t) (hscroll . 0) (fringes 8 8 nil) (margins nil) (scroll-bars 16 2 t nil) (vscroll . 0) (dedicated) (point . 4262) (star

[martin rudalics]

Post by Robert Marshall
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.

Post by Robert Marshall
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.

Post by Robert Marshall
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

Post by Robert Marshall
#<window 4 on *Minibuf-0*> 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.

Post by Robert Marshall
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 ...

Post by Robert Marshall
I started emacs 3-4 times without the problem,

... which I didn't expect. But again the values look correct and even
the minibuffer window has the correct char width now,

Post by Robert Marshall
#<window 4 on *Minibuf-0*> 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.

Post by Robert Marshall
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

[Juanma Barranquero]

I'm a bit lost here. What do you need from me?

Post by martin rudalics
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.

One thing that Robert can try is:

1) Put Emacs in the maximized state, or whatever is that is giving
trouble (just one frame).
2) Exit Emacs (saving the desktop)
3) Copy the "(setq desktop-saved-frameset ...)" line from .emacs.desktop
4) emacs -Q
5) paste the (setq desktop-saved-frameset ...) sexp into *scratch* and eval it
6) eval the following:
(frameset-restore desktop-saved-frameset
:reuse-frames t
:cleanup-frames t
:force-onscreen t)

Then, repeat from 4) on, with the same desktop-saved-frameset value as
before, but call frameset-restore with :force-onscreen nil (or without
that line, nil is the default).

Assuming that the problem reappears doing that, at least we have a
frameset that causes it, and then we can look into it and try to
understand what happens.

[martin rudalics]

Post by Juanma Barranquero
1) Put Emacs in the maximized state, or whatever is that is giving
trouble (just one frame).

I don't understand - was it Robert's problem that he wanted to save the
Emacs desktop with a maximized frame? I only thought that _after
restoring_ the desktop, maximizing the frame didn't restore minibuffer
and title line.

So unless Robert says that this is the problem let's skip (1).

Post by Juanma Barranquero
2) Exit Emacs (saving the desktop)
3) Copy the "(setq desktop-saved-frameset ...)" line from .emacs.desktop
4) emacs -Q

Robert please try here both variants with and without -Q so we can see
whether something in your .emacs has any impact.

Post by Juanma Barranquero
5) paste the (setq desktop-saved-frameset ...) sexp into *scratch* and eval it
(frameset-restore desktop-saved-frameset
:reuse-frames t
:cleanup-frames t
:force-onscreen t)
Then, repeat from 4) on, with the same desktop-saved-frameset value as
before, but call frameset-restore with :force-onscreen nil (or without
that line, nil is the default).
Assuming that the problem reappears doing that, at least we have a
frameset that causes it, and then we can look into it and try to
understand what happens.

Thanks. This is what I had in mind with "deferring loading the desktop
file until you have seen your initial frame".

If we can repeat the problem this way, we can use the debugger.

martin

[Robert Marshall]

Post by martin rudalics

Post by Juanma Barranquero
1) Put Emacs in the maximized state, or whatever is that is giving
trouble (just one frame).

I don't understand - was it Robert's problem that he wanted to save the
Emacs desktop with a maximized frame? I only thought that _after
restoring_ the desktop, maximizing the frame didn't restore minibuffer
and title line.
So unless Robert says that this is the problem let's skip (1).

You're correct, I was never attempting to save emacs' state with it maximised
so (1) can be skipped.

Post by martin rudalics

Post by Juanma Barranquero
2) Exit Emacs (saving the desktop)
3) Copy the "(setq desktop-saved-frameset ...)" line from .emacs.desktop
4) emacs -Q

Robert please try here both variants with and without -Q so we can see
whether something in your .emacs has any impact.

OK, I'm having problems at the moment getting it to replicate either
with a -Q -l loading:
(desktop-save-mode 1)
(setq desktop-save nil) ;; so that the desktop which was giving probs is kept!
(desktop-read "/home/robert/tmp")

or with my normal .emacs will let you know when I manage to generate
the same problem again!

Robert

[martin rudalics]

Post by Robert Marshall

Post by martin rudalics

Post by Juanma Barranquero
2) Exit Emacs (saving the desktop)
3) Copy the "(setq desktop-saved-frameset ...)" line from .emacs.desktop
4) emacs -Q

Robert please try here both variants with and without -Q so we can see
whether something in your .emacs has any impact.

OK, I'm having problems at the moment getting it to replicate either
(desktop-save-mode 1)
(setq desktop-save nil) ;; so that the desktop which was giving probs is kept!
(desktop-read "/home/robert/tmp")

IIUC Juanma means that you must _not_ call `desktop-read' but rather
copy the

(setq desktop-saved-frameset ...)

form from your .emacs.desktop to *scratch* in the new emacs you just
started, evaluate that form and then do

(frameset-restore desktop-saved-frameset
:reuse-frames t
:cleanup-frames t
:force-onscreen t)

in *scratch*. If this does _not_ reproduce the problem after at most
two or three attempts I would conclude that the problem is with the
(Juanma might correct me) yet invisible frame used in the original
scenario by `desktop-read'. For an invisible frame x_set_window_size_1
chooses the else clause in

if (FRAME_VISIBLE_P (f))
x_wait_for_event (f, ConfigureNotify);
else
{
change_frame_size (f, width, height, 0, 1, 0, 1);
x_sync (f);
}

so there's no synchronization with the window manager right here and
maybe subsequently making the frame visible is not catching up with the
changes induced by change_frame_size. This is the only conclusion I
currently have left.

So once more: If you can't reproduce the problem here with very few
attempts don't insist. In this case we should try the following: Strip
your .emacs.desktop from any irrelevant entries. This means to
construct a new .emacs.desktop that is sufficient to cause the original
problem and otherwise minimal enough so we can debug it. Juanma: Can we
get a pretty printed version of Robert's .emacs.desktop such that he can
process it with `desktop-read' and we can comment out entries easily?
Then we could start in a first step do things like

;; (foreground-color . "DarkOrchid1")
;; (background-color . "mint cream")
;; (mouse-color . "#221f1e")
;; (border-color . "black")
;; (screen-gamma)
;; (line-spacing)
(left-fringe . 8)
(right-fringe . 8)
;; (scroll-bar-foreground . "#221f1e")
;; (scroll-bar-background . "grey75")
(menu-bar-lines . 1)
(tool-bar-lines . 1)
;; (title)
(wait-for-wm . t)
;; (fullscreen)
(tool-bar-position . top)
;; (icon-type . t)
;; (auto-raise)
;; (auto-lower)
;; (cursor-type . box)
(scroll-bar-width . 16)
;; (alpha . 90)
(horizontal-scroll-bars . t)
;; (display-type . color)
;; (background-mode . light)
;; (cursor-color . "#221f1e")
;; (sticky)
;; (environment)

Ideally we could comment out everything but the height and width entries
but I suppose we need some additional entry to produce the bug. Any
such entry already should provide a first clue.

Post by Robert Marshall
or with my normal .emacs will let you know when I manage to generate
the same problem again!

martin

[Juanma Barranquero]

Post by martin rudalics
IIUC Juanma means that you must _not_ call `desktop-read' but rather
copy the
(setq desktop-saved-frameset ...)
form from your .emacs.desktop to *scratch* in the new emacs you just
started, evaluate that form and then do
(frameset-restore desktop-saved-frameset
:reuse-frames t
:cleanup-frames t
:force-onscreen t)
in *scratch*.

Correct. This is the way to know if it happens *after* the original
frame is created and visible.

Post by martin rudalics
If this does _not_ reproduce the problem after at most
two or three attempts I would conclude that the problem is with the
(Juanma might correct me) yet invisible frame used in the original
scenario by `desktop-read'.

And in that case, what I would suggest is to create a file

;;; bug17046.el ;;;
(setq desktop-saved-frameset ...)
(frameset-restore desktop-saved-frameset
:reuse-frames t
:cleanup-frames t
:force-onscreen t)
;;; end ;;;

and then try

emacs -Q -l bug17046.el

(and the same with :force-onscreen nil).

Note: if the problem depends on the original frame having more than
one window (before the restore, I mean), then these windows should be
created in bug17046.el before calling `frameset-restore', of course.
Same for having several buffers, etc. But as a first test, the above
should suffice

Post by martin rudalics
Juanma: Can we
get a pretty printed version of Robert's .emacs.desktop such that he can
process it with `desktop-read' and we can comment out entries easily?

I'm not sure which one right now, but assuming the last, which he said
showed the bug, the attached file should be enough.

J

[martin rudalics]

Post by Juanma Barranquero
I'm not sure which one right now, but assuming the last, which he said
showed the bug, the attached file should be enough.

One more question: Is there a way to have frameset make all changes only
with a strictly visible frame so we have all the flickering but can avoid
that

if (FRAME_VISIBLE_P (f))
x_wait_for_event (f, ConfigureNotify);
else
{
change_frame_size (f, width, height, 0, 1, 0, 1);
x_sync (f);
}

restriction I mentioned earlier.

martin

[Juanma Barranquero]

Post by martin rudalics
One more question: Is there a way to have frameset make all changes only
with a strictly visible frame

Please clarify. Do you mean:

- Not to restore upon a non-strictly visible frame (and so choose
another or create a new one)?
- To wait until the frame is visible?

(I'm not sure what do you mean with "strictly visible", BTW).

The :reuse-frames arg of `frameset-restore' accepts a predicate, so if
you have a way to decide from Elisp that a frame is "strictly
visible", you can allow or disallow its reusing.

J

[martin rudalics]

Post by Juanma Barranquero
- Not to restore upon a non-strictly visible frame (and so choose
another or create a new one)?
- To wait until the frame is visible?

The latter, I'd say.

Post by Juanma Barranquero
(I'm not sure what do you mean with "strictly visible", BTW).

"Strictly visible" should stand for "always visible while desktop
restoration is done".

Post by Juanma Barranquero
The :reuse-frames arg of `frameset-restore' accepts a predicate, so if
you have a way to decide from Elisp that a frame is "strictly
visible", you can allow or disallow its reusing.

I meant to find some way where we, before restoring a desktop, make the
involved frame visible and then do the restoring, so the user "sees"
what happens. This obviously works only when a frame exists already
before restoration kicks in, but IIUC this is what happens in Robert's
case.

martin

[Juanma Barranquero]

Post by martin rudalics
I meant to find some way where we, before restoring a desktop, make the
involved frame visible and then do the restoring, so the user "sees"
what happens. This obviously works only when a frame exists already
before restoration kicks in, but IIUC this is what happens in Robert's
case.

I'm lost. Why wouldn't it work to call (sit-for 0) before calling
frameset-restore?

[martin rudalics]

Post by Juanma Barranquero
I'm lost. Why wouldn't it work to call (sit-for 0) before calling
frameset-restore?

Robert can you do that?

martin

[Robert Marshall]

Post by martin rudalics

Post by Juanma Barranquero
I'm lost. Why wouldn't it work to call (sit-for 0) before calling
frameset-restore?

Robert can you do that?

Can I just step back a bit, having been doing other things, I'm
rather confused as to what I'm being asked to do! I think before I
start doing to sequence of tests you've requested I need to get an
emacs which is showing a bad frame? At the moment I'm unable to
replicate this - if this isn't so let me know! But at the moment I'm
about to try generating another bad startup then I'll start on the
test at (2). (your email of Sat, 22 Mar 2014 10:40:14 +0100) before I
start doing (setq desktop-saved-frameset etc

Robert

[Juanma Barranquero]

I'm rather confused as to what I'm being asked to do!

FWIW, I'm rather confused too... ;-)

I think before I
start doing to sequence of tests you've requested I need to get an
emacs which is showing a bad frame? At the moment I'm unable to
replicate this - if this isn't so let me know!

Yes. If you restart your Emacs and get a bad frame, do not exit Emacs!
Immediately open the desktop file and get hold of the (setq
desktop-saved-frameset ...) line and save it in a safe place :-)

Then you can replace the equivalent line in my bug17046.el file with
yours, exit Emacs, and do the tests requested at your leisure.

The tests would be:

1) emacs -Q -l bug17046.el
2) Same, but replacing the ":force-onscreen t" by ":force-onscreen nil"
3) As 1), but insert (sit-for 0) at the top of bug17046.el before the test
4) As 2), but with (sit-for 0) also, as in 3)

J

[Robert Marshall]

Post by Juanma Barranquero

I'm rather confused as to what I'm being asked to do!

FWIW, I'm rather confused too... ;-)

I think before I
start doing to sequence of tests you've requested I need to get an
emacs which is showing a bad frame? At the moment I'm unable to
replicate this - if this isn't so let me know!

Yes. If you restart your Emacs and get a bad frame, do not exit Emacs!
Immediately open the desktop file and get hold of the (setq
desktop-saved-frameset ...) line and save it in a safe place :-)

OK ignore the message I've just sent apart from the question about
whether the buffers mentioned in desktop-saved-frameset need to exist

Robert

[Juanma Barranquero]

Post by Robert Marshall
OK ignore the message I've just sent apart from the question about
whether the buffers mentioned in desktop-saved-frameset need to exist

They don't *need* to exist, but you can create them at the start of
the bug17046.el file and see whether that makes a difference. If the
saved frame has multiple windows and the buffers do not exist upon
restoring, you can end with a single-window frame. Perhaps that
affects the bug.

J

[Robert Marshall]

Post by Juanma Barranquero

I'm rather confused as to what I'm being asked to do!

FWIW, I'm rather confused too... ;-)

That's a relief!

Post by Juanma Barranquero

I think before I
start doing to sequence of tests you've requested I need to get an
emacs which is showing a bad frame? At the moment I'm unable to
replicate this - if this isn't so let me know!

Yes. If you restart your Emacs and get a bad frame, do not exit Emacs!
Immediately open the desktop file and get hold of the (setq
desktop-saved-frameset ...) line and save it in a safe place :-)
Then you can replace the equivalent line in my bug17046.el file with
yours, exit Emacs, and do the tests requested at your leisure.
1) emacs -Q -l bug17046.el
2) Same, but replacing the ":force-onscreen t" by ":force-onscreen nil"
3) As 1), but insert (sit-for 0) at the top of bug17046.el before the test
4) As 2), but with (sit-for 0) also, as in 3)
J

I've run these tests (and I kept the buggy frame emacs around while I
did so and I still have it, would attaching gdb to it give you anything
useful?) in this case the frame was displaying neither the decorations
nor the minibuffer

In all 4 cases I'm afraid the bug did *not* appear - I assume this is
what I was meant to look for with just a visual check. I also compared the
emacs frame with the buggy one (maybe you already realise this) and by
aligning the top of the menubar in each frame the buggy frame stops
just at the point where the buffer modeline should appear, looking
carefully I can just see the tops of the characters on the next line
of WikipediaApplet.cpp

Maybe I should add that in all cases (since I first saw the bug) I've
been running emacs from its build directory - so for me ~/emacs-bzr/src/emacs
(rather than installing it in /usr/local/bin)

I had the following lines at the head of bug17046.el

(sit-for 0) ;; commented out as required
(find-file "~/.emacs")
(find-file "/home/robert/devel/amarok/src/context/applets/wikipedia/WikipediaApplet.cpp")

(setq desktop-saved-frameset [frameset 1 (21293 48118 633382 956000) (desktop . "206") "***@poulenc" nil nil ((((font-backend xft x) (font . "-unknown-Inconsolata-normal-normal-normal-*-16-*-*-*-m-0-iso10646-1") (font-parameter . "Inconsolata-12") (border-width . 0) (internal-border-width . 0) (right-divider-width . 0) (bottom-divider-width . 0) (vertical-scroll-bars . right) (foreground-color . "DarkOrchid1") (background-color . "mint cream") (mouse-color . "#221f1e") (border-color . "black") (screen-gamma) (line-spacing) (left-fringe . 8) (right-fringe . 8) (scroll-bar-foreground . "#221f1e") (scroll-bar-background . "grey75") (menu-bar-lines . 1) (tool-bar-lines . 1) (title) (wait-for-wm . t) (fullscreen) (tool-bar-position . top) (icon-type . t) (auto-raise) (auto-lower) (cursor-type . box) (scroll-bar-width . 16) (alpha . 90) (horizontal-scroll-bars . t) (display-type . color) (background-mode . light) (cursor-color . "#221f1e") (sticky) (environment) (maximized) (frameset--id . "C8B6-55AF-6CE3-E1B1") (frameset--mini t . t) (modeline . t) (minibuffer . t) (unsplittable) (icon-name) (visibility . t) (display . ":0") (explicit-name) (height . 34) (width . 120) (left . 590) (top . 94)) ((min-height . 8) (min-width . 10) (min-height-ignore . 4) (min-width-ignore . 6) (min-height-safe . 2) (min-width-safe . 2) (min-pixel-height . 144) (min-pixel-width . 80) (min-pixel-height-ignore . 72) (min-pixel-width-ignore . 48) (min-pixel-height-safe . 36) (min-pixel-width-safe . 16)) vc (pixel-width . 992) (pixel-height . 594) (total-width . 124) (total-height . 33) (normal-height . 1.0) (normal-width . 1.0) (combination-limit) (leaf (pixel-width . 992) (pixel-height . 292) (total-width . 124) (total-height . 16) (normal-height . 0.5) (normal-width . 1.0) (buffer ".emacs" (selected . t) (hscroll . 0) (fringes 8 8 nil) (margins nil) (scroll-bars 16 2 t nil) (vscroll . 0) (dedicated) (point . 2818) (start . 2727))) (leaf (last . t) (pixel-width . 992) (pixel-height . 302) (total-width . 124) (total-height . 17) (normal-height . 0.5) (normal-width . 1.0) (buffer "WikipediaApplet.cpp" (selected) (hscroll . 0) (fringes 8 8 nil) (margins nil) (scroll-bars 16 2 t nil) (vscroll . 0) (dedicated) (point . 28638) (start . 28492)))))])

and ran

~/emacs-bzr/src/emacs -Q --no-site-file -l /home/robert/bug17046.

[Juanma Barranquero]

Post by Robert Marshall
In all 4 cases I'm afraid the bug did *not* appear - I assume this is
what I was meant to look for with just a visual check.

Well, if the bug does not appear, I don't know how to go from here :-(

J

[martin rudalics]

Post by Robert Marshall
In all 4 cases I'm afraid the bug did *not* appear - I assume this is
what I was meant to look for with just a visual check.

The fact that the bug didn't appear would be a good sign. But I'm
afraid that you ran the experiment with the bad frame. At least that is
what bug17046.el contains IIUC. What we really have to do is to run the
experiment with the original two windows frame - I attached a hopefully
correct version of that.

martin

[Juanma Barranquero]

Post by martin rudalics
The fact that the bug didn't appear would be a good sign.

Hmm. Aren't we trying to reproduce the bug from a frameset? I'm lost again.

Post by martin rudalics
At least that is
what bug17046.el contains IIUC.

I included one frameset from Robert's message, but in my instructions
I told him to substitute it.

J

[martin rudalics]

Post by Robert Marshall
Can I just step back a bit, having been doing other things, I'm
rather confused as to what I'm being asked to do!

Sorry. I'm at least as much confused as you.

Post by Robert Marshall
I think before I
start doing to sequence of tests you've requested I need to get an
emacs which is showing a bad frame?

No. We have to do something similar to restoring the frame which does
_not_ show the bad frame. Let me try to explain (I'm afraid I'm not
very good at that).

With your original recipe you get a bad frame. Unfortunately, we don't
know how to intercept that recipe, that is the frame restoration
procedure, in order to find out where things go wrong. Nothing in the
dumps gives a useful hint. Therefore we have to break up the original
monolithic recipe into various steps to find out where things go wrong.

Juanma's recipe is one such approach, simplified below:

(1) Copy the "(setq desktop-saved-frameset ...)" line from
.emacs.desktop. We presume that the inherent problem is somewhere
hidden in that form.

(2) emacs -Q

(3) Paste the (setq desktop-saved-frameset ...) sexp into *scratch* and
eval it.

(4) Eval the following:
(frameset-restore desktop-saved-frameset
:reuse-frames t
:cleanup-frames t
:force-onscreen t)

Now apparently this fails as you mentioned in your other mail because
it's missing the remaining parts of .emacs.desktop like the buffers to
be shown in the windows. I suppose this can be done easily by removing
just the

"(setq desktop-saved-frameset ...)"

form from .emas.desktop retaining everything else. Please try to do
that, save the file but keep the original around, we might need it.
Then do (1)-(4) as above with one exception: Start emacs without the -Q
option in (2) to make sure the .emacs.desktop gets read.

Now this approach might produce a bad frame or not. If it does, we can
proceed debugging `frameset-restore'. If it doesn't after a few
attempts, stop testing. Then we have restrained the problem to the fact
that `frameset-restore' breaks when working on the initial frame.

And before doing all this please wait until Juanma confirms that my new
recipe make sense at all.

martin

[Juanma Barranquero]

Post by martin rudalics
And before doing all this please wait until Juanma confirms that my new
recipe make sense at all.

Yes, though I prefer using "emacs -Q -l file.el" because desktop does
many other things, like trying to restore modes, global and local
variables, etc.

J

[martin rudalics]

Post by Juanma Barranquero
Yes, though I prefer using "emacs -Q -l file.el" because desktop does
many other things, like trying to restore modes, global and local
variables, etc.

OK. But the problem is IMO that Robert ran this with a frameset derived
from the a saved desktop of the bad frame. This won't reproduce the
problem because that frameset is likely OK (I did not see any
inconsistencies in the frame dump at least). We have to run this with a
frameset derived from the original two windows frame. I hope I attached
a correct version in my last mail, please have a look.

Now if that frameset produces two windows as I expect, we know that the
problem is with transforming the initial Emacs frame, which apparently
is not good for restoring this desktop. Then we have to step by step
remove lines from bug17046.el until we arrive at the line that causes
the problem.

martin

[Robert Marshall]

Post by martin rudalics

Post by Juanma Barranquero
Yes, though I prefer using "emacs -Q -l file.el" because desktop does
many other things, like trying to restore modes, global and local
variables, etc.

OK. But the problem is IMO that Robert ran this with a frameset derived
from the a saved desktop of the bad frame. This won't reproduce the
problem because that frameset is likely OK (I did not see any
inconsistencies in the frame dump at least). We have to run this with a
frameset derived from the original two windows frame. I hope I attached
a correct version in my last mail, please have a look.

The frameset in Juanma's bug17046.el file only appeared to have one
window (in as far as I understand the format!) and I've just tried all
4 tests with the file (& frameset) that was attached to his email (adding a
find-file of .emacs) and one window (onto .emacs) appears and no sign
of the problem

So I've tried it with your version of bug17046.el (now with 2 find-files)

Post by martin rudalics
Now if that frameset produces two windows as I expect, we know that the
problem is with transforming the initial Emacs frame, which apparently
is not good for restoring this desktop. Then we have to step by step
remove lines from bug17046.el until we arrive at the line that causes
the problem.

This does produce 2 windows but in no case is there a sign of the
problem - or is that what you are expecting? I wondered about the

(visibility . icon)

line (I don't think I ever started it up iconized) and tried the tests
both with and without it with the same result.

If I don't include the 2 find-files I get a single window onto *Messages*

Not sure whether it is relevant - or you've already assumed this
- there's no resize facility on the bad frame (apart from maximize) move
the mouse to the window corner and no resize arrows appear.

[Juanma Barranquero]

Post by Robert Marshall
I wondered about the
(visibility . icon)
line (I don't think I ever started it up iconized) and tried the tests
both with and without it with the same result.

I wonder, too. A frame with visibility . icon *should* be restored
iconified (which will affect size, as the original height and width
are not restored in that case).

In fact, an iconified frame is restored as invisible, with default
size, and then modified to iconify it.

J

[martin rudalics]

Post by Juanma Barranquero

Post by Robert Marshall
I wondered about the
(visibility . icon)
line (I don't think I ever started it up iconized) and tried the tests
both with and without it with the same result.

I wonder, too. A frame with visibility . icon *should* be restored
iconified (which will affect size, as the original height and width
are not restored in that case).
In fact, an iconified frame is restored as invisible, with default
size, and then modified to iconify it.

Easy to check. Robert, in the original .emacs.dektop file change
(visibility . icon) to (visibility . t) and try whether you can
reproduce the problem by just starting emacs the usual way.

martin

[martin rudalics]

Post by Robert Marshall
The frameset in Juanma's bug17046.el file only appeared to have one
window (in as far as I understand the format!) and I've just tried all
4 tests with the file (& frameset) that was attached to his email (adding a
find-file of .emacs) and one window (onto .emacs) appears and no sign
of the problem

I expected that.

Post by Robert Marshall
So I've tried it with your version of bug17046.el (now with 2 find-files)

Post by martin rudalics
Now if that frameset produces two windows as I expect, we know that the
problem is with transforming the initial Emacs frame, which apparently
is not good for restoring this desktop. Then we have to step by step
remove lines from bug17046.el until we arrive at the line that causes
the problem.

This does produce 2 windows but in no case is there a sign of the
problem - or is that what you are expecting?

I did. If you now ask yourself why I wanted you to try that, then it's
because I wanted to try with the more simple approaches first. BTW, you
did check all four of Juanma's scenarios, that is also the ones without
the (sit-for 0)?

Post by Robert Marshall
I wondered about the
(visibility . icon)
line (I don't think I ever started it up iconized) and tried the tests
both with and without it with the same result.

This is indeed a strange thing. Juanma, do we usually ignore this?

Post by Robert Marshall
If I don't include the 2 find-files I get a single window onto *Messages*
Not sure whether it is relevant - or you've already assumed this
- there's no resize facility on the bad frame (apart from maximize) move
the mouse to the window corner and no resize arrows appear.

It is yet another mysterious detail. Please post now your entire
.emacs.desktop file here, that is the one that you use to produce the
bad frame in the new session. I'll then try to tell you what to remove
from that file in order to narrow down the possible culprits.

And thanks for bearing with me, martin

[Juanma Barranquero]

Post by martin rudalics
BTW, you
did check all four of Juanma's scenarios, that is also the ones without
the (sit-for 0)?

Instead of (sit-for 0), I'd suggest trying with (read-event nil nil 1).

Post by martin rudalics
This is indeed a strange thing. Juanma, do we usually ignore this?

Definitely not. Try evaling this in emacs -Q:

(let* ((frame (make-frame '((visibility . icon))))
(set (frameset-save (list frame))))
(delete-frame frame)
(read-event nil nil 1)
(frameset-restore set :reuse-frames t))

J

[Robert Marshall]

Post by Juanma Barranquero

Post by martin rudalics
BTW, you
did check all four of Juanma's scenarios, that is also the ones without
the (sit-for 0)?

Instead of (sit-for 0), I'd suggest trying with (read-event nil nil 1).

Aha!! adding (read-event nil nil 1) to bug17046.el instead of the
sit-for replicates the bug - it looks ok on startup but when I move
the mouse into the frame I lose the decorations and the minibuffer!

This is with

(visibility . t)
and :force-onscreen nil

Robert

[martin rudalics]

Post by Robert Marshall
Aha!! adding (read-event nil nil 1) to bug17046.el instead of the
sit-for replicates the bug - it looks ok on startup but when I move
the mouse into the frame I lose the decorations and the minibuffer!
This is with
(visibility . t)
and :force-onscreen nil

This should give us something at last but I don't yet know what. Please
just post that bug17046.el here so we can strip it.

martin

[Robert Marshall]

Post by martin rudalics

Post by Robert Marshall
Aha!! adding (read-event nil nil 1) to bug17046.el instead of the
sit-for replicates the bug - it looks ok on startup but when I move
the mouse into the frame I lose the decorations and the minibuffer!
This is with
(visibility . t)
and :force-onscreen nil

This should give us something at last but I don't yet know what. Please
just post that bug17046.el here so we can strip it.

[martin rudalics]

File is attached, I hadn't seen this problem before my bzr update and
build of March 14th but I've just tried the same minimal startup with my
previous build of Dec 23 2013 (though as I'm running it from the bzr
pull area, it has the bzr updated el files) and I see the same problem.
I also get the bug with :force-onscreen set to t

Thanks. Do you get the bug with the attached bug17046-b.el?

martin

[Robert Marshall]

Post by martin rudalics

File is attached, I hadn't seen this problem before my bzr update and
build of March 14th but I've just tried the same minimal startup with my
previous build of Dec 23 2013 (though as I'm running it from the bzr
pull area, it has the bzr updated el files) and I see the same problem.
I also get the bug with :force-onscreen set to t

Thanks. Do you get the bug with the attached bug17046-b.el?

Yes - the frame appears ok until I move the mouse into the frame (I'm
using focus follows mouse) when the decorations & minibuffer vanish.

Robert

[Robert Marshall]

Post by martin rudalics

File is attached, I hadn't seen this problem before my bzr update and
build of March 14th but I've just tried the same minimal startup with my
previous build of Dec 23 2013 (though as I'm running it from the bzr
pull area, it has the bzr updated el files) and I see the same problem.
I also get the bug with :force-onscreen set to t

Thanks. Do you get the bug with the attached bug17046-b.el?

And I still get the problem when I comment out the 2 find-files and
replace the buffer names further down the file with *scratch* and *Messages* -
so avoiding the loading lots of cc* libraries

Robert

[martin rudalics]

Post by Robert Marshall
And I still get the problem when I comment out the 2 find-files and
replace the buffer names further down the file with *scratch* and *Messages* -
so avoiding the loading lots of cc* libraries

Fine. I wanted to ask you to do exactly that. I attach a more
radically stripped file now. If it works, that is if you still the
usual bad frame and no other bug is thrown, then try to comment out the
"font..." entries one by one.

martin

[martin rudalics]

BTW, if I follow my last suggestion here I get

Error (frameset): Wrong type argument: listp, vc

so you probably want to remove that entry too.

martin

[Robert Marshall]

Post by martin rudalics

Post by Robert Marshall
And I still get the problem when I comment out the 2 find-files and
replace the buffer names further down the file with *scratch* and *Messages* -
so avoiding the loading lots of cc* libraries

Fine. I wanted to ask you to do exactly that. I attach a more
radically stripped file now. If it works, that is if you still the
usual bad frame and no other bug is thrown, then try to comment out the
"font..." entries one by one.

With your attached file I get:

Error (frameset): Wrong type argument: listp, vc

but also see the frame going bad, and the bad frames continue when I
successively comment out these lines and restart ignoring the above error.

(;;(font-backend xft x)
;;(font . "-unknown-Inconsolata-normal-normal-normal-*-16-*-*-*-m-0-iso10646-1")
;; (font-parameter . "Inconsolata-12")

Robert

[martin rudalics]

Post by martin rudalics
Error (frameset): Wrong type argument: listp, vc
but also see the frame going bad, and the bad frames continue when I
successively comment out these lines and restart ignoring the above error.
(;;(font-backend xft x)
;;(font . "-unknown-Inconsolata-normal-normal-normal-*-16-*-*-*-m-0-iso10646-1")
;; (font-parameter . "Inconsolata-12")

OK. Apparently the "vc" is needed and most of the window entries too.
I attach the minimal file that works here as bug17046-c.el. Can you
confirm that the bug still occurs with that file?

martin

[martin rudalics]

And please try the attached single window frame too.

martin

[Robert Marshall]

Post by martin rudalics
And please try the attached single window frame too.

This also works ok (frame is ok) - but with the warning

Warning (frameset): Attempt to delete the sole visible or iconified frame

R

[Robert Marshall]

Post by martin rudalics

Post by martin rudalics
Error (frameset): Wrong type argument: listp, vc
but also see the frame going bad, and the bad frames continue when I
successively comment out these lines and restart ignoring the above error.
(;;(font-backend xft x)
;;(font . "-unknown-Inconsolata-normal-normal-normal-*-16-*-*-*-m-0-iso10646-1")
;; (font-parameter . "Inconsolata-12")

OK. Apparently the "vc" is needed and most of the window entries too.
I attach the minimal file that works here as bug17046-c.el. Can you
confirm that the bug still occurs with that file?

This file doesn't produce the bug for me - and it only displays one
window on startup (the *scratch* buffer)

Robert

[martin rudalics]

Post by Robert Marshall
This file doesn't produce the bug for me - and it only displays one
window on startup (the *scratch* buffer)

Which file: bug17046-c.el or bug17046-d.el? What about the other?
(I suppose you received my last message earlier so if this is about
bug17046-d.el then please wait until you tried with bug17046-c.el.)

martin

[Robert Marshall]

Post by martin rudalics

Post by Robert Marshall
This file doesn't produce the bug for me - and it only displays one
window on startup (the *scratch* buffer)

Which file: bug17046-c.el or bug17046-d.el? What about the other?
(I suppose you received my last message earlier so if this is about
bug17046-d.el then please wait until you tried with bug17046-c.el.)

Neither bug17046-c.el nor bug17046-d.el produce the buggy frame
and both only show one window on startup.

Robert

[Juanma Barranquero]

Post by Robert Marshall
Neither bug17046-c.el nor bug17046-d.el produce the buggy frame
and both only show one window on startup.

If you can reproduce it with *-b.el, which is quite short, please try
commenting out one by one some lines in the FRAME section (starting
with display, visibility and minibuffer, perhaps...).

[martin rudalics]

Post by Juanma Barranquero
If you can reproduce it with *-b.el, which is quite short, please try
commenting out one by one some lines in the FRAME section (starting
with display, visibility and minibuffer, perhaps...).

When in the last bug17046-e.el I posted I comment out (visibility . t),
the root window is not split on Debian. It is split on Windows.

martin

[martin rudalics]

Post by martin rudalics
When in the last bug17046-e.el I posted I comment out (visibility . t),
the root window is not split on Debian. It is split on Windows.

On Debian I get

Attempt to delete the sole visible or iconified frame

martin

[Robert Marshall]

Post by Juanma Barranquero

Post by Robert Marshall
Neither bug17046-c.el nor bug17046-d.el produce the buggy frame
and both only show one window on startup.

If you can reproduce it with *-b.el, which is quite short, please try
commenting out one by one some lines in the FRAME section (starting
with display, visibility and minibuffer, perhaps...).

I removed first the 3 font* lines - which we'd already seen made no
difference from bug17046-b.el - when I commented (display . ":0") that
made the difference and the amended file now displays the frame
correctly.

I tried commenting out the other 2 lines you suggested (each time just
that line commented) and in both cases the frame display was buggy.

The commenting 'display' version causes the frame to jump position to
the top LHS so I had to be careful to keep the mouse out of the way -
moving the mouse into the frame during startup appears to prevent the
bug appearing.

So I now have a version of that file with visibility and minibuffer
commented and display uncommented which still shows the bug.

Robert

[martin rudalics]

Post by Robert Marshall
Neither bug17046-c.el nor bug17046-d.el produce the buggy frame
and both only show one window on startup.

I just tried on Debian and noticed that frameset throws more errors than
Windows when `desktop-saved-frameset' is not entirely complete.
Attached bug17046-e.el is the minimum version that works on my Debian.
Please try this.

martin

[Robert Marshall]

Post by martin rudalics

Post by Robert Marshall
Neither bug17046-c.el nor bug17046-d.el produce the buggy frame
and both only show one window on startup.

I just tried on Debian and noticed that frameset throws more errors than
Windows when `desktop-saved-frameset' is not entirely complete.
Attached bug17046-e.el is the minimum version that works on my Debian.
Please try this.

Your bug17046-e.el also works (ie doesn't cause the bug) for me

Robert

[martin rudalics]

Post by Robert Marshall
Your bug17046-e.el also works (ie doesn't cause the bug) for me

Are you sure? Then we almost found it. You now have to only find the
decisive difference between the last bug17046-a.el or bug17046-b.el
version that caused the bug and bug17046-e.el. To do that please

(1) Make sure you found a version that produced the bug and did not
throw any other error.

(2)

[Robert Marshall]

Post by martin rudalics

Post by Robert Marshall
Your bug17046-e.el also works (ie doesn't cause the bug) for me

Are you sure? Then we almost found it. You now have to only find the
decisive difference between the last bug17046-a.el or bug17046-b.el
version that caused the bug and bug17046-e.el. To do that please
(1) Make sure you found a version that produced the bug and did not
throw any other error.

[martin rudalics]

I thought that was the (display . ":0")
line (as in my response to Juanma)?

Ahh... I didn't have that message yet. What does

(frame-parameter nil 'display)

give in a normal emacs -Q session? And what gives

(getenv "DISPLAY")

in such a session?

martin

[Robert Marshall]

Post by martin rudalics

I thought that was the (display . ":0")
line (as in my response to Juanma)?

Ahh... I didn't have that message yet. What does
(frame-parameter nil 'display)

":0"

Post by martin rudalics
give in a normal emacs -Q session? And what gives
(getenv "DISPLAY")

":0" again

Post by martin rudalics
in such a session?

looks to be consistent

Robert

[Juanma Barranquero]

I thought that was the (display . ":0")
line (as in my response to Juanma)?

Shouldn't affect, but just in case...

Could you please retry with the same bug*.el that reproduces the bug, but adding

:force-display t

to the frameset-restore call?

[Robert Marshall]

Post by Juanma Barranquero

I thought that was the (display . ":0")
line (as in my response to Juanma)?

Shouldn't affect, but just in case...
Could you please retry with the same bug*.el that reproduces the bug, but adding
:force-display t
to the frameset-restore call?

The bug still appears with both the (display... line being present and
:force-display t

However if I comment out the (display line but *leave in* the
:force-display t parameter - the bug is still present - so in this case
:force-display provokes the bug - it would have been ok without that
line.

Robert

[Juanma Barranquero]

Post by Robert Marshall
However if I comment out the (display line but *leave in* the
:force-display t parameter - the bug is still present - so in this case
:force-display provokes the bug - it would have been ok without that
line.

Please try this:

- edit lisp/frameset.el, and in line 1149, change

(eq (frame-parameter nil 'display)

to

(equal (frame-parameter nil 'display)

save, compile frameset.el, and try again.

J

[Robert Marshall]

Post by Juanma Barranquero

Post by Robert Marshall
However if I comment out the (display line but *leave in* the
:force-display t parameter - the bug is still present - so in this case
:force-display provokes the bug - it would have been ok without that
line.

- edit lisp/frameset.el, and in line 1149, change
(eq (frame-parameter nil 'display)
to
(equal (frame-parameter nil 'display)

=== modified file 'lisp/frameset.el'
*** lisp/frameset.el 2014-03-12 18:36:26 +0000
--- lisp/frameset.el 2014-03-23 20:51:56 +0000
***************
*** 1146,1152 ****
frame to-tty duplicate)
;; Only set target if forcing displays and the target display is different.
(unless (or (frameset-keep-original-display-p force-display)
! (eq (frame-parameter nil 'display)
(cdr (assq 'display frame-cfg))))
(setq frameset--target-display (cons 'display
(frame-parameter nil 'display))
--- 1146,1152 ----
frame to-tty duplicate)
;; Only set target if forcing displays and the target display is different.
(unless (or (frameset-keep-original-display-p force-display)
! (equal (frame-parameter nil 'display)
(cdr (assq 'display frame-cfg))))
(setq frameset--target-display (cons 'display
(frame-parameter nil 'display))

Post by Juanma Barranquero
save, compile frameset.el, and try again.

and saved and compiled but the bug is still present (tried with both
the display parameter and :force-display - uncommenting them separately).
So I can't see any change in behaviour.

Robert

[Juanma Barranquero]

Post by Robert Marshall
and saved and compiled but the bug is still present (tried with both
the display parameter and :force-display - uncommenting them separately).
So I can't see any change in behaviour.

Aha. Well, it was a long shot. The change I suggested fixes a real
bug, whose consequence is to make frameset-restore to force the
current display onto the restored frames; but in you case, the
restored frame's display and the current frame's display are
identical, so forcing it shouldn't change anything, and it doesn't.

J

[Juanma Barranquero]

Could you please post the exact .el file you're using to reproduce the bug?

Thanks,

J

[Robert Marshall]

Post by Juanma Barranquero
Could you please post the exact .el file you're using to reproduce the bug?

Here it is

[Juanma Barranquero]

Please try the attached bug17046-b.el. It's the same you sent me, plus
some code at the start.

I need to see the content of *Messages* in the two cases (with and without bug).

Thanks,

J

[Robert Marshall]

Post by Juanma Barranquero
Please try the attached bug17046-b.el. It's the same you sent me, plus
some code at the start.
I need to see the content of *Messages* in the two cases (with and without bug).

With bug:

#<frame ***@poulenc 0x8725ae0> was :reused
filtered-cfg: ((tool-bar-lines . 0) (width . 120) (height . 30) (display . ":0") (visibility . t) (minibuffer . t) (frameset--mini t . t) (frameset--id . "DA9D-E03E-DF32-EAB7"))
alt-cfg: nil

Without bug:

#<frame ***@poulenc 0x9c6c040> was :created
filtered-cfg: ((tool-bar-lines . 0) (width . 120) (height . 30) (visibility . t) (minibuffer . t) (frameset--mini t . t) (frameset--id . "DA9D-E03E-DF32-EAB7"))
alt-cfg: nil

R

[Juanma Barranquero]

Do you see any problem if, from emacs -Q, you evaluate the following
code in *scratch*?

(let ((frame (make-frame)))
(discard-input)
(read-event nil nil 1)
(modify-frame-parameters frame '((tool-bar-lines . 0)
(width . 120)
(height . 30)
(display . ":0")
(visibility . t)
(minibuffer . t))))

[Juanma Barranquero]

Please, try this too:

(let ((frame (make-frame-on-display ":0" '((visibility . nil)))))
(discard-input)
(read-event nil nil 1)
(modify-frame-parameters frame '((tool-bar-lines . 0)
(width . 120)
(height . 30)
(display . ":0")
(visibility . t)
(minibuffer . t))))

[Robert Marshall]

Post by martin rudalics

Post by Robert Marshall
This does produce 2 windows but in no case is there a sign of the
problem - or is that what you are expecting?

I did. If you now ask yourself why I wanted you to try that, then it's
because I wanted to try with the more simple approaches first. BTW, you
did check all four of Juanma's scenarios, that is also the ones without
the (sit-for 0)?

Yes I tried all 4

Post by martin rudalics

Post by Robert Marshall
I wondered about the
(visibility . icon)
line (I don't think I ever started it up iconized) and tried the tests
both with and without it with the same result.

This is indeed a strange thing. Juanma, do we usually ignore this?

Post by Robert Marshall
If I don't include the 2 find-files I get a single window onto *Messages*
Not sure whether it is relevant - or you've already assumed this
- there's no resize facility on the bad frame (apart from maximize) move
the mouse to the window corner and no resize arrows appear.

It is yet another mysterious detail. Please post now your entire
.emacs.desktop file here, that is the one that you use to produce the
bad frame in the new session. I'll then try to tell you what to remove
from that file in order to narrow down the possible culprits.

Can you confirm that the desktop being used to load is (by default)
the one in $HOME (if it exists) and not any in the current directory
(I saw it writing the desktop to ~/ just wanted to be sure it read
from there too as I'd squirreled one away in ~/tmp which is where I
was running the tests from)

Are you sure? My desktop file contains 266 calls to
desktop-create-buffer - (slight diversion/scare here[1] ) Can I make it
available via the web or do you want it in the body of the bug thread?

Is there any trimming down I can try first - removal of buffers in
same mode with same minor modes?

Post by martin rudalics
And thanks for bearing with me, martin

Thanks for your efforts!

Robert
[1] it looks as if it has been overwritten? I've got another emacs
session (where I'm typing this) but as I haven't closed any buffers it
should be the same (or re-ordered), I thought .emacs.desktop was only
written on exit - it looks as if the desktop-auto-save is the new
default. Looks like I'm going to have to verify .... yes it's still
bad - and now saved elsewhere!

[Juanma Barranquero]

Post by Robert Marshall
Can you confirm that the desktop being used to load is (by default)
the one in $HOME (if it exists) and not any in the current directory
(I saw it writing the desktop to ~/ just wanted to be sure it read
from there too as I'd squirreled one away in ~/tmp which is where I
was running the tests from)

Variable desktop-path shows the list of directories to search for the
dektop file, and desktop-dirname tells where will the desktop be
saved.

J

[Robert Marshall]

Post by Juanma Barranquero
I'm a bit lost here. What do you need from me?

Post by martin rudalics
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.

1) Put Emacs in the maximized state, or whatever is that is giving
trouble (just one frame).

OK I've managed to get a bad frame here, no window decorations but
there is a minibuffer visible (and not maximised)

Post by Juanma Barranquero
2) Exit Emacs (saving the desktop)
3) Copy the "(setq desktop-saved-frameset ...)" line from .emacs.desktop
4) emacs -Q
5) paste the (setq desktop-saved-frameset ...) sexp into *scratch* and eval it
(frameset-restore desktop-saved-frameset
:reuse-frames t
:cleanup-frames t
:force-onscreen t)
Then, repeat from 4) on, with the same desktop-saved-frameset value as
before, but call frameset-restore with :force-onscreen nil (or without
that line, nil is the default).

I did all those (2,3 then 4-6) -the desktop-saved-frameset referenced buffers that
didn't exist - is that correct or should I have loaded them before
evaling the desktop-saved-frameset?

Then repeated (4-6) with :force-onscreen now nil

Post by Juanma Barranquero
Assuming that the problem reappears doing that, at least we have a
frameset that causes it, and then we can look into it and try to
understand what happens.

In neither case did the problem appear. What I am seeing on emacs -Q is

Ignoring unknown mode `16-mode'
Ignoring unknown mode `16-*-*-mode'

in *messages* - is this benign? They don't appear with -Q --no-site-file
but *info* says that -Q covers --no-site-file?

Robert

[Juanma Barranquero]

Post by Robert Marshall
Ignoring unknown mode `16-mode'
Ignoring unknown mode `16-*-*-mode'

That's part of the font name. How the #$%&! did that get interpreted as a mode?

J

[Robert Marshall]

[those who have already seen this re-sending of an email from Friday
may ignore it! - I'm re-sending because it got blocked from the bug-gnu-emacs
list because of the excessively large attachment]

Post by martin rudalics
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
(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 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).

The attachment can be viewed here:

Loading Image...;att=1;bug=17046


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?

Post by martin rudalics
(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)

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.
The problem only seems to occur when the frame is trying to show 2
buffers?


Robert

[Juanma Barranquero]

Post by Robert Marshall
On starting emacs with desktop enabled the frame appears normal until
loading is complete when the window title/ iconize button etc disappears
together with the minibuffer. I have a screenshot of the frame (if
needed for clarity)

If you start Emacs with

(setq desktop-restore-frames nil)
(desktop-mode 1)

does still happen? (Perhaps desktop is restoring a frame with some
weird parameters...)

[Robert Marshall]

Post by Juanma Barranquero

Post by Robert Marshall
On starting emacs with desktop enabled the frame appears normal until
loading is complete when the window title/ iconize button etc disappears
together with the minibuffer. I have a screenshot of the frame (if
needed for clarity)

If you start Emacs with
(setq desktop-restore-frames nil)
(desktop-mode 1)
does still happen? (Perhaps desktop is restoring a frame with some
weird parameters...)

Yes that solves the problem - (assuming you meant (desktop-save-mode 1) )
- there only though appeared to be one frame when the faulty
restore happened - and the problem occurred more than once - in both
cases I was exiting (and implicitly saving the desktop) when only
one frame was open (at least as far as I could see!).

Robert

[Juanma Barranquero]

Post by Robert Marshall
Yes that solves the problem - (assuming you meant (desktop-save-mode 1) )

Yes, desktop-save-mode.

Please edit your .emacs.desktop file and remove the assignment to
desktop-saved-frameset in the "Global Section". Then reenable
desktop-restore-frames in your .emacs and let's see if the issue does
reappear. If it does, I'd suggest posting the contents of
desktop-saved-frameset (from the desktop file).

[Robert Marshall]

Post by Juanma Barranquero

Post by Robert Marshall
Yes that solves the problem - (assuming you meant (desktop-save-mode 1) )

Yes, desktop-save-mode.
Please edit your .emacs.desktop file and remove the assignment to
desktop-saved-frameset in the "Global Section". Then reenable
desktop-restore-frames in your .emacs and let's see if the issue does
reappear. If it does, I'd suggest posting the contents of
desktop-saved-frameset (from the desktop file).

I carried out the above and the issue does not reappear (I tried
maximise and unmaximise a couple of times just to check) so I'm
assuming you meant that the contents of desktop-saved-frameset was the
problem which I include below - unless my suggest in my contribution
to this bug report with the screenshot is correct and it's a kde/gtk
issue.

(setq desktop-saved-frameset [frameset 1 (21291 2634 754550 483000) (desktop . "206") "***@poulenc" nil nil ((((font-backend xft x) (font-parameter . "Inconsolata-12") (font . "-unknown-Inconsolata-normal-normal-normal-*-16-*-*-*-m-0-iso10646-1") (border-width . 0) (internal-border-width . 0) (right-divider-width . 0) (bottom-divider-width . 0) (vertical-scroll-bars . right) (foreground-color . "DarkOrchid1") (background-color . "mint cream") (mouse-color . "#221f1e") (border-color . "black") (screen-gamma) (line-spacing) (left-fringe . 8) (right-fringe . 8) (scroll-bar-foreground . "#221f1e") (scroll-bar-background . "grey75") (menu-bar-lines . 1) (tool-bar-lines . 1) (title) (wait-for-wm . t) (fullscreen) (tool-bar-position . top) (icon-type . t) (auto-raise) (auto-lower) (cursor-type . box) (scroll-bar-width . 16) (alpha . 90) (display-type . color) (background-mode . light) (cursor-color . "#221f1e") (visibility . t) (sticky) (frameset--id . "FB69-CBB8-3217-A8F7") (frameset--mini t) (modeline . t) (minibuffer . t) (unsplittable) (icon-name) (display . ":0") (explicit-name) (height . 35) (width . 80) (left . 764) (top . 364)) ((min-height . 4) (min-width . 10) (min-height-ignore . 2) (min-width-ignore . 6) (min-height-safe . 1) (min-width-safe . 2) (min-pixel-height . 72) (min-pixel-width . 80) (min-pixel-height-ignore . 36) (min-pixel-width-ignore . 48) (min-pixel-height-safe . 18) (min-pixel-width-safe . 16)) leaf (pixel-width . 672) (pixel-height . 612) (total-width . 84) (total-height . 0) (normal-height . 1.0) (normal-width . 1.0) (buffer "*scratch*" (selected . t) (hscroll . 0) (fringes 8 8 nil) (margins nil) (scroll-bars 16 2 t nil) (vscroll . 0) (dedicated) (point . 225) (start . 1))) (((font-backend xft x) (font . "-unknown-Inconsolata-normal-normal-normal-*-16-*-*-*-m-0-iso10646-1") (font-parameter . "Inconsolata-12") (border-width . 0) (internal-border-width . 0) (right-divider-width . 0) (bottom-divider-width . 0) (vertical-scroll-bars . right) (foreground-color . "DarkOrchid1") (background-color . "mint cream") (mouse-color . "#221f1e") (border-color . "black") (screen-gamma) (line-spacing) (left-fringe . 8) (right-fringe . 8) (scroll-bar-foreground . "#221f1e") (scroll-bar-background . "grey75") (menu-bar-lines . 1) (tool-bar-lines . 1) (title) (wait-for-wm . t) (fullscreen) (tool-bar-position . top) (icon-type . t) (auto-raise) (auto-lower) (cursor-type . box) (scroll-bar-width . 16) (alpha . 90) (horizontal-scroll-bars . t) (display-type . color) (background-mode . light) (cursor-color . "#221f1e") (sticky) (environment) (frameset--id . "293F-FDD1-DD37-022D") (frameset--mini t . t) (modeline . t) (minibuffer . t) (unsplittable) (icon-name) (visibility . t) (display . ":0") (explicit-name) (height . 33) (width . 120) (left . 1136) (top . 95)) ((min-height . 4) (min-width . 10) (min-height-ignore . 2) (min-width-ignore . 6) (min-height-safe . 1) (min-width-safe . 2) (min-pixel-height . 72) (min-pixel-width . 80) (min-pixel-height-ignore . 36) (min-pixel-width-ignore . 48) (min-pixel-height-safe . 18) (min-pixel-width-safe . 16)) leaf (pixel-width . 992) (pixel-height . 576) (total-width . 124) (total-height . 32) (normal-height . 1.0) (normal-width . 1.0) (buffer "*Messages*" (selected) (hscroll . 0) (fringes 8 8 nil) (margins nil) (scroll-bars 16 2 t nil) (vscroll . 0) (dedicated) (point . 2629) (start . 1917))))])

Robert
--

[Juanma Barranquero]

Post by Robert Marshall
I carried out the above and the issue does not reappear (I tried
maximise and unmaximise a couple of times just to check)

So the bug is gone and we can close this bug?

Post by Robert Marshall
so I'm
assuming you meant that the contents of desktop-saved-frameset was the
problem

It is possible that a frame in some weird state was saved, and from
that moment on, exiting/entering Emacs with desktop-mode enabled would
try to reproduce that weird frame (or window) state from the saved
frameset.

The frameset dump you sent includes two frames. It is the one that was
giving you trouble? At a cursory look, I don't see anything obviously
wrong with the frames. Martin, do you see something questionable in
the window trees?


[frameset
1
(21291 2634 754550 483000)
(desktop . "206")
"***@poulenc"
nil
nil
((;; ********** FRAME 1
((font-backend xft x)
(font-parameter . "Inconsolata-12")
(font . "-unknown-Inconsolata-normal-normal-normal-*-16-*-*-*-m-0-iso10646-1")
(border-width . 0)
(internal-border-width . 0)
(right-divider-width . 0)
(bottom-divider-width . 0)
(vertical-scroll-bars . right)
(foreground-color . "DarkOrchid1")
(background-color . "mint cream")
(mouse-color . "#221f1e")
(border-color . "black")
(screen-gamma)
(line-spacing)
(left-fringe . 8)
(right-fringe . 8)
(scroll-bar-foreground . "#221f1e")
(scroll-bar-background . "grey75")
(menu-bar-lines . 1)
(tool-bar-lines . 1)
(title)
(wait-for-wm . t)
(fullscreen)
(tool-bar-position . top)
(icon-type . t)
(auto-raise)
(auto-lower)
(cursor-type . box)
(scroll-bar-width . 16)
(alpha . 90)
(display-type . color)
(background-mode . light)
(cursor-color . "#221f1e")
(visibility . t)
(sticky)
(frameset--id . "FB69-CBB8-3217-A8F7")
(frameset--mini t)
(modeline . t)
(minibuffer . t)
(unsplittable)
(icon-name)
(display . ":0")
(explicit-name)
(height . 35)
(width . 80)
(left . 764)
(top . 364))
;; ********** WINDOW TREE 1
((min-height . 4)
(min-width . 10)
(min-height-ignore . 2)
(min-width-ignore . 6)
(min-height-safe . 1)
(min-width-safe . 2)
(min-pixel-height . 72)
(min-pixel-width . 80)
(min-pixel-height-ignore . 36)
(min-pixel-width-ignore . 48)
(min-pixel-height-safe . 18)
(min-pixel-width-safe . 16))
leaf
(pixel-width . 672)
(pixel-height . 612)
(total-width . 84)
(total-height . 0)
(normal-height . 1.0)
(normal-width . 1.0)
(buffer "*scratch*" (selected . t)
(hscroll . 0)
(fringes 8 8 nil)
(margins nil)
(scroll-bars 16 2 . t nil)
(vscroll . 0)
(dedicated)
(point . 225)
(start . 1)))
(;; ********** FRAME 2
((font-backend xft x)
(font . "-unknown-Inconsolata-normal-normal-normal-*-16-*-*-*-m-0-iso10646-1")
(font-parameter . "Inconsolata-12")
(border-width . 0)
(internal-border-width . 0)
(right-divider-width . 0)
(bottom-divider-width . 0)
(vertical-scroll-bars . right)
(foreground-color . "DarkOrchid1")
(background-color . "mint . cream")
(mouse-color . "#221f1e")
(border-color . "black")
(screen-gamma)
(line-spacing)
(left-fringe . 8)
(right-fringe . 8)
(scroll-bar-foreground . "#221f1e")
(scroll-bar-background . "grey75")
(menu-bar-lines . 1)
(tool-bar-lines . 1)
(title)
(wait-for-wm . t)
(fullscreen)
(tool-bar-position . top)
(icon-type . t)
(auto-raise)
(auto-lower)
(cursor-type . box)
(scroll-bar-width . 16)
(alpha . 90)
(horizontal-scroll-bars . t)
(display-type . color)
(background-mode . light)
(cursor-color . "#221f1e")
(sticky)
(environment)
(frameset--id . "293F-FDD1-DD37-022D")
(frameset--mini t . t)
(modeline . t)
(minibuffer . t)
(unsplittable)
(icon-name)
(visibility . t)
(display . ":0")
(explicit-name)
(height . 33)
(width . 120)
(left . 1136)
(top . 95))
;; ********** WINDOW TREE 2
((min-height . 4)
(min-width . 10)
(min-height-ignore . 2)
(min-width-ignore . 6)
(min-height-safe . 1)
(min-width-safe . 2)
(min-pixel-height . 72)
(min-pixel-width . 80)
(min-pixel-height-ignore . 36)
(min-pixel-width-ignore . 48)
(min-pixel-height-safe . 18)
(min-pixel-width-safe . 16))
leaf
(pixel-width . 992)
(pixel-height . 576)
(total-width . 124)
(total-height . 32)
(normal-height . 1.0)
(normal-width . 1.0)
(buffer "*Messages*" (selected)
(hscroll . 0)
(fringes 8 8 nil)
(margins nil)
(scroll-bars 16 2 . t nil)
(vscroll . 0)
(dedicated)
(point . 2629)
(start . 1917))))]

[martin rudalics]

Post by Juanma Barranquero
Martin, do you see something questionable in
the window trees?

I see two issues:

FRAME 1

Post by Juanma Barranquero
(frameset--mini t)

...

Post by Juanma Barranquero
(height . 35)

...

Post by Juanma Barranquero
(total-height . 0)

FRAME 2

Post by Juanma Barranquero
(frameset--mini t . t)

...

Post by Juanma Barranquero
(height . 33)

...

Post by Juanma Barranquero
(total-height . 32)

Obviously a total-height of 0 for FRAME 1 is broken - it should look
like for FRAME 2. Just that a total height of zero shouldn't have any
bad consequences - it would get swallowed by `split-window'. And the
differences in frameset--mini, are they OK?

martin

[Juanma Barranquero]

Post by martin rudalics
Obviously a total-height of 0 for FRAME 1 is broken - it should look
like for FRAME 2. Just that a total height of zero shouldn't have any
bad consequences - it would get swallowed by `split-window'.

I checked, and it doesn't cause any trouble when restoring.

Post by martin rudalics
And the
differences in frameset--mini, are they OK?

Post by Robert Marshall
(frameset--mini t)
(frameset--mini t . t)

Yes. The first t means that the frames have their own minibuffer. The
second t means that that frame's minibuffer was the one pointed out by
the `default-minibuffer-frame' variable. When restoring,
default-minibuffer-frame will be set to that frame, but that would
only affect new minibufferless frames, so it doesn't seem to have any
influence in the reported bug.

J

[martin rudalics]

Post by Juanma Barranquero

Post by martin rudalics
Obviously a total-height of 0 for FRAME 1 is broken - it should look
like for FRAME 2. Just that a total height of zero shouldn't have any
bad consequences - it would get swallowed by `split-window'.

I checked, and it doesn't cause any trouble when restoring.

I wonder how this 0 crept in tho. The pixel-height is completely
normal.

BTW, how do you handle maximization and fullscreen, I'm too lazy to look
at the code. Do you handle the 'maximized frame parameter?

martin

[Juanma Barranquero]

Post by martin rudalics
Do you handle the 'maximized frame parameter?

As far as I can see, fullboth and maximized are preserved (ie. a
fullboth frame is restored as fullboth, and a maximized one is
restored as maximized).

J

[martin rudalics]

Post by Juanma Barranquero

Post by martin rudalics
Do you handle the 'maximized frame parameter?

As far as I can see, fullboth and maximized are preserved (ie. a
fullboth frame is restored as fullboth, and a maximized one is
restored as maximized).

But what about a frame that has both parameters set - fullscreen and
maximized? IIUC a fullscreen/fullboth and maximized/maximized one will
become fullboth and de-fullscreenifying it will make it normal. Right?

martin

[Juanma Barranquero]

Post by martin rudalics
But what about a frame that has both parameters set - fullscreen and
maximized? IIUC a fullscreen/fullboth and maximized/maximized one will
become fullboth and de-fullscreenifying it will make it normal. Right?

Now you got me. What's that "maximized" parameter? I've never seen it.
The docs only talk about having (fullscreen . maximized).

[martin rudalics]

Post by Juanma Barranquero
Now you got me. What's that "maximized" parameter? I've never seen it.
The docs only talk about having (fullscreen . maximized).

IIUC it's a kludge Eli introduced on w32 to handle the case where we
toggle via F11 from a maximized to a fullscreen frame and via another
F11 back to the maximized (instead of a normal) one. So you should see
the `maximized' parameter after you applied F11 to a maximized frame.

I have understood the idea but not yet whether it works in all cases.
And I suppose it should not concern desktop.

martin

[Juanma Barranquero]

Post by martin rudalics
IIUC it's a kludge Eli introduced on w32 to handle the case where we
toggle via F11 from a maximized to a fullscreen frame and via another
F11 back to the maximized (instead of a normal) one. So you should see
the `maximized' parameter after you applied F11 to a maximized frame.

But it is a w32-specific hack? Because Robert's frameset contains
(maximized), but he's on Ubuntu.

J

[martin rudalics]

Post by Juanma Barranquero
But it is a w32-specific hack?

Yes.

Post by Juanma Barranquero
Because Robert's frameset contains
(maximized), but he's on Ubuntu.

My BTW referred to the Windows version only ;-)

martin

[Eli Zaretskii]

Date: Sat, 22 Mar 2014 14:45:01 +0100

Post by Juanma Barranquero
Now you got me. What's that "maximized" parameter? I've never seen it.
The docs only talk about having (fullscreen . maximized).

IIUC it's a kludge Eli introduced on w32

I did? There's not a single line of my code in w32term.c, under
SIZE_MAXIMIZED, where this parameter is used. That code was added by
your revision 115301, AFAICS.

Perhaps you mean the FULLSCREEN_MAXIMIZED value of the
f->want_fullscreen slot. But that isn't my invention, either, nor is
it w32-specific.

[martin rudalics]

Post by Eli Zaretskii

Post by martin rudalics
IIUC it's a kludge Eli introduced on w32

I did? There's not a single line of my code in w32term.c, under
SIZE_MAXIMIZED, where this parameter is used. That code was added by
your revision 115301, AFAICS.

Sorry. I forgot.

Post by Eli Zaretskii
Perhaps you mean the FULLSCREEN_MAXIMIZED value of the
f->want_fullscreen slot. But that isn't my invention, either, nor is
it w32-specific.

No. That one is about what should be done. The one I referred to is
about what should be restored when we toggle fullscreen mode off - a
maximized or a normal window.

martin

[Stefan]

Post by martin rudalics
But what about a frame that has both parameters set - fullscreen and
maximized? IIUC a fullscreen/fullboth and maximized/maximized one will
become fullboth and de-fullscreenifying it will make it normal. Right?

Having both is an error.
We should have only one parameter. It's too late to fix it 24.4, but we
should fix it for 24.5.

I think this parameter should be called `maximized' with values:

nil
width
height
t
fullscreen

Is there some situation that is not covered by the above?


Stefan

[martin rudalics]

Post by Stefan
Having both is an error.
We should have only one parameter. It's too late to fix it 24.4, but we
should fix it for 24.5.
nil
width
height
t
fullscreen
Is there some situation that is not covered by the above?

Yes. On GNU/Linux maximize your frame, then type F11 twice. What you
get is a maximized frame. I presume this is the desired behavior. To
get the same behavior on Windows you have to remember the state before
typing F11 the first time.

Note that F11 is not covered by the Windows API. It's the application
that calculates the sizes and asks Windows to apply them, but as far as
Windows is concerned, a fullscreen is just the same as a normal window.
Now when we leave fullscreen mode we must somehow know whether to
restore to a maximized or a normal frame. That's what the `maximized'
parameter is for - it remembers the previous state.

martin