GNU bug report logs -
#17046
24.3.50; On startup emacs frame has no minibuffer or windows decorations
Previous Next
Reported by: Robert Marshall <robert <at> capuchin.co.uk>
Date: Thu, 20 Mar 2014 09:09:02 UTC
Severity: important
Found in version 24.3.50
Fixed in version 24.4
Done: Juanma Barranquero <lekktu <at> gmail.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 17046 in the body.
You can then email your comments to 17046 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Thu, 20 Mar 2014 09:09:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Robert Marshall <robert <at> capuchin.co.uk>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Thu, 20 Mar 2014 09:09:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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 rudalics <at> 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)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Thu, 20 Mar 2014 09:54:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 17046 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Thu, 20 Mar 2014 12:23:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 17046 <at> debbugs.gnu.org (full text, mbox):
martin rudalics writes:
> > 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
--
Robert Marshall
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Thu, 20 Mar 2014 12:25:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 17046 <at> debbugs.gnu.org (full text, mbox):
On Thu, Mar 20, 2014 at 10:08 AM, Robert Marshall <robert <at> capuchin.co.uk> wrote:
> 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...)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Thu, 20 Mar 2014 12:58:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 17046 <at> debbugs.gnu.org (full text, mbox):
Juanma Barranquero writes:
> On Thu, Mar 20, 2014 at 10:08 AM, Robert Marshall <robert <at> capuchin.co.uk> wrote:
> > 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
--
Robert Marshall
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Thu, 20 Mar 2014 13:09:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 17046 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Thu, 20 Mar 2014 14:03:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 17046 <at> debbugs.gnu.org (full text, mbox):
On Thu, Mar 20, 2014 at 1:57 PM, Robert Marshall <robert <at> capuchin.co.uk> wrote:
> 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).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Thu, 20 Mar 2014 14:29:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 17046 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
martin rudalics writes:
>
> 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!
> 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
>
> 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
[emacs-sshot.png (image/png, inline)]
[Message part 3 (text/plain, inline)]
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)
> 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! 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?
Robert
--
Robert Marshall
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Thu, 20 Mar 2014 16:33:03 GMT)
Full text and
rfc822 format available.
Message #29 received at 17046 <at> debbugs.gnu.org (full text, mbox):
Juanma Barranquero writes:
> On Thu, Mar 20, 2014 at 1:57 PM, Robert Marshall <robert <at> capuchin.co.uk> wrote:
>
> > 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") "robert <at> 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
--
Robert Marshall
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Thu, 20 Mar 2014 16:55:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 17046 <at> debbugs.gnu.org (full text, mbox):
On Thu, Mar 20, 2014 at 5:32 PM, Robert Marshall <robert <at> capuchin.co.uk> wrote:
> 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?
> 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")
"robert <at> 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))))]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Thu, 20 Mar 2014 19:24:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 17046 <at> debbugs.gnu.org (full text, mbox):
> > 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.
> (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.
> 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)
>
>
> > 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?
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Thu, 20 Mar 2014 19:25:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 17046 <at> debbugs.gnu.org (full text, mbox):
> Martin, do you see something questionable in
> the window trees?
I see two issues:
FRAME 1
> (frameset--mini t)
...
> (height . 35)
...
> (total-height . 0)
FRAME 2
> (frameset--mini t . t)
...
> (height . 33)
...
> (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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Thu, 20 Mar 2014 20:25:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 17046 <at> debbugs.gnu.org (full text, mbox):
On Thu, Mar 20, 2014 at 8:24 PM, martin rudalics <rudalics <at> gmx.at> wrote:
> 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.
> And the
> differences in frameset--mini, are they OK?
>> (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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Thu, 20 Mar 2014 20:26:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 17046 <at> debbugs.gnu.org (full text, mbox):
martin rudalics writes:
> 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.
> > 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)
> >
> >
> > > 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") "robert <at> 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://rmstar.blogspot.com/
Robert Marshall
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Thu, 20 Mar 2014 20:39:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 17046 <at> debbugs.gnu.org (full text, mbox):
On Thu, Mar 20, 2014 at 9:25 PM, Robert Marshall <robert <at> capuchin.co.uk> wrote:
> 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")
"robert <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Thu, 20 Mar 2014 20:52:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 17046 <at> debbugs.gnu.org (full text, mbox):
Juanma Barranquero writes:
>
> 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
--
Robert Marshall
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Thu, 20 Mar 2014 21:01:01 GMT)
Full text and
rfc822 format available.
Message #53 received at 17046 <at> debbugs.gnu.org (full text, mbox):
On Thu, Mar 20, 2014 at 9:51 PM, Robert Marshall <robert <at> capuchin.co.uk> wrote:
> Me2! Do you want me also to start with an empty .emacs.desktop file?
With no desktop file, yes.
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Fri, 21 Mar 2014 08:03:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 17046 <at> debbugs.gnu.org (full text, mbox):
>> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Fri, 21 Mar 2014 08:03:04 GMT)
Full text and
rfc822 format available.
Message #59 received at 17046 <at> debbugs.gnu.org (full text, mbox):
> [frameset
> 1
> (21291 19570 712781 440000)
> (desktop . "206")
> "robert <at> poulenc" nil nil
> ((;; ********** FRAME 1
> (total-height . 29)
...
> (total-height . 15)
...
> (total-height . 14)
A frame with a 15 lines window above and a 14 lines window below. Looks
normal to me.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Fri, 21 Mar 2014 08:04:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 17046 <at> debbugs.gnu.org (full text, mbox):
> 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.
> > 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)
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Fri, 21 Mar 2014 10:58:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 17046 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
martin rudalics writes:
> Once more (I'm confused): What I wanted you to try is to get that bad
> frame (the one without title decoration and without minibuffer) back on
> screen. Let's call this the "bad base state". Now please in that state
> do:
>
> (1) Apply your window manager's key shortcut to maximize it and then the
> shortcut to restore its normal size. Do title bar or minibuffer
> come back?
No both in the 'maximized' state and on restored the window is exactly
the same (though in a different position relative to the rest of the
screen). The one difference is that the emacs frame which was
originally showing two windows 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).
[maxim.png (image/png, inline)]
[Message part 3 (text/plain, inline)]
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?
>
> (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
--
Robert Marshall
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Fri, 21 Mar 2014 15:08:01 GMT)
Full text and
rfc822 format available.
Message #68 received at 17046 <at> debbugs.gnu.org (full text, mbox):
> > Once more (I'm confused): What I wanted you to try is to get that bad
> > frame (the one without title decoration and without minibuffer) back on
> > screen. Let's call this the "bad base state". Now please in that state
> > do:
> >
> > (1) Apply your window manager's key shortcut to maximize it and then the
> > shortcut to restore its normal size. Do title bar or minibuffer
> > come back?
>
> No both in the 'maximized' state and on restored the window is exactly
> the same (though in a different position relative to the rest of the
> screen). The one difference is that the emacs frame which was
> originally showing two windows
Do you mean the "bad base state" frame was showing two windows before
maximization? Or do you mean the frame whose state was saved and should
have been restored was showing two windows? Or does the "second window"
refer to the minibuffer window?
> now only shows one window. I'm
> including a screenshot of the maximised state. Other applications
> maximise as expected - as does emacs when the desktop isn't loaded.
> (I commented in a previous message that maximise isn't working
> properly when the frame is in this state).
You mean it simply does not maximize, as can be seen on the screenshot.
Are the three buttons (minimize, maximize, delete) on the right of the
toolbar something you've seen before on your system? I don't see them
on the screenshot you sent earlier. What happens when you click on
them? Finally, there are no scroll bars and no right fringes on this
frame which probably count as more bugs.
> Is the maximise state happening but the border is only giving a
> partial window and the other buffer is there but the frame cuts off
> visibility?
The frame dump you sent earlier indicates that the Emacs frame/window
handling code considers everything in order. This means that the bug
happens either in the communcation between window manager and Emacs or
that Emacs doesn't redraw the frame orderly. But all this is dwarfed by
the fact that there's no title line and the strange buttons on the right
of the frame.
> > (2) In the bad base state type F11. Does anything change? Type F11
> > again. Does anything change this time?
>
> Exactly the same behaviour as in case (1)
Remarkable. One clue less for the disappearance of the title line.
> I exited the bad state emacs but with only one window shown in the
> frame and then restarted emacs and the frame was displayed correctly!
> I then displayed another buffer in a second window in that frame and
> exited again. On a restart the problem was back.
I can only assure you that yours is the strangest behavior I've seen
over the past year.
> The problem only seems to occur when the frame is trying to show 2
> buffers?
OK. I'm happy that the problem is reliably repeatable. So please
proceed as follows:
(1) In the frame whose state you save, just before exiting it, do
`window--dump-frame' and post the contents of the *window-frame-dump*
buffer here and also the value of `desktop-saved-frameset' for control.
(2) Repeat the experiment with two side-by-side windows (that is call
`split-window-right' before saving the desktop) and proceed as described
in (1).
Thanks, martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Fri, 21 Mar 2014 16:20:02 GMT)
Full text and
rfc822 format available.
Message #71 received at 17046 <at> debbugs.gnu.org (full text, mbox):
On Fri, Mar 21, 2014 at 9:02 AM, martin rudalics <rudalics <at> gmx.at> wrote:
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Fri, 21 Mar 2014 16:55:01 GMT)
Full text and
rfc822 format available.
Message #74 received at 17046 <at> debbugs.gnu.org (full text, mbox):
martin rudalics writes:
> > > Once more (I'm confused): What I wanted you to try is to get that bad
> > > frame (the one without title decoration and without minibuffer) back on
> > > screen. Let's call this the "bad base state". Now please in that state
> > > do:
> > >
> > > (1) Apply your window manager's key shortcut to maximize it and then the
> > > shortcut to restore its normal size. Do title bar or minibuffer
> > > come back?
> >
> > No both in the 'maximized' state and on restored the window is exactly
> > the same (though in a different position relative to the rest of the
> > screen). The one difference is that the emacs frame which was
> > originally showing two windows
>
> Do you mean the "bad base state" frame was showing two windows before
> maximization? Or do you mean the frame whose state was saved and should
> have been restored was showing two windows? Or does the "second window"
> refer to the minibuffer window?
>
> > now only shows one window. I'm
> > including a screenshot of the maximised state. Other applications
> > maximise as expected - as does emacs when the desktop isn't loaded.
> > (I commented in a previous message that maximise isn't working
> > properly when the frame is in this state).
>
> You mean it simply does not maximize, as can be seen on the screenshot.
> Are the three buttons (minimize, maximize, delete) on the right of the
> toolbar something you've seen before on your system? I don't see them
> on the screenshot you sent earlier. What happens when you click on
> them? Finally, there are no scroll bars and no right fringes on this
> frame which probably count as more bugs.
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.
>
> > Is the maximise state happening but the border is only giving a
> > partial window and the other buffer is there but the frame cuts off
> > visibility?
>
> The frame dump you sent earlier indicates that the Emacs frame/window
> handling code considers everything in order. This means that the bug
> happens either in the communcation between window manager and Emacs or
> that Emacs doesn't redraw the frame orderly. But all this is dwarfed by
> the fact that there's no title line and the strange buttons on the right
> of the frame.
>
> > > (2) In the bad base state type F11. Does anything change? Type F11
> > > again. Does anything change this time?
> >
> > Exactly the same behaviour as in case (1)
>
> Remarkable. One clue less for the disappearance of the title line.
>
> > I exited the bad state emacs but with only one window shown in the
> > frame and then restarted emacs and the frame was displayed correctly!
> > I then displayed another buffer in a second window in that frame and
> > exited again. On a restart the problem was back.
>
> I can only assure you that yours is the strangest behavior I've seen
> over the past year.
>
> > The problem only seems to occur when the frame is trying to show 2
> > buffers?
>
> OK. I'm happy that the problem is reliably repeatable. So please
> proceed as follows:
>
> (1) In the frame whose state you save, just before exiting it, do
> `window--dump-frame' and post the contents of the *window-frame-dump*
> buffer here and also the value of `desktop-saved-frameset' for control.
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
(setq desktop-saved-frameset [frameset 1 (21292 26291 660046 398000) (desktop . "206") "robert <at> 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 . 36) (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 . 630) (total-width . 124) (total-height . 35) (normal-height . 1.0) (normal-width . 1.0) (combination-limit) (leaf (pixel-width . 992) (pixel-height . 314) (total-width . 124) (total-height . 17) (normal-height . 0.5) (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 . 2818) (start . 2727))) (leaf (last . t) (pixel-width . 992) (pixel-height . 316) (total-width . 124) (total-height . 18) (normal-height . 0.5) (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 . 28638) (start . 28492)))))])
>
> (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") "robert <at> 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") "robert <at> 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) (start . 3837))))])
Robert
--
Robert Marshall
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Fri, 21 Mar 2014 17:43:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 17046 <at> debbugs.gnu.org (full text, mbox):
> Sorry for the confusion I've caused here - those 3 buttons belong to
> another application whose window I have shaded (so that the rest of it
> is not visible).
Ahh... OK.
> The emacs scroll bars and fringe disappear when the
> window gets the maximise command.
But they do so only on this "bad" frame, I suppose. Maximizing a "good"
frame doesn't cause them to disappear.
> You mean before exiting emacs and that saving the desktop file and
> with an un'maximised' bad frame? I get (evaluating it in*scratch*)
> (see end of message - maybe I've misunderstood you here and you wanted
> the output with just one window in the bad frame - the output from
> that option is at the end)
You've done everything as I wanted, thanks. This one reveals a strange
bug, namely in the last line of
> #<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.
> So just one buffer in the frame split into 2 side by side windows
> (with the issues with two windows I'd been using split-window-below
> and displaying another buffer in the second window).......
>
> In attempting to restart to do this test I was unable to replicate the
> error for some time,
... which I expected ...
> I started emacs 3-4 times without the problem,
> eventually I got a bad frame and got the results below:
... which I didn't expect. But again the values look correct and even
the minibuffer window has the correct char width now,
> #<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.
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sat, 22 Mar 2014 01:55:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 17046 <at> debbugs.gnu.org (full text, mbox):
On Fri, Mar 21, 2014 at 6:42 PM, martin rudalics <rudalics <at> gmx.at> wrote:
> Juanma must likely help now for the HOWTO:
I'm a bit lost here. What do you need from me?
> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sat, 22 Mar 2014 09:40:02 GMT)
Full text and
rfc822 format available.
Message #83 received at 17046 <at> debbugs.gnu.org (full text, mbox):
>> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sat, 22 Mar 2014 09:41:02 GMT)
Full text and
rfc822 format available.
Message #86 received at 17046 <at> debbugs.gnu.org (full text, mbox):
> 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).
> 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.
> 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.
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sat, 22 Mar 2014 11:37:02 GMT)
Full text and
rfc822 format available.
Message #89 received at 17046 <at> debbugs.gnu.org (full text, mbox):
martin rudalics writes:
> > 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.
> > 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
--
Robert Marshall
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sat, 22 Mar 2014 11:44:01 GMT)
Full text and
rfc822 format available.
Message #92 received at 17046 <at> debbugs.gnu.org (full text, mbox):
On Sat, Mar 22, 2014 at 10:39 AM, martin rudalics <rudalics <at> gmx.at> wrote:
> 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).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sat, 22 Mar 2014 13:46:02 GMT)
Full text and
rfc822 format available.
Message #95 received at 17046 <at> debbugs.gnu.org (full text, mbox):
>> > 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")
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.
> or with my normal .emacs will let you know when I manage to generate
> the same problem again!
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sat, 22 Mar 2014 13:46:03 GMT)
Full text and
rfc822 format available.
Message #98 received at 17046 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sat, 22 Mar 2014 14:04:02 GMT)
Full text and
rfc822 format available.
Message #101 received at 17046 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sat, Mar 22, 2014 at 2:44 PM, martin rudalics <rudalics <at> gmx.at> wrote:
> 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.
> 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
> 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
[bug17046.el (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sat, 22 Mar 2014 14:06:01 GMT)
Full text and
rfc822 format available.
Message #104 received at 17046 <at> debbugs.gnu.org (full text, mbox):
On Sat, Mar 22, 2014 at 2:45 PM, martin rudalics <rudalics <at> gmx.at> wrote:
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sat, 22 Mar 2014 14:22:01 GMT)
Full text and
rfc822 format available.
Message #107 received at 17046 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sat, 22 Mar 2014 14:22:02 GMT)
Full text and
rfc822 format available.
Message #110 received at 17046 <at> debbugs.gnu.org (full text, mbox):
> But it is a w32-specific hack?
Yes.
> Because Robert's frameset contains
> (maximized), but he's on Ubuntu.
My BTW referred to the Windows version only ;-)
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sat, 22 Mar 2014 14:29:01 GMT)
Full text and
rfc822 format available.
Message #113 received at 17046 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 22 Mar 2014 14:45:01 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> Cc: 17046 <at> debbugs.gnu.org, Robert Marshall <robert <at> capuchin.co.uk>
>
> > 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sat, 22 Mar 2014 14:35:02 GMT)
Full text and
rfc822 format available.
Message #116 received at 17046 <at> debbugs.gnu.org (full text, mbox):
On Sat, Mar 22, 2014 at 3:20 PM, martin rudalics <rudalics <at> gmx.at> wrote:
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sat, 22 Mar 2014 14:40:02 GMT)
Full text and
rfc822 format available.
Message #119 received at 17046 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sat, 22 Mar 2014 15:21:01 GMT)
Full text and
rfc822 format available.
Message #122 received at 17046 <at> debbugs.gnu.org (full text, mbox):
> 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?
The latter, I'd say.
> (I'm not sure what do you mean with "strictly visible", BTW).
"Strictly visible" should stand for "always visible while desktop
restoration is done".
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sat, 22 Mar 2014 15:22:02 GMT)
Full text and
rfc822 format available.
Message #125 received at 17046 <at> debbugs.gnu.org (full text, mbox):
>> 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.
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sat, 22 Mar 2014 15:22:03 GMT)
Full text and
rfc822 format available.
Message #128 received at 17046 <at> debbugs.gnu.org (full text, mbox):
> 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?
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sat, 22 Mar 2014 15:27:02 GMT)
Full text and
rfc822 format available.
Message #131 received at 17046 <at> debbugs.gnu.org (full text, mbox):
On Sat, Mar 22, 2014 at 4:20 PM, martin rudalics <rudalics <at> gmx.at> wrote:
> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sat, 22 Mar 2014 15:34:02 GMT)
Full text and
rfc822 format available.
Message #134 received at 17046 <at> debbugs.gnu.org (full text, mbox):
> I'm lost. Why wouldn't it work to call (sit-for 0) before calling
> frameset-restore?
Robert can you do that?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sat, 22 Mar 2014 16:29:02 GMT)
Full text and
rfc822 format available.
Message #137 received at 17046 <at> debbugs.gnu.org (full text, mbox):
martin rudalics writes:
> > 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
--
Robert Marshall
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sat, 22 Mar 2014 16:40:04 GMT)
Full text and
rfc822 format available.
Message #140 received at 17046 <at> debbugs.gnu.org (full text, mbox):
On Sat, Mar 22, 2014 at 5:28 PM, Robert Marshall <robert <at> capuchin.co.uk> wrote:
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sat, 22 Mar 2014 16:57:02 GMT)
Full text and
rfc822 format available.
Message #143 received at 17046 <at> debbugs.gnu.org (full text, mbox):
Juanma Barranquero writes:
> On Fri, Mar 21, 2014 at 6:42 PM, martin rudalics <rudalics <at> gmx.at> wrote:
>
> > Juanma must likely help now for the HOWTO:
>
> I'm a bit lost here. What do you need from me?
>
> > 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).
OK I've managed to get a bad frame here, no window decorations but
there is a minibuffer visible (and not maximised)
> 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).
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
>
> 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
--
Robert Marshall
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sat, 22 Mar 2014 17:01:02 GMT)
Full text and
rfc822 format available.
Message #146 received at 17046 <at> debbugs.gnu.org (full text, mbox):
Juanma Barranquero writes:
> On Sat, Mar 22, 2014 at 5:28 PM, Robert Marshall <robert <at> capuchin.co.uk> wrote:
>
> > 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
--
Links and things http://rmstar.blogspot.com/
Robert Marshall
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sat, 22 Mar 2014 17:36:01 GMT)
Full text and
rfc822 format available.
Message #149 received at 17046 <at> debbugs.gnu.org (full text, mbox):
On Sat, Mar 22, 2014 at 6:00 PM, Robert Marshall <robert <at> capuchin.co.uk> wrote:
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sat, 22 Mar 2014 17:40:01 GMT)
Full text and
rfc822 format available.
Message #152 received at 17046 <at> debbugs.gnu.org (full text, mbox):
On Sat, Mar 22, 2014 at 5:56 PM, Robert Marshall <robert <at> capuchin.co.uk> wrote:
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sat, 22 Mar 2014 18:37:02 GMT)
Full text and
rfc822 format available.
Message #155 received at 17046 <at> debbugs.gnu.org (full text, mbox):
Juanma Barranquero writes:
> On Sat, Mar 22, 2014 at 5:28 PM, Robert Marshall <robert <at> capuchin.co.uk> wrote:
>
> > I'm rather confused as to what I'm being asked to do!
>
> FWIW, I'm rather confused too... ;-)
>
That's a relief!
> > 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
>
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") "robert <at> 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.el
Robert
--
Robert Marshall
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sat, 22 Mar 2014 18:44:02 GMT)
Full text and
rfc822 format available.
Message #158 received at 17046 <at> debbugs.gnu.org (full text, mbox):
> 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.
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sat, 22 Mar 2014 19:10:03 GMT)
Full text and
rfc822 format available.
Message #161 received at 17046 <at> debbugs.gnu.org (full text, mbox):
On Sat, Mar 22, 2014 at 7:36 PM, Robert Marshall <robert <at> capuchin.co.uk> wrote:
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sat, 22 Mar 2014 19:19:01 GMT)
Full text and
rfc822 format available.
Message #164 received at 17046 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> 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
[bug17046.el (application/emacs-lisp, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sat, 22 Mar 2014 19:19:02 GMT)
Full text and
rfc822 format available.
Message #167 received at 17046 <at> debbugs.gnu.org (full text, mbox):
On Sat, Mar 22, 2014 at 7:43 PM, martin rudalics <rudalics <at> gmx.at> wrote:
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sat, 22 Mar 2014 19:24:01 GMT)
Full text and
rfc822 format available.
Message #170 received at 17046 <at> debbugs.gnu.org (full text, mbox):
On Sat, Mar 22, 2014 at 8:18 PM, martin rudalics <rudalics <at> gmx.at> wrote:
> 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.
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sat, 22 Mar 2014 19:35:02 GMT)
Full text and
rfc822 format available.
Message #173 received at 17046 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sat, 22 Mar 2014 20:18:01 GMT)
Full text and
rfc822 format available.
Message #176 received at 17046 <at> debbugs.gnu.org (full text, mbox):
martin rudalics writes:
> > 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)
> 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.
--
Robert Marshall
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sat, 22 Mar 2014 21:18:02 GMT)
Full text and
rfc822 format available.
Message #179 received at 17046 <at> debbugs.gnu.org (full text, mbox):
On Sat, Mar 22, 2014 at 9:17 PM, Robert Marshall <robert <at> capuchin.co.uk> wrote:
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sat, 22 Mar 2014 21:36:02 GMT)
Full text and
rfc822 format available.
Message #182 received at 17046 <at> debbugs.gnu.org (full text, mbox):
> 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.
> So I've tried it with your version of bug17046.el (now with 2 find-files)
>
>> 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)?
> 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?
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sat, 22 Mar 2014 21:36:03 GMT)
Full text and
rfc822 format available.
Message #185 received at 17046 <at> debbugs.gnu.org (full text, mbox):
>> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sat, 22 Mar 2014 21:43:01 GMT)
Full text and
rfc822 format available.
Message #188 received at 17046 <at> debbugs.gnu.org (full text, mbox):
On Sat, Mar 22, 2014 at 10:35 PM, martin rudalics <rudalics <at> gmx.at> wrote:
> 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).
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sat, 22 Mar 2014 22:11:02 GMT)
Full text and
rfc822 format available.
Message #191 received at 17046 <at> debbugs.gnu.org (full text, mbox):
martin rudalics writes:
> > 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
> > 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?
>
> > 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?
> 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!
--
Robert Marshall
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sat, 22 Mar 2014 22:16:02 GMT)
Full text and
rfc822 format available.
Message #194 received at 17046 <at> debbugs.gnu.org (full text, mbox):
On Sat, Mar 22, 2014 at 11:10 PM, Robert Marshall <robert <at> capuchin.co.uk> wrote:
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sat, 22 Mar 2014 22:17:01 GMT)
Full text and
rfc822 format available.
Message #197 received at 17046 <at> debbugs.gnu.org (full text, mbox):
Juanma Barranquero writes:
> On Sat, Mar 22, 2014 at 10:35 PM, martin rudalics <rudalics <at> gmx.at> wrote:
>
> > 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
--
Robert Marshall
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sun, 23 Mar 2014 10:13:02 GMT)
Full text and
rfc822 format available.
Message #200 received at 17046 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sun, 23 Mar 2014 11:15:02 GMT)
Full text and
rfc822 format available.
Message #203 received at 17046 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
martin rudalics writes:
> > 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.
>
[bug17046-a.el (application/octet-stream, attachment)]
[Message part 3 (text/plain, inline)]
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
Robert
--
Robert Marshall
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sun, 23 Mar 2014 11:40:02 GMT)
Full text and
rfc822 format available.
Message #206 received at 17046 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> 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
[bug17046-b.el (application/emacs-lisp, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sun, 23 Mar 2014 12:14:01 GMT)
Full text and
rfc822 format available.
Message #209 received at 17046 <at> debbugs.gnu.org (full text, mbox):
martin rudalics writes:
> > 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sun, 23 Mar 2014 13:41:03 GMT)
Full text and
rfc822 format available.
Message #212 received at 17046 <at> debbugs.gnu.org (full text, mbox):
martin rudalics writes:
> > 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
--
Robert Marshall
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sun, 23 Mar 2014 13:53:01 GMT)
Full text and
rfc822 format available.
Message #215 received at 17046 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> 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
[bug17046-b.el (application/emacs-lisp, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sun, 23 Mar 2014 14:12:01 GMT)
Full text and
rfc822 format available.
Message #218 received at submit <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sun, 23 Mar 2014 14:31:01 GMT)
Full text and
rfc822 format available.
Message #221 received at 17046 <at> debbugs.gnu.org (full text, mbox):
martin rudalics writes:
> > 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
--
Robert Marshall
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sun, 23 Mar 2014 14:57:02 GMT)
Full text and
rfc822 format available.
Message #224 received at 17046 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> 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")
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
[bug17046-c.el (application/emacs-lisp, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sun, 23 Mar 2014 15:04:01 GMT)
Full text and
rfc822 format available.
Message #227 received at 17046 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
And please try the attached single window frame too.
martin
[bug17046-d.el (application/emacs-lisp, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sun, 23 Mar 2014 15:19:01 GMT)
Full text and
rfc822 format available.
Message #230 received at 17046 <at> debbugs.gnu.org (full text, mbox):
martin rudalics writes:
> > 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")
>
> 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
--
Robert Marshall
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sun, 23 Mar 2014 15:29:01 GMT)
Full text and
rfc822 format available.
Message #233 received at 17046 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sun, 23 Mar 2014 15:35:02 GMT)
Full text and
rfc822 format available.
Message #236 received at 17046 <at> debbugs.gnu.org (full text, mbox):
martin rudalics writes:
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sun, 23 Mar 2014 16:08:02 GMT)
Full text and
rfc822 format available.
Message #239 received at 17046 <at> debbugs.gnu.org (full text, mbox):
[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]
martin rudalics writes:
> Once more (I'm confused): What I wanted you to try is to get that bad
> frame (the one without title decoration and without minibuffer) back on
> screen. Let's call this the "bad base state". Now please in that state
> do:
>
> (1) Apply your window manager's key shortcut to maximize it and then the
> shortcut to restore its normal size. Do title bar or minibuffer
> come back?
No both in the 'maximized' state and on restored the window is exactly
the same (though in a different position relative to the rest of the
screen). The one difference is that the emacs frame which was
originally showing two windows 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:
http://debbugs.gnu.org/cgi/bugreport.cgi?msg=65;filename=maxim.png;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?
>
> (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
--
Robert Marshall
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sun, 23 Mar 2014 16:11:01 GMT)
Full text and
rfc822 format available.
Message #242 received at 17046 <at> debbugs.gnu.org (full text, mbox):
martin rudalics writes:
> > 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
--
Links and things http://rmstar.blogspot.com/
Robert Marshall
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sun, 23 Mar 2014 16:39:05 GMT)
Full text and
rfc822 format available.
Message #245 received at 17046 <at> debbugs.gnu.org (full text, mbox):
On Sun, Mar 23, 2014 at 5:10 PM, Robert Marshall <robert <at> capuchin.co.uk> wrote:
> 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...).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sun, 23 Mar 2014 16:51:01 GMT)
Full text and
rfc822 format available.
Message #248 received at 17046 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> 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
[bug17046-e.el (application/emacs-lisp, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sun, 23 Mar 2014 16:58:02 GMT)
Full text and
rfc822 format available.
Message #251 received at 17046 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sun, 23 Mar 2014 17:08:01 GMT)
Full text and
rfc822 format available.
Message #254 received at 17046 <at> debbugs.gnu.org (full text, mbox):
Juanma Barranquero writes:
> On Sun, Mar 23, 2014 at 5:10 PM, Robert Marshall <robert <at> capuchin.co.uk> wrote:
>
> > 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
--
Robert Marshall
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sun, 23 Mar 2014 17:12:02 GMT)
Full text and
rfc822 format available.
Message #257 received at 17046 <at> debbugs.gnu.org (full text, mbox):
martin rudalics writes:
> > 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
--
Robert Marshall
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sun, 23 Mar 2014 17:20:02 GMT)
Full text and
rfc822 format available.
Message #260 received at 17046 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sun, 23 Mar 2014 17:29:02 GMT)
Full text and
rfc822 format available.
Message #263 received at 17046 <at> debbugs.gnu.org (full text, mbox):
> 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) From that version one by one comment out a line that is not
present in bug17046-e.el.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sun, 23 Mar 2014 17:44:02 GMT)
Full text and
rfc822 format available.
Message #266 received at 17046 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
martin rudalics writes:
> > 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) From that version one by one comment out a line that is not
> present in bug17046-e.el.
>
I thought that was the (display . ":0")
line (as in my response to Juanma)?
I'm attaching the version I have with the single line to comment which
removes the bug indicated:
[bug17046-b.el (application/octet-stream, attachment)]
[Message part 3 (text/plain, inline)]
In nether case does it produce any other error
Robert
--
Links and things http://rmstar.blogspot.com/
Robert Marshall
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sun, 23 Mar 2014 18:10:02 GMT)
Full text and
rfc822 format available.
Message #269 received at 17046 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sun, 23 Mar 2014 19:07:02 GMT)
Full text and
rfc822 format available.
Message #272 received at 17046 <at> debbugs.gnu.org (full text, mbox):
martin rudalics writes:
> > 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"
>
> give in a normal emacs -Q session? And what gives
>
> (getenv "DISPLAY")
>
":0" again
> in such a session?
>
looks to be consistent
Robert
--
Robert Marshall
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sun, 23 Mar 2014 19:13:01 GMT)
Full text and
rfc822 format available.
Message #275 received at 17046 <at> debbugs.gnu.org (full text, mbox):
On Sun, Mar 23, 2014 at 6:43 PM, Robert Marshall <robert <at> capuchin.co.uk> wrote:
> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sun, 23 Mar 2014 19:33:01 GMT)
Full text and
rfc822 format available.
Message #278 received at 17046 <at> debbugs.gnu.org (full text, mbox):
Juanma Barranquero writes:
> On Sun, Mar 23, 2014 at 6:43 PM, Robert Marshall <robert <at> capuchin.co.uk> wrote:
>
> > 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
--
Robert Marshall
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sun, 23 Mar 2014 20:19:02 GMT)
Full text and
rfc822 format available.
Message #281 received at 17046 <at> debbugs.gnu.org (full text, mbox):
On Sun, Mar 23, 2014 at 8:32 PM, Robert Marshall <robert <at> capuchin.co.uk> wrote:
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sun, 23 Mar 2014 21:02:02 GMT)
Full text and
rfc822 format available.
Message #284 received at 17046 <at> debbugs.gnu.org (full text, mbox):
Juanma Barranquero writes:
> On Sun, Mar 23, 2014 at 8:32 PM, Robert Marshall <robert <at> capuchin.co.uk> wrote:
>
> > 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)
>
=== 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))
> 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
--
Robert Marshall
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sun, 23 Mar 2014 21:10:01 GMT)
Full text and
rfc822 format available.
Message #287 received at 17046 <at> debbugs.gnu.org (full text, mbox):
On Sun, Mar 23, 2014 at 10:01 PM, Robert Marshall <robert <at> capuchin.co.uk> wrote:
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sun, 23 Mar 2014 21:19:02 GMT)
Full text and
rfc822 format available.
Message #290 received at 17046 <at> debbugs.gnu.org (full text, mbox):
Could you please post the exact .el file you're using to reproduce the bug?
Thanks,
J
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Sun, 23 Mar 2014 21:36:02 GMT)
Full text and
rfc822 format available.
Message #293 received at 17046 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Juanma Barranquero writes:
> Could you please post the exact .el file you're using to reproduce the bug?
>
Here it is
[bug17046-b.el (application/octet-stream, attachment)]
[Message part 3 (text/plain, inline)]
Robert
--
Robert Marshall
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Mon, 24 Mar 2014 00:15:02 GMT)
Full text and
rfc822 format available.
Message #296 received at 17046 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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
[bug17046-b.el (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Mon, 24 Mar 2014 08:10:02 GMT)
Full text and
rfc822 format available.
Message #299 received at 17046 <at> debbugs.gnu.org (full text, mbox):
Juanma Barranquero writes:
> 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 emacs <at> 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 emacs <at> 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
--
Robert Marshall
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Mon, 24 Mar 2014 11:33:01 GMT)
Full text and
rfc822 format available.
Message #302 received at 17046 <at> debbugs.gnu.org (full text, mbox):
On Mon, Mar 24, 2014 at 9:09 AM, Robert Marshall <robert <at> capuchin.co.uk> wrote:
> With bug:
>
> #<frame emacs <at> poulenc 0x8725ae0> was :reused
> Without bug:
>
> #<frame emacs <at> poulenc 0x9c6c040> was :created
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))))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Mon, 24 Mar 2014 11:37:02 GMT)
Full text and
rfc822 format available.
Message #305 received at 17046 <at> debbugs.gnu.org (full text, mbox):
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))))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Mon, 24 Mar 2014 12:04:02 GMT)
Full text and
rfc822 format available.
Message #308 received at 17046 <at> debbugs.gnu.org (full text, mbox):
Juanma Barranquero writes:
> 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))))
>
I don't see a problem in this case - and also there's no problem in
the case in your earlier email.
(I've kept the mod you gave me yesterday for frameset.el I assume that
as it's a bug fix it is not material to this)
R
--
Robert Marshall
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Mon, 24 Mar 2014 12:58:01 GMT)
Full text and
rfc822 format available.
Message #311 received at 17046 <at> debbugs.gnu.org (full text, mbox):
On Mon, Mar 24, 2014 at 1:03 PM, Robert Marshall <robert <at> capuchin.co.uk> wrote:
> I don't see a problem in this case - and also there's no problem in
> the case in your earlier email.
Curiouser and curiouser.
> (I've kept the mod you gave me yesterday for frameset.el I assume that
> as it's a bug fix it is not material to this)
If you mean the change from `eq' to `equal', yeah, it's OK.
Now, could you please modify the bug17046-b.el I gave you earlier, and
change line 33 from
(cons '(visibility)
to
(cons '(visibility . t)
and try again both tests (with and without '(display . ":0")).
Thanks,
J
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Mon, 24 Mar 2014 13:24:02 GMT)
Full text and
rfc822 format available.
Message #314 received at 17046 <at> debbugs.gnu.org (full text, mbox):
Juanma Barranquero writes:
> Now, could you please modify the bug17046-b.el I gave you earlier, and
> change line 33 from
>
> (cons '(visibility)
>
> to
>
> (cons '(visibility . t)
>
> and try again both tests (with and without '(display . ":0")).
>
With display (and bug)
#<frame emacs <at> 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 display (or bug)
#<frame emacs <at> poulenc 0x99cfb08> 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
--
Robert Marshall
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Mon, 24 Mar 2014 14:59:01 GMT)
Full text and
rfc822 format available.
Message #317 received at 17046 <at> debbugs.gnu.org (full text, mbox):
On Mon, Mar 24, 2014 at 2:23 PM, Robert Marshall <robert <at> capuchin.co.uk> wrote:
> With display (and bug)
A nice theory just hit the dirt. Bummer.
Please revert the previous change. (i.e., it should have "(cons
'(visibility)" again), and comment out the window-state-put call in
line 48. Let's see whether the bug happens when creating the frame, or
when we put the window-state.
J
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Mon, 24 Mar 2014 15:22:01 GMT)
Full text and
rfc822 format available.
Message #320 received at 17046 <at> debbugs.gnu.org (full text, mbox):
Juanma Barranquero writes:
> On Mon, Mar 24, 2014 at 2:23 PM, Robert Marshall <robert <at> capuchin.co.uk> wrote:
>
> > With display (and bug)
>
> A nice theory just hit the dirt. Bummer.
>
> Please revert the previous change. (i.e., it should have "(cons
> '(visibility)" again), and comment out the window-state-put call in
> line 48. Let's see whether the bug happens when creating the frame, or
> when we put the window-state.
>
With bug:
#<frame emacs <at> 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 emacs <at> poulenc 0x8d0dea0> 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
--
Robert Marshall
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Mon, 24 Mar 2014 15:42:02 GMT)
Full text and
rfc822 format available.
Message #323 received at 17046 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Mon, Mar 24, 2014 at 4:22 PM, Robert Marshall <robert <at> capuchin.co.uk> wrote:
> With bug:
>
> #<frame emacs <at> poulenc 0x8725ae0> was :reused
So it doesn't depend on the window-state.
If you're not yet bored to death, please try with the attached .el
file. It should behave as in the previous cases, but I want to see the
real, final frame parameter list of the reused (buggy) frame and the
created (correct) one.
(Thanks for your patience, BTW)
[bug17046-c.el (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Mon, 24 Mar 2014 16:10:02 GMT)
Full text and
rfc822 format available.
Message #326 received at 17046 <at> debbugs.gnu.org (full text, mbox):
Juanma Barranquero writes:
> On Mon, Mar 24, 2014 at 4:22 PM, Robert Marshall <robert <at> capuchin.co.uk> wrote:
>
> > With bug:
> >
> > #<frame emacs <at> poulenc 0x8725ae0> was :reused
>
> So it doesn't depend on the window-state.
>
> If you're not yet bored to death, please try with the attached .el
> file. It should behave as in the previous cases, but I want to see the
> real, final frame parameter list of the reused (buggy) frame and the
> created (correct) one.
>
With bug:
#<frame emacs <at> poulenc 0x8725ae0> was :reused with:
(alpha)
(auto-lower)
(auto-raise)
(background-color . white)
(background-mode . light)
(border-color . black)
(border-width . 0)
(bottom-divider-width . 0)
(buffer-list *scratch*)
(buffer-predicate)
(buried-buffer-list)
(cursor-color . black)
(cursor-type . box)
(display . :0)
(display-type . color)
(environment)
(explicit-name)
(font . -unknown-DejaVu Sans Mono-normal-normal-normal-*-14-*-*-*-m-0-iso10646-1)
(font-backend xft x)
(font-parameter . Monospace 11)
(foreground-color . black)
(fullscreen)
(height . 35)
(horizontal-scroll-bars . t)
(icon-name)
(icon-type . t)
(internal-border-width . 0)
(left . 896)
(left-fringe . 8)
(line-spacing)
(menu-bar-lines . 1)
(minibuffer . #<window 4 on *Minibuf-0*>)
(modeline . t)
(mouse-color . black)
(name . emacs <at> poulenc)
(outer-window-id . 115343557)
(parent-id . 34054155)
(right-divider-width . 0)
(right-fringe . 8)
(screen-gamma)
(scroll-bar-background)
(scroll-bar-foreground)
(scroll-bar-width . 16)
(sticky)
(title)
(tool-bar-lines . 1)
(tool-bar-position . top)
(top . 0)
(unsplittable)
(vertical-scroll-bars . right)
(visibility . t)
(wait-for-wm . t)
(width . 80)
(window-id . 115343562)
(window-system . x)
--------------------------------------------------------------------------------
w/o bug:
#<frame emacs <at> poulenc 0x9fae3d8> was :created with:
(alpha)
(auto-lower)
(auto-raise)
(background-color . white)
(background-mode . light)
(border-color . black)
(border-width . 0)
(bottom-divider-width . 0)
(buffer-list *scratch*)
(buffer-predicate)
(buried-buffer-list)
(cursor-color . black)
(cursor-type . box)
(display . :0)
(display-type . color)
(explicit-name)
(font . -unknown-DejaVu Sans Mono-normal-normal-normal-*-14-*-*-*-m-0-iso10646-1)
(font-backend xft x)
(font-parameter . Monospace 11)
(foreground-color . black)
(fullscreen)
(height . 30)
(icon-name)
(icon-type . t)
(internal-border-width . 0)
(left . 0)
(left-fringe . 8)
(line-spacing)
(menu-bar-lines . 1)
(minibuffer . #<window 6 on *Minibuf-0*>)
(modeline . t)
(mouse-color . black)
(name . emacs <at> poulenc)
(outer-window-id . 115343946)
(parent-id)
(right-divider-width . 0)
(right-fringe . 8)
(screen-gamma)
(scroll-bar-background)
(scroll-bar-foreground)
(scroll-bar-width . 16)
(title)
(tool-bar-lines . 1)
(tool-bar-position . top)
(top . 0)
(unsplittable)
(vertical-scroll-bars . right)
(visibility)
(wait-for-wm . t)
(width . 80)
(window-id . 115343950)
--------------------------------------------------------------------------------
> (Thanks for your patience, BTW)
;-) it is a bit of an epic! I hope you're getting useful information
R
--
Robert Marshall
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Mon, 24 Mar 2014 16:18:03 GMT)
Full text and
rfc822 format available.
Message #329 received at 17046 <at> debbugs.gnu.org (full text, mbox):
On Mon, Mar 24, 2014 at 5:09 PM, Robert Marshall <robert <at> capuchin.co.uk> wrote:
> ;-) it is a bit of an epic! I hope you're getting useful information
Well, we're closing on it, yes. It happens on reusing, and seems
related to display, and does not depend on the windows it shows.
That's good to know.
Now, please cut the `let' from lines 23-30 and paste it at the end of
the function, just there:
(when alt-cfg (modify-frame-parameters frame alt-cfg))
;;; paste the `let' here
frame))
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Mon, 24 Mar 2014 17:14:01 GMT)
Full text and
rfc822 format available.
Message #332 received at 17046 <at> debbugs.gnu.org (full text, mbox):
Juanma Barranquero writes:
> On Mon, Mar 24, 2014 at 5:09 PM, Robert Marshall <robert <at> capuchin.co.uk> wrote:
>
> > ;-) it is a bit of an epic! I hope you're getting useful information
>
> Well, we're closing on it, yes. It happens on reusing, and seems
> related to display, and does not depend on the windows it shows.
> That's good to know.
>
Good to hear!
> Now, please cut the `let' from lines 23-30 and paste it at the end of
> the function, just there:
>
> (when alt-cfg (modify-frame-parameters frame alt-cfg))
> ;;; paste the `let' here
> frame))
>
With bug:
--------------------------------------------------------------------------------
#<frame emacs <at> poulenc 0x8725ae0> was :reused with:
(alpha)
(auto-lower)
(auto-raise)
(background-color . white)
(background-mode . light)
(border-color . black)
(border-width . 0)
(bottom-divider-width . 0)
(buffer-list *scratch*)
(buffer-predicate)
(buried-buffer-list)
(cursor-color . black)
(cursor-type . box)
(display . :0)
(display-type . color)
(environment)
(explicit-name)
(font . -unknown-DejaVu Sans Mono-normal-normal-normal-*-14-*-*-*-m-0-iso10646-1)
(font-backend xft x)
(font-parameter . Monospace 11)
(foreground-color . black)
(frameset--id . DA9D-E03E-DF32-EAB7)
(frameset--mini t . t)
(fullscreen)
(height . 36)
(horizontal-scroll-bars . t)
(icon-name)
(icon-type . t)
(internal-border-width . 0)
(left . 896)
(left-fringe . 8)
(line-spacing)
(menu-bar-lines . 1)
(minibuffer . #<window 4 on *Minibuf-0*>)
(modeline . t)
(mouse-color . black)
(name . emacs <at> poulenc)
(outer-window-id . 115343557)
(parent-id . 33987892)
(right-divider-width . 0)
(right-fringe . 8)
(screen-gamma)
(scroll-bar-background)
(scroll-bar-foreground)
(scroll-bar-width . 16)
(sticky)
(title)
(tool-bar-lines . 0)
(tool-bar-position . top)
(top . 0)
(unsplittable)
(vertical-scroll-bars . right)
(visibility . t)
(wait-for-wm . t)
(width . 80)
(window-id . 115343562)
(window-system . x)
--------------------------------------------------------------------------------
Without bug:
--------------------------------------------------------------------------------
#<frame emacs <at> poulenc 0x8d57b08> was :created with:
(alpha)
(auto-lower)
(auto-raise)
(background-color . white)
(background-mode . light)
(border-color . black)
(border-width . 0)
(bottom-divider-width . 0)
(buffer-list *scratch*)
(buffer-predicate)
(buried-buffer-list)
(cursor-color . black)
(cursor-type . box)
(display . :0)
(display-type . color)
(explicit-name)
(font . -unknown-DejaVu Sans Mono-normal-normal-normal-*-14-*-*-*-m-0-iso10646-1)
(font-backend xft x)
(font-parameter . Monospace 11)
(foreground-color . black)
(frameset--id . DA9D-E03E-DF32-EAB7)
(frameset--mini t . t)
(fullscreen)
(height . 30)
(icon-name)
(icon-type . t)
(internal-border-width . 0)
(left . 0)
(left-fringe . 8)
(line-spacing)
(menu-bar-lines . 1)
(minibuffer . #<window 6 on *Minibuf-0*>)
(modeline . t)
(mouse-color . black)
(name . emacs <at> poulenc)
(outer-window-id . 115343940)
(parent-id . 34000989)
(right-divider-width . 0)
(right-fringe . 8)
(screen-gamma)
(scroll-bar-background)
(scroll-bar-foreground)
(scroll-bar-width . 16)
(sticky)
(title)
(tool-bar-lines . 0)
(tool-bar-position . top)
(top . 0)
(unsplittable)
(vertical-scroll-bars . right)
(visibility . t)
(wait-for-wm . t)
(width . 80)
(window-id . 115343944)
--------------------------------------------------------------------------------
--
Robert Marshall
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Mon, 24 Mar 2014 17:26:02 GMT)
Full text and
rfc822 format available.
Message #335 received at 17046 <at> debbugs.gnu.org (full text, mbox):
Interesting. There aren't that many differences between the frames.
The possibly significant ones:
(environment)
(height . 36)
(horizontall-scroll-bars . t)
(left . 896)
(window-system . x)
vs.
(height . 30)
(left . 0)
So I'd suggest adding them (the ones in the first group) one by one to
your bug17046.el, and repeat the tests. Comment out the `let' from the
previous message, there's no need to report the frame parameters now,
just whether some case fails / works when previously it would've
worked / failed instead.
Let's hope we find something that can explain the different behavior.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Mon, 24 Mar 2014 18:49:02 GMT)
Full text and
rfc822 format available.
Message #338 received at 17046 <at> debbugs.gnu.org (full text, mbox):
Juanma Barranquero writes:
> Interesting. There aren't that many differences between the frames.
> The possibly significant ones:
>
> (environment)
> (height . 36)
> (horizontall-scroll-bars . t)
(horizontal-scroll-bars . t) ; !
> (left . 896)
> (window-system . x)
>
> vs.
>
> (height . 30)
> (left . 0)
>
> So I'd suggest adding them (the ones in the first group) one by one to
> your bug17046.el, and repeat the tests. Comment out the `let' from the
> previous message, there's no need to report the frame parameters now,
> just whether some case fails / works when previously it would've
> worked / failed instead.
I'm assuming that because the ones in the first group appeared in the
buggy run and not in the other, I need to add these to the version
with (display... commented out and see if the bug occurs? I added
them incrementally - (environment) and then (environment) and
(height...) and so on until all 4 were active and then ran with one of
them only active at a time and the bug did not appear (so 7 runs in all).
R
--
Robert Marshall
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Mon, 24 Mar 2014 21:34:02 GMT)
Full text and
rfc822 format available.
Message #341 received at 17046 <at> debbugs.gnu.org (full text, mbox):
Juanma Barranquero writes:
> On Mon, Mar 24, 2014 at 7:48 PM, Robert Marshall <robert <at> capuchin.co.uk> wrote:
>
> > (horizontal-scroll-bars . t) ; !
>
> Yes, a typo, sorry.
>
> > I'm assuming that because the ones in the first group appeared in the
> > buggy run and not in the other, I need to add these to the version
> > with (display... commented out and see if the bug occurs? I added
> > them incrementally - (environment) and then (environment) and
> > (height...) and so on until all 4 were active
>
> There were 5, not 4.
>
So there were, that's one error each ;-) though height was already
there in the parameters so my eye must have elided it, I've just tried
it with 36 (rather than 30) and that doesn't make the version without
display error.
> > them only active at a time and the bug did not appear
>
> Hmm. I'm running out of ideas.
>
> Please test the attached version. In the parameter list, I've added
> the five parameters of the previous message. The idea is to test them
> as a group, so four runs:
>
> - with (display . ":0") and the five parameters above
> - with (display . ":0") and none of the five
> - without display, in both cases.
>
> Each run will generate in *Messages* two dumps from the frame
> parameter list, but I'm only interested in these in the case(s) where
> the bug appears.
>
I've done all 4 runs and none of them produced the bug! I assume this
isn't what you expected, I see some of the parameters to
frameset-restore are different.
R
--
Robert Marshall
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Mon, 24 Mar 2014 21:54:02 GMT)
Full text and
rfc822 format available.
Message #344 received at 17046 <at> debbugs.gnu.org (full text, mbox):
On Mon, Mar 24, 2014 at 10:33 PM, Robert Marshall <robert <at> capuchin.co.uk> wrote:
> So there were, that's one error each ;-)
Yep ;-)
> I've done all 4 runs and none of them produced the bug! I assume this
> isn't what you expected
I half-expected it.
> I see some of the parameters to
> frameset-restore are different.
Not just that, I've radically simplified `frameset--restore-frame'.
So if you do not see now the bug even with (display . ":0"), that
means that we can forget for now the other parameters and concentrate
on testing only display yes/no again.
Before I change anything more, if you happen to still have a bug*.el
file from previous tests where you were able to reproduce the bug, try
it using
(frameset-restore desktop-saved-frameset
:reuse-frames t
:force-display nil
:force-onscreen nil
:cleanup-frames t)
to call frameset-restore. I expect that you will still see the bug,
but if you don't, that will be interesting by itself.
J
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Mon, 24 Mar 2014 22:44:03 GMT)
Full text and
rfc822 format available.
Message #347 received at 17046 <at> debbugs.gnu.org (full text, mbox):
Juanma Barranquero writes:
>
> Before I change anything more, if you happen to still have a bug*.el
> file from previous tests where you were able to reproduce the bug, try
> it using
>
> (frameset-restore desktop-saved-frameset
> :reuse-frames t
> :force-display nil
> :force-onscreen nil
> :cleanup-frames t)
>
> to call frameset-restore. I expect that you will still see the bug,
> but if you don't, that will be interesting by itself.
>
With those parameters I still see the bug in the bug*c.el file
R
--
Robert Marshall
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Mon, 24 Mar 2014 23:39:02 GMT)
Full text and
rfc822 format available.
Message #350 received at 17046 <at> debbugs.gnu.org (full text, mbox):
On Mon, Mar 24, 2014 at 11:43 PM, Robert Marshall <robert <at> capuchin.co.uk> wrote:
> With those parameters I still see the bug in the bug*c.el file
Great. Now, could you please try with that same bug*c.el file, but
commenting out the line
(push '(tool-bar-lines . 0) filtered-cfg)
near the top of frameset--restore-frame?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Tue, 25 Mar 2014 07:13:02 GMT)
Full text and
rfc822 format available.
Message #353 received at 17046 <at> debbugs.gnu.org (full text, mbox):
Juanma Barranquero writes:
> On Mon, Mar 24, 2014 at 11:43 PM, Robert Marshall <robert <at> capuchin.co.uk> wrote:
>
> > With those parameters I still see the bug in the bug*c.el file
>
> Great. Now, could you please try with that same bug*c.el file, but
> commenting out the line
>
> (push '(tool-bar-lines . 0) filtered-cfg)
>
> near the top of frameset--restore-frame?
>
No bug with that line commented
Robert
--
Robert Marshall
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Tue, 25 Mar 2014 10:42:02 GMT)
Full text and
rfc822 format available.
Message #356 received at 17046 <at> debbugs.gnu.org (full text, mbox):
On Tue, Mar 25, 2014 at 8:12 AM, Robert Marshall <robert <at> capuchin.co.uk> wrote:
> No bug with that line commented
That's great news! Sort of... :-(
That line's here because on some systems (Windows, among others),
(make-frame '((height . X)))
and
(modify-frame-parameters (make-frame) '((height . X)))
do not give frames of the same height (that's bug#14795).
Apparently, in your system, modifying a frame size with
(tool-bar-lines . 0) triggers a window manager (or Emacs redisplay)
bug.
If you evaluate this in emacs -Q, does it fail too?
(let* ((default-frame-alist nil)
(frame (make-frame '((width . 80) (height . 20))))
(tool-bar-lines (frame-parameter frame 'tool-bar-lines)))
(discard-input)
(read-event nil nil 2)
(modify-frame-parameters frame '((tool-bar-lines . 0) (width . 60)
(height . 25)))
(modify-frame-parameters frame `((tool-bar-lines . ,tool-bar-lines))))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Tue, 25 Mar 2014 11:10:03 GMT)
Full text and
rfc822 format available.
Message #359 received at 17046 <at> debbugs.gnu.org (full text, mbox):
Juanma Barranquero writes:
> On Tue, Mar 25, 2014 at 8:12 AM, Robert Marshall <robert <at> capuchin.co.uk> wrote:
>
> > No bug with that line commented
>
> That's great news! Sort of... :-(
>
> That line's here because on some systems (Windows, among others),
>
> (make-frame '((height . X)))
>
> and
>
> (modify-frame-parameters (make-frame) '((height . X)))
>
> do not give frames of the same height (that's bug#14795).
>
> Apparently, in your system, modifying a frame size with
> (tool-bar-lines . 0) triggers a window manager (or Emacs redisplay)
> bug.
>
> If you evaluate this in emacs -Q, does it fail too?
>
> (let* ((default-frame-alist nil)
> (frame (make-frame '((width . 80) (height . 20))))
> (tool-bar-lines (frame-parameter frame 'tool-bar-lines)))
> (discard-input)
> (read-event nil nil 2)
> (modify-frame-parameters frame '((tool-bar-lines . 0) (width . 60)
> (height . 25)))
> (modify-frame-parameters frame `((tool-bar-lines . ,tool-bar-lines))))
>
It doesn't cause the bug but if I drop those lines into a file and
load it from a -Q -l command line I then see the bug.
Sometimes when I run that elisp (from *scratch*) I see the frame come
up 80 width and it doesn't resize to 60 which seems odd (to me)
R
--
Robert Marshall
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Tue, 25 Mar 2014 12:33:02 GMT)
Full text and
rfc822 format available.
Message #362 received at 17046 <at> debbugs.gnu.org (full text, mbox):
On Tue, Mar 25, 2014 at 12:09 PM, Robert Marshall <robert <at> capuchin.co.uk> wrote:
> It doesn't cause the bug
> Sometimes when I run that elisp (from *scratch*) I see the frame come
> up 80 width and it doesn't resize to 60 which seems odd (to me)
Not my area of expertise, but I'd bet a few eurocents both of these
must be caused by a race condition of some kind, where Emacs idea of
the frame state and the window manager's idea are desynchronized.
Creating and modifying frames is relatively slow. Bug#16967 is such a
case, on Windows.
> but if I drop those lines into a file and
> load it from a -Q -l command line I then see the bug.
That's wonderful, because we have finally decoupled the bug from
framesets (which makes things easier to test).
So, at the end, the bug is that modifying the dimensions of an
existing frame with tool-bar-lines set to 0 fails. That's either a
window manager problem, or a problem in the Emacs code related to it.
Adding a workaround for frameset.el is possible, but I'd like to know
if it's possible to fix the bug for real, because any workaround is
going to be ugly; I can't just disable the current code because I'd be
trading one bug for another.
Martin, any suggestion? Anyone else who knows about this stuff?
J
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Tue, 25 Mar 2014 14:58:02 GMT)
Full text and
rfc822 format available.
Message #365 received at 17046 <at> debbugs.gnu.org (full text, mbox):
> So, at the end, the bug is that modifying the dimensions of an
> existing frame with tool-bar-lines set to 0 fails. That's either a
> window manager problem, or a problem in the Emacs code related to it.
Since Robert uses GTK the toolbar is not part of the Emacs frame. And
since IIUC the frame is not yet visible, the problem with applying the
frame size change immediately, that is without waiting for a
ConfigureNotify event, might have an impact too. Why GTK+ would drop
the frame title is still beyond my comprehension.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Tue, 25 Mar 2014 15:50:03 GMT)
Full text and
rfc822 format available.
Message #368 received at 17046 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 25 Mar 2014 15:57:27 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> Cc: 17046 <at> debbugs.gnu.org
>
> > So, at the end, the bug is that modifying the dimensions of an
> > existing frame with tool-bar-lines set to 0 fails. That's either a
> > window manager problem, or a problem in the Emacs code related to it.
>
> Since Robert uses GTK the toolbar is not part of the Emacs frame. And
> since IIUC the frame is not yet visible, the problem with applying the
> frame size change immediately, that is without waiting for a
> ConfigureNotify event, might have an impact too. Why GTK+ would drop
> the frame title is still beyond my comprehension.
Does it help to apply the size parameters only after the rest,
including the toolbar, were already applied, i.e. in a separate call
to modify-frame-parameters?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Wed, 26 Mar 2014 16:36:02 GMT)
Full text and
rfc822 format available.
Message #371 received at 17046 <at> debbugs.gnu.org (full text, mbox):
On Tue, Mar 25, 2014 at 4:48 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> Does it help to apply the size parameters only after the rest,
> including the toolbar, were already applied, i.e. in a separate call
> to modify-frame-parameters?
Do you mean to do this?
(let* ((default-frame-alist nil)
(frame (make-frame '((width . 80) (height . 20))))
(tool-bar-lines (frame-parameter frame 'tool-bar-lines)))
(discard-input)
(read-event nil nil 2)
(modify-frame-parameters frame '((tool-bar-lines . 0)))
(modify-frame-parameters frame '((width . 60) (height . 25)))
(modify-frame-parameters frame `((tool-bar-lines . ,tool-bar-lines))))
Robert, could you try this, please? (In a separate .el file, as you did before)
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Wed, 26 Mar 2014 17:08:02 GMT)
Full text and
rfc822 format available.
Message #374 received at 17046 <at> debbugs.gnu.org (full text, mbox):
Juanma Barranquero writes:
> On Tue, Mar 25, 2014 at 4:48 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > Does it help to apply the size parameters only after the rest,
> > including the toolbar, were already applied, i.e. in a separate call
> > to modify-frame-parameters?
>
> Do you mean to do this?
>
> (let* ((default-frame-alist nil)
> (frame (make-frame '((width . 80) (height . 20))))
> (tool-bar-lines (frame-parameter frame 'tool-bar-lines)))
> (discard-input)
> (read-event nil nil 2)
> (modify-frame-parameters frame '((tool-bar-lines . 0)))
> (modify-frame-parameters frame '((width . 60) (height . 25)))
> (modify-frame-parameters frame `((tool-bar-lines . ,tool-bar-lines))))
>
> Robert, could you try this, please? (In a separate .el file, as you did before)
>
I read Eli's suggestion as
(modify-frame-parameters frame `((tool-bar-lines . ,tool-bar-lines)))
(modify-frame-parameters frame '((width . 60)
(height . 25))))
which doesn't show the bug, In your order with those 2 calls swapped
around the bug is present.
Though I was also uncertain as to whether implementation internals
were being referred to.
R
--
Robert Marshall
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Wed, 26 Mar 2014 17:18:02 GMT)
Full text and
rfc822 format available.
Message #377 received at 17046 <at> debbugs.gnu.org (full text, mbox):
On Wed, Mar 26, 2014 at 6:08 PM, Robert Marshall <robert <at> capuchin.co.uk> wrote:
> I read Eli's suggestion as
>
> (modify-frame-parameters frame `((tool-bar-lines . ,tool-bar-lines)))
> (modify-frame-parameters frame '((width . 60)
> (height . 25))))
>
> which doesn't show the bug,
The local binding for tool-bar-lines in my test code is the value of
the tool-bar-lines parameter of the freshly created frame (for
example, on my system its value is 3). So the code above would not
show the bug because it is not setting tool-bar-lines to 0.
> In your order with those 2 calls swapped
> around the bug is present.
So unfortunately Eli's idea didn't work.
Does it fail/work with these additional read-event's? (To allow redisplay)
(let* ((default-frame-alist nil)
(frame (make-frame '((width . 80) (height . 20))))
(tool-bar-lines (frame-parameter frame 'tool-bar-lines)))
(discard-input)
(read-event nil nil 2)
(modify-frame-parameters frame '((tool-bar-lines . 0)))
(read-event nil nil 0.1)
(modify-frame-parameters frame '((width . 60) (height . 25)))
(read-event nil nil 0.1)
(modify-frame-parameters frame `((tool-bar-lines . ,tool-bar-lines))))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Wed, 26 Mar 2014 17:30:08 GMT)
Full text and
rfc822 format available.
Message #380 received at 17046 <at> debbugs.gnu.org (full text, mbox):
Juanma Barranquero writes:
>
> So unfortunately Eli's idea didn't work.
>
> Does it fail/work with these additional read-event's? (To allow redisplay)
>
> (let* ((default-frame-alist nil)
> (frame (make-frame '((width . 80) (height . 20))))
> (tool-bar-lines (frame-parameter frame 'tool-bar-lines)))
> (discard-input)
> (read-event nil nil 2)
> (modify-frame-parameters frame '((tool-bar-lines . 0)))
> (read-event nil nil 0.1)
> (modify-frame-parameters frame '((width . 60) (height . 25)))
> (read-event nil nil 0.1)
> (modify-frame-parameters frame `((tool-bar-lines . ,tool-bar-lines))))
>
It still fails with this code
R
--
Robert Marshall
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Wed, 26 Mar 2014 17:55:01 GMT)
Full text and
rfc822 format available.
Message #383 received at 17046 <at> debbugs.gnu.org (full text, mbox):
> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Wed, 26 Mar 2014 18:15:46 +0100
> Cc: Eli Zaretskii <eliz <at> gnu.org>, martin rudalics <rudalics <at> gmx.at>, 17046 <at> debbugs.gnu.org
>
> On Wed, Mar 26, 2014 at 6:08 PM, Robert Marshall <robert <at> capuchin.co.uk> wrote:
>
> > I read Eli's suggestion as
> >
> > (modify-frame-parameters frame `((tool-bar-lines . ,tool-bar-lines)))
> > (modify-frame-parameters frame '((width . 60)
> > (height . 25))))
> >
> > which doesn't show the bug,
>
> The local binding for tool-bar-lines in my test code is the value of
> the tool-bar-lines parameter of the freshly created frame (for
> example, on my system its value is 3). So the code above would not
> show the bug because it is not setting tool-bar-lines to 0.
>
> > In your order with those 2 calls swapped
> > around the bug is present.
>
> So unfortunately Eli's idea didn't work.
My idea was what Robert did. So it did work ;-)
Is it for some reason unworkable to have the size change after all the
rest?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Wed, 26 Mar 2014 18:20:03 GMT)
Full text and
rfc822 format available.
Message #386 received at 17046 <at> debbugs.gnu.org (full text, mbox):
On Wed, Mar 26, 2014 at 6:54 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> My idea was what Robert did. So it did work ;-)
Oh :-)
But that's equivalent to just skipping all the hoopla with
tool-bar-lines. You're setting it to 0, then to the correct value, and
then modifying the frame.
> Is it for some reason unworkable to have the size change after all the
> rest?
Presumably, that would break the fix for bug#14795.
OTOH, though the bug still real, i.e.,
(modify-frame-parameters (make-frame) '((height . X)))
and
(make-frame '((height . X)))
give frames of different size, now I cannot reproduce the problem when
restoring frames with frameset-restore *without* my workaround.
I think there's been some changes related to frames and the like, so
it is possible that the workaround can simply be removed and this
problem just disappears. We would still have a bug with GTK builds and
tool-bar-lines = 0, but it would be of much lesser impact.
Allow me a few hours to test things thoroughly.
J
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Wed, 26 Mar 2014 19:14:02 GMT)
Full text and
rfc822 format available.
Message #389 received at 17046 <at> debbugs.gnu.org (full text, mbox):
Juanma Barranquero writes:
> On Wed, Mar 26, 2014 at 6:54 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > My idea was what Robert did. So it did work ;-)
>
> Oh :-)
>
I'm glad I put in both options!
> But that's equivalent to just skipping all the hoopla with
> tool-bar-lines. You're setting it to 0, then to the correct value, and
> then modifying the frame.
>
> > Is it for some reason unworkable to have the size change after all the
> > rest?
>
> Presumably, that would break the fix for bug#14795.
>
> OTOH, though the bug still real, i.e.,
>
> (modify-frame-parameters (make-frame) '((height . X)))
>
> and
>
> (make-frame '((height . X)))
>
> give frames of different size, now I cannot reproduce the problem when
> restoring frames with frameset-restore *without* my workaround.
>
> I think there's been some changes related to frames and the like, so
> it is possible that the workaround can simply be removed and this
> problem just disappears. We would still have a bug with GTK builds and
> tool-bar-lines = 0, but it would be of much lesser impact.
>
> Allow me a few hours to test things thoroughly.
>
Should I be updating my pull from bzr? (if only to keep in sync with you)
Robert
--
Robert Marshall
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Wed, 26 Mar 2014 20:20:01 GMT)
Full text and
rfc822 format available.
Message #392 received at 17046 <at> debbugs.gnu.org (full text, mbox):
On Wed, Mar 26, 2014 at 8:14 PM, Robert Marshall <robert <at> capuchin.co.uk> wrote:
> I'm glad I put in both options!
Yep :-)
> Should I be updating my pull from bzr? (if only to keep in sync with you)
Yes, thanks.
J
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Wed, 26 Mar 2014 22:59:02 GMT)
Full text and
rfc822 format available.
Message #395 received at 17046 <at> debbugs.gnu.org (full text, mbox):
Juanma Barranquero writes:
> On Wed, Mar 26, 2014 at 8:14 PM, Robert Marshall <robert <at> capuchin.co.uk> wrote:
> > Should I be updating my pull from bzr? (if only to keep in sync with you)
>
> Yes, thanks.
>
Did that, built (with just a make) and got Invalid read syntax ")" on dired-aux
so I then tried make bootstrap and get
.....
make[3]: Entering directory `/home/robert/emacs-bzr/lisp'
EMACSLOADPATH= '../src/bootstrap-emacs' -batch --no-site-file --no-site-lisp -l autoload \
--eval "(setq generate-autoload-cookie \";;;###cal-autoload\")" \
--eval "(setq generated-autoload-file (expand-file-name (unmsys--file-name \"calendar/cal-loaddefs.el\")))" \
-f batch-update-autoloads ./calendar
Wrote /home/robert/emacs-bzr/lisp/calendar/cal-loaddefs.el
Eager macro-expansion failure: (invalid-read-syntax ")")
Eager macro-expansion failure: (invalid-read-syntax ")")
..... lots more of these
..... ending with
Eager macro-expansion failure: (invalid-read-syntax ")")
Eager macro-expansion failure: (invalid-read-syntax ")")
Eager macro-expansion failure: (invalid-read-syntax ")")
Wrote /home/robert/emacs-bzr/lisp/calendar/cal-loaddefs.el
Eager macro-expansion failure: (invalid-read-syntax ")")
Eager macro-expansion failure: (invalid-read-syntax ")")
Eager macro-expansion failure: (invalid-read-syntax ")")
Eager macro-expansion failure: (invalid-read-syntax ")")
Eager macro-expansion failure: (invalid-read-syntax ")")
Eager macro-expansion failure: (invalid-read-syntax ")")
Eager macro-expansion failure: (invalid-read-syntax ")")
Loading macroexp.elc...
Invalid read syntax: ")"
make[3]: *** [calendar/cal-loaddefs.el] Error 255
make[3]: Leaving directory `/home/robert/emacs-bzr/lisp'
make[2]: *** [../lisp/loaddefs.el] Error 2
make[2]: Leaving directory `/home/robert/emacs-bzr/src'
make[1]: *** [src] Error 2
make[1]: Leaving directory `/home/robert/emacs-bzr'
make: *** [bootstrap] Error 2
Do you want a separate bug report? Or is there something obvious I've missed?
Robert
--
Robert Marshall
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Wed, 26 Mar 2014 23:01:01 GMT)
Full text and
rfc822 format available.
Message #398 received at 17046 <at> debbugs.gnu.org (full text, mbox):
On Wed, Mar 26, 2014 at 11:58 PM, Robert Marshall <robert <at> capuchin.co.uk> wrote:
> Do you want a separate bug report? Or is there something obvious I've missed?
Bootstrap failures are usually noticed quite soon. Was this the trunk
or the emacs-24 branch?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Wed, 26 Mar 2014 23:07:02 GMT)
Full text and
rfc822 format available.
Message #401 received at 17046 <at> debbugs.gnu.org (full text, mbox):
On Wed, Mar 26, 2014 at 7:19 PM, Juanma Barranquero <lekktu <at> gmail.com> wrote:
> I think there's been some changes related to frames and the like, so
> it is possible that the workaround can simply be removed and this
> problem just disappears. We would still have a bug with GTK builds and
> tool-bar-lines = 0, but it would be of much lesser impact.
OK, now I understand.
I originally added the tool-bar-lines stuff as a workaround for
bug#14795, which affects only newly created frames. That means that if
the frameset has a (height . 20) parameter for frame A, when restoring
the frameset, reusing a frame for A would work, but in case reusing
failed (no suitable frame found), A would be created with more than 20
lines (23 on Windows, for example). So the tool-bar-lines fix, to get
A back to 20 lines.
For several reasons related to offscreen frames, it turns out when a
new frame is needed, frameset-restore creates it invisible and
onscreen, and then reapplies its frame parameters and turns it visible
(if required). Which means that every new frame (the ones affected by
bug#14795) is already resized to the correct height while invisible,
regardless of whether it was the right height or not to start with.
In other words, I can remove the workaround for bug#14795 because it
is unnecessary now.
The GTK bug with (tool-bar-lines . 0) should be filed as a new bug,
IMHO, perhaps with a pointer to this one.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Thu, 27 Mar 2014 01:00:04 GMT)
Full text and
rfc822 format available.
Message #404 received at 17046 <at> debbugs.gnu.org (full text, mbox):
On Wed, Mar 26, 2014 at 11:58 PM, Robert Marshall <robert <at> capuchin.co.uk> wrote:
> Did that, built (with just a make) and got Invalid read syntax ")" on dired-aux
> so I then tried make bootstrap and get
>
> .....
> Eager macro-expansion failure: (invalid-read-syntax ")")
I just bootstrapped both trunk and emacs-24 without any trouble.
Perhaps it is a POSIX-specific failure.
I'd suggest cleaning up the workspace (with bzr clean-tree),
reconfiguring and bootstrapping again.
J
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17046; Package
emacs.
(Thu, 27 Mar 2014 07:16:02 GMT)
Full text and
rfc822 format available.
Message #407 received at 17046 <at> debbugs.gnu.org (full text, mbox):
Juanma Barranquero writes:
> On Wed, Mar 26, 2014 at 11:58 PM, Robert Marshall <robert <at> capuchin.co.uk> wrote:
>
> > Did that, built (with just a make) and got Invalid read syntax ")" on dired-aux
> > so I then tried make bootstrap and get
> >
> > .....
> > Eager macro-expansion failure: (invalid-read-syntax ")")
>
> I just bootstrapped both trunk and emacs-24 without any trouble.
> Perhaps it is a POSIX-specific failure.
Thanks for doing that check - I assume as I've not done anything
special (that's emacs-24 orientated) that I'm on the trunk.
>
> I'd suggest cleaning up the workspace (with bzr clean-tree),
> reconfiguring and bootstrapping again.
>
Did
bzr pull
bzr clean-tree (and 'y' to delete of various files)
./configure
make bootstrap
And still get
Saving file /home/robert/emacs-bzr/lisp/calendar/cal-loaddefs.el...
Eager macro-expansion failure: (invalid-read-syntax ")")
......
Eager macro-expansion failure: (invalid-read-syntax ")")
Wrote /home/robert/emacs-bzr/lisp/calendar/cal-loaddefs.el
Eager macro-expansion failure: (invalid-read-syntax ")")
.......
Loading macroexp.elc...
Invalid read syntax: ")"
make[3]: *** [calendar/cal-loaddefs.el] Error 255
Looking back in the make I see
../lisp/minibuffer.el: `with-wrapper-hook' is an obsolete macro (as of 24.4); use a <foo>-function variable modified by `add-function'.
Loading /home/robert/emacs-bzr/lisp/abbrev.el (source)...
../lisp/abbrev.el: `with-wrapper-hook' is an obsolete macro (as of 24.4); use a <foo>-function variable modified by `add-function'.
Loading /home/robert/emacs-bzr/lisp/simple.el (source)...
../lisp/simple.el: `with-wrapper-hook' is an obsolete macro (as of 24.4); use a <foo>-function variable modified by `add-function'.
Not sure whether those messages are expected.
Robert
--
Robert Marshall
Reply sent
to
Juanma Barranquero <lekktu <at> gmail.com>:
You have taken responsibility.
(Thu, 27 Mar 2014 15:08:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Robert Marshall <robert <at> capuchin.co.uk>:
bug acknowledged by developer.
(Thu, 27 Mar 2014 15:08:03 GMT)
Full text and
rfc822 format available.
Message #412 received at 17046-done <at> debbugs.gnu.org (full text, mbox):
Version: 24.4
On Thu, Mar 27, 2014 at 12:05 AM, Juanma Barranquero <lekktu <at> gmail.com> wrote:
> In other words, I can remove the workaround for bug#14795 because it
> is unnecessary now.
Robert confirms that the change currently committed to the release
branch fixes the original problem (bad frames when restoring Emacs
from desktop) so I'm closing this report.
> The GTK bug with (tool-bar-lines . 0) should be filed as a new bug,
> IMHO, perhaps with a pointer to this one.
I'll do that.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Fri, 25 Apr 2014 11:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 10 years and 13 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.