* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations @ 2014-03-20 9:08 Robert Marshall 2014-03-20 9:52 ` martin rudalics 2014-03-20 12:24 ` Juanma Barranquero 0 siblings, 2 replies; 135+ messages in thread From: Robert Marshall @ 2014-03-20 9:08 UTC (permalink / raw) To: 17046 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@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) ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-20 9:08 bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations Robert Marshall @ 2014-03-20 9:52 ` martin rudalics 2014-03-20 12:22 ` Robert Marshall 2014-03-20 12:24 ` Juanma Barranquero 1 sibling, 1 reply; 135+ messages in thread From: martin rudalics @ 2014-03-20 9:52 UTC (permalink / raw) To: Robert Marshall; +Cc: 17046 > 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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-20 9:52 ` martin rudalics @ 2014-03-20 12:22 ` Robert Marshall 2014-03-20 13:08 ` martin rudalics 0 siblings, 1 reply; 135+ messages in thread From: Robert Marshall @ 2014-03-20 12:22 UTC (permalink / raw) To: martin rudalics; +Cc: 17046 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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-20 12:22 ` Robert Marshall @ 2014-03-20 13:08 ` martin rudalics 2014-03-20 14:28 ` Robert Marshall 0 siblings, 1 reply; 135+ messages in thread From: martin rudalics @ 2014-03-20 13:08 UTC (permalink / raw) To: Robert Marshall; +Cc: 17046 > 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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-20 13:08 ` martin rudalics @ 2014-03-20 14:28 ` Robert Marshall 2014-03-20 19:23 ` martin rudalics 0 siblings, 1 reply; 135+ messages in thread From: Robert Marshall @ 2014-03-20 14:28 UTC (permalink / raw) To: martin rudalics; +Cc: 17046 [-- Attachment #1: message body text --] [-- Type: text/plain, Size: 952 bytes --] 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 [-- Attachment #2: emacs frames --] [-- Type: image/png, Size: 327395 bytes --] [-- Attachment #3: message body and .signature --] [-- Type: text/plain, Size: 835 bytes --] 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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-20 14:28 ` Robert Marshall @ 2014-03-20 19:23 ` martin rudalics 2014-03-20 20:25 ` Robert Marshall 0 siblings, 1 reply; 135+ messages in thread From: martin rudalics @ 2014-03-20 19:23 UTC (permalink / raw) To: Robert Marshall; +Cc: 17046 > > 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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-20 19:23 ` martin rudalics @ 2014-03-20 20:25 ` Robert Marshall 2014-03-20 20:37 ` Juanma Barranquero 2014-03-21 8:03 ` martin rudalics 0 siblings, 2 replies; 135+ messages in thread From: Robert Marshall @ 2014-03-20 20:25 UTC (permalink / raw) To: martin rudalics; +Cc: 17046 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@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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-20 20:25 ` Robert Marshall @ 2014-03-20 20:37 ` Juanma Barranquero 2014-03-20 20:51 ` Robert Marshall 2014-03-21 8:02 ` martin rudalics 2014-03-21 8:03 ` martin rudalics 1 sibling, 2 replies; 135+ messages in thread From: Juanma Barranquero @ 2014-03-20 20:37 UTC (permalink / raw) To: Robert Marshall; +Cc: 17046 On Thu, Mar 20, 2014 at 9:25 PM, Robert Marshall <robert@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@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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-20 20:37 ` Juanma Barranquero @ 2014-03-20 20:51 ` Robert Marshall 2014-03-20 20:59 ` Juanma Barranquero 2014-03-21 8:02 ` martin rudalics 1 sibling, 1 reply; 135+ messages in thread From: Robert Marshall @ 2014-03-20 20:51 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 17046 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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-20 20:51 ` Robert Marshall @ 2014-03-20 20:59 ` Juanma Barranquero 0 siblings, 0 replies; 135+ messages in thread From: Juanma Barranquero @ 2014-03-20 20:59 UTC (permalink / raw) To: Robert Marshall; +Cc: 17046 On Thu, Mar 20, 2014 at 9:51 PM, Robert Marshall <robert@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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-20 20:37 ` Juanma Barranquero 2014-03-20 20:51 ` Robert Marshall @ 2014-03-21 8:02 ` martin rudalics 1 sibling, 0 replies; 135+ messages in thread From: martin rudalics @ 2014-03-21 8:02 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 17046, Robert Marshall > [frameset > 1 > (21291 19570 712781 440000) > (desktop . "206") > "robert@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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-20 20:25 ` Robert Marshall 2014-03-20 20:37 ` Juanma Barranquero @ 2014-03-21 8:03 ` martin rudalics [not found] ` <21292.6903.499178.348@capuchin.co.uk> 2014-03-23 16:07 ` Robert Marshall 1 sibling, 2 replies; 135+ messages in thread From: martin rudalics @ 2014-03-21 8:03 UTC (permalink / raw) To: Robert Marshall; +Cc: 17046 > 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 ^ permalink raw reply [flat|nested] 135+ messages in thread
[parent not found: <21292.6903.499178.348@capuchin.co.uk>]
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations [not found] ` <21292.6903.499178.348@capuchin.co.uk> @ 2014-03-21 15:07 ` martin rudalics 2014-03-21 16:53 ` Robert Marshall 0 siblings, 1 reply; 135+ messages in thread From: martin rudalics @ 2014-03-21 15:07 UTC (permalink / raw) To: Robert Marshall; +Cc: 17046 > > 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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-21 15:07 ` martin rudalics @ 2014-03-21 16:53 ` Robert Marshall 2014-03-21 17:42 ` martin rudalics 0 siblings, 1 reply; 135+ messages in thread From: Robert Marshall @ 2014-03-21 16:53 UTC (permalink / raw) To: martin rudalics; +Cc: 17046 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@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@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@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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-21 16:53 ` Robert Marshall @ 2014-03-21 17:42 ` martin rudalics 2014-03-22 1:53 ` Juanma Barranquero 0 siblings, 1 reply; 135+ messages in thread From: martin rudalics @ 2014-03-21 17:42 UTC (permalink / raw) To: Robert Marshall; +Cc: 17046 > 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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-21 17:42 ` martin rudalics @ 2014-03-22 1:53 ` Juanma Barranquero 2014-03-22 9:40 ` martin rudalics 2014-03-22 16:56 ` Robert Marshall 0 siblings, 2 replies; 135+ messages in thread From: Juanma Barranquero @ 2014-03-22 1:53 UTC (permalink / raw) To: martin rudalics; +Cc: 17046, Robert Marshall On Fri, Mar 21, 2014 at 6:42 PM, martin rudalics <rudalics@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. ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-22 1:53 ` Juanma Barranquero @ 2014-03-22 9:40 ` martin rudalics 2014-03-22 11:35 ` Robert Marshall 2014-03-22 16:56 ` Robert Marshall 1 sibling, 1 reply; 135+ messages in thread From: martin rudalics @ 2014-03-22 9:40 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 17046, Robert Marshall > 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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-22 9:40 ` martin rudalics @ 2014-03-22 11:35 ` Robert Marshall 2014-03-22 13:44 ` martin rudalics 0 siblings, 1 reply; 135+ messages in thread From: Robert Marshall @ 2014-03-22 11:35 UTC (permalink / raw) To: martin rudalics; +Cc: Juanma Barranquero, 17046 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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-22 11:35 ` Robert Marshall @ 2014-03-22 13:44 ` martin rudalics 2014-03-22 14:02 ` Juanma Barranquero 0 siblings, 1 reply; 135+ messages in thread From: martin rudalics @ 2014-03-22 13:44 UTC (permalink / raw) To: Robert Marshall; +Cc: Juanma Barranquero, 17046 >> > 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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-22 13:44 ` martin rudalics @ 2014-03-22 14:02 ` Juanma Barranquero 2014-03-22 14:20 ` martin rudalics 0 siblings, 1 reply; 135+ messages in thread From: Juanma Barranquero @ 2014-03-22 14:02 UTC (permalink / raw) To: martin rudalics; +Cc: 17046, Robert Marshall [-- Attachment #1: Type: text/plain, Size: 1774 bytes --] On Sat, Mar 22, 2014 at 2:44 PM, martin rudalics <rudalics@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 [-- Attachment #2: bug17046.el --] [-- Type: application/octet-stream, Size: 3638 bytes --] ;;; bug17046.el ;;; (setq desktop-saved-frameset [frameset 1 (21292 27934 99775 17000) (desktop . "206") "robert@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))))]) (frameset-restore desktop-saved-frameset :reuse-frames t :cleanup-frames t :force-onscreen t) ;;; end ;;; ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-22 14:02 ` Juanma Barranquero @ 2014-03-22 14:20 ` martin rudalics 2014-03-22 14:33 ` Juanma Barranquero 0 siblings, 1 reply; 135+ messages in thread From: martin rudalics @ 2014-03-22 14:20 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 17046, Robert Marshall > 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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-22 14:20 ` martin rudalics @ 2014-03-22 14:33 ` Juanma Barranquero 2014-03-22 15:20 ` martin rudalics 0 siblings, 1 reply; 135+ messages in thread From: Juanma Barranquero @ 2014-03-22 14:33 UTC (permalink / raw) To: martin rudalics; +Cc: 17046, Robert Marshall On Sat, Mar 22, 2014 at 3:20 PM, martin rudalics <rudalics@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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-22 14:33 ` Juanma Barranquero @ 2014-03-22 15:20 ` martin rudalics 2014-03-22 15:26 ` Juanma Barranquero 0 siblings, 1 reply; 135+ messages in thread From: martin rudalics @ 2014-03-22 15:20 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 17046, Robert Marshall > 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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-22 15:20 ` martin rudalics @ 2014-03-22 15:26 ` Juanma Barranquero 2014-03-22 15:33 ` martin rudalics 0 siblings, 1 reply; 135+ messages in thread From: Juanma Barranquero @ 2014-03-22 15:26 UTC (permalink / raw) To: martin rudalics; +Cc: 17046, Robert Marshall On Sat, Mar 22, 2014 at 4:20 PM, martin rudalics <rudalics@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? ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-22 15:26 ` Juanma Barranquero @ 2014-03-22 15:33 ` martin rudalics 2014-03-22 16:28 ` Robert Marshall 0 siblings, 1 reply; 135+ messages in thread From: martin rudalics @ 2014-03-22 15:33 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 17046, Robert Marshall > I'm lost. Why wouldn't it work to call (sit-for 0) before calling > frameset-restore? Robert can you do that? martin ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-22 15:33 ` martin rudalics @ 2014-03-22 16:28 ` Robert Marshall 2014-03-22 16:38 ` Juanma Barranquero 2014-03-22 18:43 ` martin rudalics 0 siblings, 2 replies; 135+ messages in thread From: Robert Marshall @ 2014-03-22 16:28 UTC (permalink / raw) To: martin rudalics; +Cc: Juanma Barranquero, 17046 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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-22 16:28 ` Robert Marshall @ 2014-03-22 16:38 ` Juanma Barranquero 2014-03-22 17:00 ` Robert Marshall 2014-03-22 18:36 ` Robert Marshall 2014-03-22 18:43 ` martin rudalics 1 sibling, 2 replies; 135+ messages in thread From: Juanma Barranquero @ 2014-03-22 16:38 UTC (permalink / raw) To: Robert Marshall; +Cc: 17046 On Sat, Mar 22, 2014 at 5:28 PM, Robert Marshall <robert@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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-22 16:38 ` Juanma Barranquero @ 2014-03-22 17:00 ` Robert Marshall 2014-03-22 17:34 ` Juanma Barranquero 2014-03-22 18:36 ` Robert Marshall 1 sibling, 1 reply; 135+ messages in thread From: Robert Marshall @ 2014-03-22 17:00 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 17046 Juanma Barranquero writes: > On Sat, Mar 22, 2014 at 5:28 PM, Robert Marshall <robert@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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-22 17:00 ` Robert Marshall @ 2014-03-22 17:34 ` Juanma Barranquero 0 siblings, 0 replies; 135+ messages in thread From: Juanma Barranquero @ 2014-03-22 17:34 UTC (permalink / raw) To: Robert Marshall; +Cc: 17046 On Sat, Mar 22, 2014 at 6:00 PM, Robert Marshall <robert@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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-22 16:38 ` Juanma Barranquero 2014-03-22 17:00 ` Robert Marshall @ 2014-03-22 18:36 ` Robert Marshall 2014-03-22 19:09 ` Juanma Barranquero 2014-03-22 19:18 ` martin rudalics 1 sibling, 2 replies; 135+ messages in thread From: Robert Marshall @ 2014-03-22 18:36 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 17046 Juanma Barranquero writes: > On Sat, Mar 22, 2014 at 5:28 PM, Robert Marshall <robert@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@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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-22 18:36 ` Robert Marshall @ 2014-03-22 19:09 ` Juanma Barranquero 2014-03-22 19:18 ` martin rudalics 1 sibling, 0 replies; 135+ messages in thread From: Juanma Barranquero @ 2014-03-22 19:09 UTC (permalink / raw) To: Robert Marshall; +Cc: 17046 On Sat, Mar 22, 2014 at 7:36 PM, Robert Marshall <robert@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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-22 18:36 ` Robert Marshall 2014-03-22 19:09 ` Juanma Barranquero @ 2014-03-22 19:18 ` martin rudalics 2014-03-22 19:22 ` Juanma Barranquero 1 sibling, 1 reply; 135+ messages in thread From: martin rudalics @ 2014-03-22 19:18 UTC (permalink / raw) To: Robert Marshall, Juanma Barranquero; +Cc: 17046 [-- Attachment #1: Type: text/plain, Size: 450 bytes --] > 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 [-- Attachment #2: bug17046.el --] [-- Type: application/emacs-lisp, Size: 3104 bytes --] ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-22 19:18 ` martin rudalics @ 2014-03-22 19:22 ` Juanma Barranquero 0 siblings, 0 replies; 135+ messages in thread From: Juanma Barranquero @ 2014-03-22 19:22 UTC (permalink / raw) To: martin rudalics; +Cc: 17046, Robert Marshall On Sat, Mar 22, 2014 at 8:18 PM, martin rudalics <rudalics@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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-22 16:28 ` Robert Marshall 2014-03-22 16:38 ` Juanma Barranquero @ 2014-03-22 18:43 ` martin rudalics 2014-03-22 19:17 ` Juanma Barranquero 1 sibling, 1 reply; 135+ messages in thread From: martin rudalics @ 2014-03-22 18:43 UTC (permalink / raw) To: Robert Marshall; +Cc: Juanma Barranquero, 17046 > 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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-22 18:43 ` martin rudalics @ 2014-03-22 19:17 ` Juanma Barranquero 2014-03-22 19:34 ` martin rudalics 0 siblings, 1 reply; 135+ messages in thread From: Juanma Barranquero @ 2014-03-22 19:17 UTC (permalink / raw) To: martin rudalics; +Cc: 17046, Robert Marshall On Sat, Mar 22, 2014 at 7:43 PM, martin rudalics <rudalics@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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-22 19:17 ` Juanma Barranquero @ 2014-03-22 19:34 ` martin rudalics 2014-03-22 20:17 ` Robert Marshall 0 siblings, 1 reply; 135+ messages in thread From: martin rudalics @ 2014-03-22 19:34 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 17046, Robert Marshall > 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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-22 19:34 ` martin rudalics @ 2014-03-22 20:17 ` Robert Marshall 2014-03-22 21:17 ` Juanma Barranquero 2014-03-22 21:35 ` martin rudalics 0 siblings, 2 replies; 135+ messages in thread From: Robert Marshall @ 2014-03-22 20:17 UTC (permalink / raw) To: martin rudalics; +Cc: Juanma Barranquero, 17046 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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-22 20:17 ` Robert Marshall @ 2014-03-22 21:17 ` Juanma Barranquero 2014-03-22 21:35 ` martin rudalics 2014-03-22 21:35 ` martin rudalics 1 sibling, 1 reply; 135+ messages in thread From: Juanma Barranquero @ 2014-03-22 21:17 UTC (permalink / raw) To: Robert Marshall; +Cc: 17046 On Sat, Mar 22, 2014 at 9:17 PM, Robert Marshall <robert@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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-22 21:17 ` Juanma Barranquero @ 2014-03-22 21:35 ` martin rudalics 0 siblings, 0 replies; 135+ messages in thread From: martin rudalics @ 2014-03-22 21:35 UTC (permalink / raw) To: Juanma Barranquero, Robert Marshall; +Cc: 17046 >> 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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-22 20:17 ` Robert Marshall 2014-03-22 21:17 ` Juanma Barranquero @ 2014-03-22 21:35 ` martin rudalics 2014-03-22 21:42 ` Juanma Barranquero 2014-03-22 22:10 ` Robert Marshall 1 sibling, 2 replies; 135+ messages in thread From: martin rudalics @ 2014-03-22 21:35 UTC (permalink / raw) To: Robert Marshall; +Cc: Juanma Barranquero, 17046 > 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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-22 21:35 ` martin rudalics @ 2014-03-22 21:42 ` Juanma Barranquero 2014-03-22 22:16 ` Robert Marshall 2014-03-22 22:10 ` Robert Marshall 1 sibling, 1 reply; 135+ messages in thread From: Juanma Barranquero @ 2014-03-22 21:42 UTC (permalink / raw) To: martin rudalics; +Cc: 17046, Robert Marshall On Sat, Mar 22, 2014 at 10:35 PM, martin rudalics <rudalics@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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-22 21:42 ` Juanma Barranquero @ 2014-03-22 22:16 ` Robert Marshall 2014-03-23 10:11 ` martin rudalics 0 siblings, 1 reply; 135+ messages in thread From: Robert Marshall @ 2014-03-22 22:16 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 17046 Juanma Barranquero writes: > On Sat, Mar 22, 2014 at 10:35 PM, martin rudalics <rudalics@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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-22 22:16 ` Robert Marshall @ 2014-03-23 10:11 ` martin rudalics 2014-03-23 11:14 ` Robert Marshall 0 siblings, 1 reply; 135+ messages in thread From: martin rudalics @ 2014-03-23 10:11 UTC (permalink / raw) To: Robert Marshall, Juanma Barranquero; +Cc: 17046 > 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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-23 10:11 ` martin rudalics @ 2014-03-23 11:14 ` Robert Marshall 2014-03-23 11:39 ` martin rudalics 0 siblings, 1 reply; 135+ messages in thread From: Robert Marshall @ 2014-03-23 11:14 UTC (permalink / raw) To: martin rudalics; +Cc: Juanma Barranquero, 17046 [-- Attachment #1: message body text --] [-- Type: text/plain, Size: 470 bytes --] 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. > [-- Attachment #2: startup file --] [-- Type: application/octet-stream, Size: 3254 bytes --] ;;; bug17046.el with two windows ;;; (read-event nil nil 1) ;(sit-for 0) (find-file "~/.emacs") (find-file "/home/robert/devel/amarok/src/context/applets/wikipedia/WikipediaApplet.cpp") (setq desktop-saved-frameset [frameset 1 (21291 19570 712781 440000) (desktop . "206") "robert@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 . t) (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)))))]) (frameset-restore desktop-saved-frameset :reuse-frames t :cleanup-frames t :force-onscreen t) ;;; end ;;; [-- Attachment #3: message body and .signature --] [-- Type: text/plain, Size: 363 bytes --] 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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-23 11:14 ` Robert Marshall @ 2014-03-23 11:39 ` martin rudalics 2014-03-23 12:13 ` Robert Marshall 2014-03-23 13:39 ` Robert Marshall 0 siblings, 2 replies; 135+ messages in thread From: martin rudalics @ 2014-03-23 11:39 UTC (permalink / raw) To: Robert Marshall; +Cc: Juanma Barranquero, 17046 [-- Attachment #1: Type: text/plain, Size: 417 bytes --] > 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 [-- Attachment #2: bug17046-b.el --] [-- Type: application/emacs-lisp, Size: 3365 bytes --] ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-23 11:39 ` martin rudalics @ 2014-03-23 12:13 ` Robert Marshall 2014-03-23 13:39 ` Robert Marshall 1 sibling, 0 replies; 135+ messages in thread From: Robert Marshall @ 2014-03-23 12:13 UTC (permalink / raw) To: martin rudalics; +Cc: Juanma Barranquero, 17046 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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-23 11:39 ` martin rudalics 2014-03-23 12:13 ` Robert Marshall @ 2014-03-23 13:39 ` Robert Marshall 2014-03-23 13:51 ` martin rudalics 1 sibling, 1 reply; 135+ messages in thread From: Robert Marshall @ 2014-03-23 13:39 UTC (permalink / raw) To: martin rudalics; +Cc: Juanma Barranquero, 17046 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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-23 13:39 ` Robert Marshall @ 2014-03-23 13:51 ` martin rudalics 2014-03-23 14:11 ` martin rudalics 2014-03-23 14:30 ` Robert Marshall 0 siblings, 2 replies; 135+ messages in thread From: martin rudalics @ 2014-03-23 13:51 UTC (permalink / raw) To: Robert Marshall; +Cc: Juanma Barranquero, 17046 [-- Attachment #1: Type: text/plain, Size: 445 bytes --] > 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 [-- Attachment #2: bug17046-b.el --] [-- Type: application/emacs-lisp, Size: 1162 bytes --] ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-23 13:51 ` martin rudalics @ 2014-03-23 14:11 ` martin rudalics 2014-03-23 14:30 ` Robert Marshall 1 sibling, 0 replies; 135+ messages in thread From: martin rudalics @ 2014-03-23 14:11 UTC (permalink / raw) To: 17046 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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-23 13:51 ` martin rudalics 2014-03-23 14:11 ` martin rudalics @ 2014-03-23 14:30 ` Robert Marshall 2014-03-23 14:55 ` martin rudalics 1 sibling, 1 reply; 135+ messages in thread From: Robert Marshall @ 2014-03-23 14:30 UTC (permalink / raw) To: martin rudalics; +Cc: Juanma Barranquero, 17046 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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-23 14:30 ` Robert Marshall @ 2014-03-23 14:55 ` martin rudalics 2014-03-23 15:03 ` martin rudalics 2014-03-23 15:17 ` Robert Marshall 0 siblings, 2 replies; 135+ messages in thread From: martin rudalics @ 2014-03-23 14:55 UTC (permalink / raw) To: Robert Marshall; +Cc: Juanma Barranquero, 17046 [-- Attachment #1: Type: text/plain, Size: 611 bytes --] > 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 [-- Attachment #2: bug17046-c.el --] [-- Type: application/emacs-lisp, Size: 1266 bytes --] ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-23 14:55 ` martin rudalics @ 2014-03-23 15:03 ` martin rudalics 2014-03-23 15:34 ` Robert Marshall 2014-03-23 15:17 ` Robert Marshall 1 sibling, 1 reply; 135+ messages in thread From: martin rudalics @ 2014-03-23 15:03 UTC (permalink / raw) To: Robert Marshall; +Cc: Juanma Barranquero, 17046 [-- Attachment #1: Type: text/plain, Size: 62 bytes --] And please try the attached single window frame too. martin [-- Attachment #2: bug17046-d.el --] [-- Type: application/emacs-lisp, Size: 952 bytes --] ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-23 15:03 ` martin rudalics @ 2014-03-23 15:34 ` Robert Marshall 0 siblings, 0 replies; 135+ messages in thread From: Robert Marshall @ 2014-03-23 15:34 UTC (permalink / raw) To: martin rudalics; +Cc: Juanma Barranquero, 17046 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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-23 14:55 ` martin rudalics 2014-03-23 15:03 ` martin rudalics @ 2014-03-23 15:17 ` Robert Marshall 2014-03-23 15:28 ` martin rudalics 1 sibling, 1 reply; 135+ messages in thread From: Robert Marshall @ 2014-03-23 15:17 UTC (permalink / raw) To: martin rudalics; +Cc: Juanma Barranquero, 17046 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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-23 15:17 ` Robert Marshall @ 2014-03-23 15:28 ` martin rudalics 2014-03-23 16:10 ` Robert Marshall 0 siblings, 1 reply; 135+ messages in thread From: martin rudalics @ 2014-03-23 15:28 UTC (permalink / raw) To: Robert Marshall; +Cc: Juanma Barranquero, 17046 > 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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-23 15:28 ` martin rudalics @ 2014-03-23 16:10 ` Robert Marshall 2014-03-23 16:37 ` Juanma Barranquero 2014-03-23 16:50 ` martin rudalics 0 siblings, 2 replies; 135+ messages in thread From: Robert Marshall @ 2014-03-23 16:10 UTC (permalink / raw) To: martin rudalics; +Cc: Juanma Barranquero, 17046 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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-23 16:10 ` Robert Marshall @ 2014-03-23 16:37 ` Juanma Barranquero 2014-03-23 16:57 ` martin rudalics 2014-03-23 17:07 ` Robert Marshall 2014-03-23 16:50 ` martin rudalics 1 sibling, 2 replies; 135+ messages in thread From: Juanma Barranquero @ 2014-03-23 16:37 UTC (permalink / raw) To: Robert Marshall; +Cc: 17046 On Sun, Mar 23, 2014 at 5:10 PM, Robert Marshall <robert@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...). ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-23 16:37 ` Juanma Barranquero @ 2014-03-23 16:57 ` martin rudalics 2014-03-23 17:19 ` martin rudalics 2014-03-23 17:07 ` Robert Marshall 1 sibling, 1 reply; 135+ messages in thread From: martin rudalics @ 2014-03-23 16:57 UTC (permalink / raw) To: Juanma Barranquero, Robert Marshall; +Cc: 17046 > 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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-23 16:57 ` martin rudalics @ 2014-03-23 17:19 ` martin rudalics 0 siblings, 0 replies; 135+ messages in thread From: martin rudalics @ 2014-03-23 17:19 UTC (permalink / raw) To: Juanma Barranquero, Robert Marshall; +Cc: 17046 > 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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-23 16:37 ` Juanma Barranquero 2014-03-23 16:57 ` martin rudalics @ 2014-03-23 17:07 ` Robert Marshall 1 sibling, 0 replies; 135+ messages in thread From: Robert Marshall @ 2014-03-23 17:07 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 17046 Juanma Barranquero writes: > On Sun, Mar 23, 2014 at 5:10 PM, Robert Marshall <robert@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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-23 16:10 ` Robert Marshall 2014-03-23 16:37 ` Juanma Barranquero @ 2014-03-23 16:50 ` martin rudalics 2014-03-23 17:11 ` Robert Marshall 1 sibling, 1 reply; 135+ messages in thread From: martin rudalics @ 2014-03-23 16:50 UTC (permalink / raw) To: Robert Marshall; +Cc: Juanma Barranquero, 17046 [-- Attachment #1: Type: text/plain, Size: 346 bytes --] > 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 [-- Attachment #2: bug17046-e.el --] [-- Type: application/emacs-lisp, Size: 1996 bytes --] ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-23 16:50 ` martin rudalics @ 2014-03-23 17:11 ` Robert Marshall 2014-03-23 17:28 ` martin rudalics 0 siblings, 1 reply; 135+ messages in thread From: Robert Marshall @ 2014-03-23 17:11 UTC (permalink / raw) To: martin rudalics; +Cc: Juanma Barranquero, 17046 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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-23 17:11 ` Robert Marshall @ 2014-03-23 17:28 ` martin rudalics 2014-03-23 17:43 ` Robert Marshall 0 siblings, 1 reply; 135+ messages in thread From: martin rudalics @ 2014-03-23 17:28 UTC (permalink / raw) To: Robert Marshall; +Cc: Juanma Barranquero, 17046 > 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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-23 17:28 ` martin rudalics @ 2014-03-23 17:43 ` Robert Marshall 2014-03-23 18:09 ` martin rudalics 2014-03-23 19:11 ` Juanma Barranquero 0 siblings, 2 replies; 135+ messages in thread From: Robert Marshall @ 2014-03-23 17:43 UTC (permalink / raw) To: martin rudalics; +Cc: Juanma Barranquero, 17046 [-- Attachment #1: message body text --] [-- Type: text/plain, Size: 703 bytes --] 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: [-- Attachment #2: bug minimum --] [-- Type: application/octet-stream, Size: 2112 bytes --] ;;; bug17046.el with two windows ;;; (read-event nil nil 1) (setq desktop-saved-frameset [frameset 1 (21291 19570 712781 440000) (desktop . "206") "robert@poulenc" nil nil (( ;; ********** FRAME 1 ( (frameset--id . "DA9D-E03E-DF32-EAB7") (frameset--mini t . t) (minibuffer . t) (visibility . t) ;; ****** Comment this next line to prevent the bug appearing (display . ":0") (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 "*scratch*" (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 "*Messages*" (selected) (hscroll . 0) (fringes 8 8 nil) (margins nil) (scroll-bars 16 2 t nil) (vscroll . 0) (dedicated) (point . 3612) (start . 3165)))))]) (frameset-restore desktop-saved-frameset :reuse-frames t :cleanup-frames t :force-onscreen t) ;;; end ;;; [-- Attachment #3: message body and .signature --] [-- Type: text/plain, Size: 121 bytes --] In nether case does it produce any other error Robert -- Links and things http://rmstar.blogspot.com/ Robert Marshall ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-23 17:43 ` Robert Marshall @ 2014-03-23 18:09 ` martin rudalics 2014-03-23 19:06 ` Robert Marshall 2014-03-23 19:11 ` Juanma Barranquero 1 sibling, 1 reply; 135+ messages in thread From: martin rudalics @ 2014-03-23 18:09 UTC (permalink / raw) To: Robert Marshall; +Cc: Juanma Barranquero, 17046 > 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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-23 18:09 ` martin rudalics @ 2014-03-23 19:06 ` Robert Marshall 0 siblings, 0 replies; 135+ messages in thread From: Robert Marshall @ 2014-03-23 19:06 UTC (permalink / raw) To: martin rudalics; +Cc: Juanma Barranquero, 17046 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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-23 17:43 ` Robert Marshall 2014-03-23 18:09 ` martin rudalics @ 2014-03-23 19:11 ` Juanma Barranquero 2014-03-23 19:32 ` Robert Marshall 1 sibling, 1 reply; 135+ messages in thread From: Juanma Barranquero @ 2014-03-23 19:11 UTC (permalink / raw) To: Robert Marshall; +Cc: 17046 On Sun, Mar 23, 2014 at 6:43 PM, Robert Marshall <robert@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? ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-23 19:11 ` Juanma Barranquero @ 2014-03-23 19:32 ` Robert Marshall 2014-03-23 20:17 ` Juanma Barranquero 2014-03-23 21:17 ` Juanma Barranquero 0 siblings, 2 replies; 135+ messages in thread From: Robert Marshall @ 2014-03-23 19:32 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 17046 Juanma Barranquero writes: > On Sun, Mar 23, 2014 at 6:43 PM, Robert Marshall <robert@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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-23 19:32 ` Robert Marshall @ 2014-03-23 20:17 ` Juanma Barranquero 2014-03-23 21:01 ` Robert Marshall 2014-03-23 21:17 ` Juanma Barranquero 1 sibling, 1 reply; 135+ messages in thread From: Juanma Barranquero @ 2014-03-23 20:17 UTC (permalink / raw) To: Robert Marshall; +Cc: 17046 On Sun, Mar 23, 2014 at 8:32 PM, Robert Marshall <robert@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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-23 20:17 ` Juanma Barranquero @ 2014-03-23 21:01 ` Robert Marshall 2014-03-23 21:08 ` Juanma Barranquero 0 siblings, 1 reply; 135+ messages in thread From: Robert Marshall @ 2014-03-23 21:01 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 17046 Juanma Barranquero writes: > On Sun, Mar 23, 2014 at 8:32 PM, Robert Marshall <robert@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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-23 21:01 ` Robert Marshall @ 2014-03-23 21:08 ` Juanma Barranquero 0 siblings, 0 replies; 135+ messages in thread From: Juanma Barranquero @ 2014-03-23 21:08 UTC (permalink / raw) To: Robert Marshall; +Cc: 17046 On Sun, Mar 23, 2014 at 10:01 PM, Robert Marshall <robert@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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-23 19:32 ` Robert Marshall 2014-03-23 20:17 ` Juanma Barranquero @ 2014-03-23 21:17 ` Juanma Barranquero 2014-03-23 21:35 ` Robert Marshall 1 sibling, 1 reply; 135+ messages in thread From: Juanma Barranquero @ 2014-03-23 21:17 UTC (permalink / raw) To: Robert Marshall; +Cc: 17046 Could you please post the exact .el file you're using to reproduce the bug? Thanks, J ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-23 21:17 ` Juanma Barranquero @ 2014-03-23 21:35 ` Robert Marshall 2014-03-24 0:13 ` Juanma Barranquero 0 siblings, 1 reply; 135+ messages in thread From: Robert Marshall @ 2014-03-23 21:35 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 17046 [-- Attachment #1: message body text --] [-- Type: text/plain, Size: 122 bytes --] Juanma Barranquero writes: > Could you please post the exact .el file you're using to reproduce the bug? > Here it is [-- Attachment #2: bug file --] [-- Type: application/octet-stream, Size: 2135 bytes --] ;;; bug17046.el with two windows ;;; (read-event nil nil 1) (setq desktop-saved-frameset [frameset 1 (21291 19570 712781 440000) (desktop . "206") "robert@poulenc" nil nil (( ;; ********** FRAME 1 ( (frameset--id . "DA9D-E03E-DF32-EAB7") (frameset--mini t . t) (minibuffer . t) (visibility . t) ;; ****** Comment this next line to prevent the bug appearing (display . ":0") (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 "*scratch*" (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 "*Messages*" (selected) (hscroll . 0) (fringes 8 8 nil) (margins nil) (scroll-bars 16 2 t nil) (vscroll . 0) (dedicated) (point . 3612) (start . 3165)))))]) (frameset-restore desktop-saved-frameset :reuse-frames t ; :force-display t :cleanup-frames t :force-onscreen t) ;;; end ;;; [-- Attachment #3: message body and .signature --] [-- Type: text/plain, Size: 28 bytes --] Robert -- Robert Marshall ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-23 21:35 ` Robert Marshall @ 2014-03-24 0:13 ` Juanma Barranquero 2014-03-24 8:09 ` Robert Marshall 0 siblings, 1 reply; 135+ messages in thread From: Juanma Barranquero @ 2014-03-24 0:13 UTC (permalink / raw) To: Robert Marshall; +Cc: 17046 [-- Attachment #1: Type: text/plain, Size: 192 bytes --] 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 [-- Attachment #2: bug17046-b.el --] [-- Type: application/octet-stream, Size: 4277 bytes --] ;;; bug17046.el with two windows ;;; (require 'frameset) (defun frameset--restore-frame (parameters window-state filters force-onscreen) (let* ((fullscreen (cdr (assq 'fullscreen parameters))) (lines (assq 'tool-bar-lines parameters)) (filtered-cfg (frameset-filter-params parameters filters nil)) (display (cdr (assq 'display filtered-cfg))) ;; post-filtering alt-cfg frame) (setq filtered-cfg (assq-delete-all 'tool-bar-lines filtered-cfg)) (push '(tool-bar-lines . 0) filtered-cfg) (when fullscreen (let ((width (and (eq fullscreen 'fullheight) (cdr (assq 'width filtered-cfg)))) (height (and (eq fullscreen 'fullwidth) (cdr (assq 'height filtered-cfg)))) (visible (assq 'visibility filtered-cfg))) (setq filtered-cfg (cl-delete-if (lambda (p) (memq p '(visibility fullscreen width height))) filtered-cfg :key #'car)) (when width (setq filtered-cfg (append `((user-size . t) (width . ,width)) filtered-cfg))) (when height (setq filtered-cfg (append `((user-size . t) (height . ,height)) filtered-cfg))) (push visible alt-cfg) (push (cons 'fullscreen fullscreen) alt-cfg))) (setq frame (and frameset--reuse-list (frameset--reuse-frame display filtered-cfg))) (if frame (puthash frame :reused frameset--action-map) (setq frame (make-frame-on-display display (cons '(visibility) (frameset--initial-params filtered-cfg)))) (puthash frame :created frameset--action-map)) (message "%S was %s" frame (gethash frame frameset--action-map)) (modify-frame-parameters frame (if (eq (frame-parameter frame 'fullscreen) fullscreen) (assq-delete-all 'fullscreen filtered-cfg) filtered-cfg)) (message "filtered-cfg: %S" filtered-cfg) (when (and force-onscreen (not (eq (frame-parameter frame 'visibility) 'icon))) (frameset-move-onscreen frame force-onscreen)) (when lines (push lines alt-cfg)) (when alt-cfg (modify-frame-parameters frame alt-cfg)) (message "alt-cfg: %S" alt-cfg) (window-state-put window-state (frame-root-window frame) 'safe) frame)) (read-event nil nil 1) (setq desktop-saved-frameset [frameset 1 (21291 19570 712781 440000) (desktop . "206") "robert@poulenc" nil nil (( ;; ********** FRAME 1 ( (frameset--id . "DA9D-E03E-DF32-EAB7") (frameset--mini t . t) (minibuffer . t) (visibility . t) ;; ****** Comment this next line to prevent the bug appearing (display . ":0") (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 "*scratch*" (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 "*Messages*" (selected) (hscroll . 0) (fringes 8 8 nil) (margins nil) (scroll-bars 16 2 t nil) (vscroll . 0) (dedicated) (point . 3612) (start . 3165)))))]) (frameset-restore desktop-saved-frameset :reuse-frames t ; :force-display t :force-onscreen t :cleanup-frames t) ;;; end ;;; ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-24 0:13 ` Juanma Barranquero @ 2014-03-24 8:09 ` Robert Marshall 2014-03-24 11:32 ` Juanma Barranquero 0 siblings, 1 reply; 135+ messages in thread From: Robert Marshall @ 2014-03-24 8:09 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 17046 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@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@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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-24 8:09 ` Robert Marshall @ 2014-03-24 11:32 ` Juanma Barranquero 2014-03-24 11:36 ` Juanma Barranquero 0 siblings, 1 reply; 135+ messages in thread From: Juanma Barranquero @ 2014-03-24 11:32 UTC (permalink / raw) To: Robert Marshall; +Cc: 17046 On Mon, Mar 24, 2014 at 9:09 AM, Robert Marshall <robert@capuchin.co.uk> wrote: > With bug: > > #<frame emacs@poulenc 0x8725ae0> was :reused > Without bug: > > #<frame emacs@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)))) ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-24 11:32 ` Juanma Barranquero @ 2014-03-24 11:36 ` Juanma Barranquero 2014-03-24 12:03 ` Robert Marshall 0 siblings, 1 reply; 135+ messages in thread From: Juanma Barranquero @ 2014-03-24 11:36 UTC (permalink / raw) To: Robert Marshall; +Cc: 17046 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)))) ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-24 11:36 ` Juanma Barranquero @ 2014-03-24 12:03 ` Robert Marshall 2014-03-24 12:56 ` Juanma Barranquero 0 siblings, 1 reply; 135+ messages in thread From: Robert Marshall @ 2014-03-24 12:03 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 17046 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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-24 12:03 ` Robert Marshall @ 2014-03-24 12:56 ` Juanma Barranquero 2014-03-24 13:23 ` Robert Marshall 0 siblings, 1 reply; 135+ messages in thread From: Juanma Barranquero @ 2014-03-24 12:56 UTC (permalink / raw) To: Robert Marshall; +Cc: 17046 On Mon, Mar 24, 2014 at 1:03 PM, Robert Marshall <robert@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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-24 12:56 ` Juanma Barranquero @ 2014-03-24 13:23 ` Robert Marshall 2014-03-24 14:57 ` Juanma Barranquero 0 siblings, 1 reply; 135+ messages in thread From: Robert Marshall @ 2014-03-24 13:23 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 17046 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@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@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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-24 13:23 ` Robert Marshall @ 2014-03-24 14:57 ` Juanma Barranquero 2014-03-24 15:22 ` Robert Marshall 0 siblings, 1 reply; 135+ messages in thread From: Juanma Barranquero @ 2014-03-24 14:57 UTC (permalink / raw) To: Robert Marshall; +Cc: 17046 On Mon, Mar 24, 2014 at 2:23 PM, Robert Marshall <robert@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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-24 14:57 ` Juanma Barranquero @ 2014-03-24 15:22 ` Robert Marshall 2014-03-24 15:41 ` Juanma Barranquero 0 siblings, 1 reply; 135+ messages in thread From: Robert Marshall @ 2014-03-24 15:22 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 17046 Juanma Barranquero writes: > On Mon, Mar 24, 2014 at 2:23 PM, Robert Marshall <robert@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@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@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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-24 15:22 ` Robert Marshall @ 2014-03-24 15:41 ` Juanma Barranquero 2014-03-24 16:09 ` Robert Marshall 0 siblings, 1 reply; 135+ messages in thread From: Juanma Barranquero @ 2014-03-24 15:41 UTC (permalink / raw) To: Robert Marshall; +Cc: 17046 [-- Attachment #1: Type: text/plain, Size: 449 bytes --] On Mon, Mar 24, 2014 at 4:22 PM, Robert Marshall <robert@capuchin.co.uk> wrote: > With bug: > > #<frame emacs@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) [-- Attachment #2: bug17046-c.el --] [-- Type: application/octet-stream, Size: 3698 bytes --] ;;; bug17046.el with two windows ;;; (require 'frameset) (defun frameset--restore-frame (parameters window-state filters force-onscreen) (let* ((fullscreen (cdr (assq 'fullscreen parameters))) (lines (assq 'tool-bar-lines parameters)) (filtered-cfg (frameset-filter-params parameters filters nil)) (display (cdr (assq 'display filtered-cfg))) ;; post-filtering alt-cfg frame) (setq filtered-cfg (assq-delete-all 'tool-bar-lines filtered-cfg)) (push '(tool-bar-lines . 0) filtered-cfg) (setq frame (and frameset--reuse-list (frameset--reuse-frame display filtered-cfg))) (if frame (puthash frame :reused frameset--action-map) (setq frame (make-frame-on-display display (cons '(visibility) (frameset--initial-params filtered-cfg)))) (puthash frame :created frameset--action-map)) (let ((sep (make-string 80 ?-))) (message "%s\n%S was %s with:\n %s\n%s\n" sep frame (gethash frame frameset--action-map) (mapconcat (lambda (o) (format "%s" o)) (sort (frame-parameters frame) (lambda (a b) (string< (car a) (car b)))) "\n ") sep)) (modify-frame-parameters frame (if (eq (frame-parameter frame 'fullscreen) fullscreen) (assq-delete-all 'fullscreen filtered-cfg) filtered-cfg)) (when (and force-onscreen (not (eq (frame-parameter frame 'visibility) 'icon))) (frameset-move-onscreen frame force-onscreen)) (when lines (push lines alt-cfg)) (when alt-cfg (modify-frame-parameters frame alt-cfg)) frame)) (read-event nil nil 1) (setq desktop-saved-frameset [frameset 1 (21291 19570 712781 440000) (desktop . "206") "robert@poulenc" nil nil (( ;; ********** FRAME 1 ( (frameset--id . "DA9D-E03E-DF32-EAB7") (frameset--mini t . t) (minibuffer . t) (visibility . t) ;; ****** Comment this next line to prevent the bug appearing (display . ":0") (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 "*scratch*" (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 "*Messages*" (selected) (hscroll . 0) (fringes 8 8 nil) (margins nil) (scroll-bars 16 2 t nil) (vscroll . 0) (dedicated) (point . 3612) (start . 3165)))))]) (frameset-restore desktop-saved-frameset :reuse-frames t ; :force-display t :force-onscreen t :cleanup-frames t) ;;; end ;;; ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-24 15:41 ` Juanma Barranquero @ 2014-03-24 16:09 ` Robert Marshall 2014-03-24 16:16 ` Juanma Barranquero 0 siblings, 1 reply; 135+ messages in thread From: Robert Marshall @ 2014-03-24 16:09 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 17046 Juanma Barranquero writes: > On Mon, Mar 24, 2014 at 4:22 PM, Robert Marshall <robert@capuchin.co.uk> wrote: > > > With bug: > > > > #<frame emacs@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@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@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@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@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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-24 16:09 ` Robert Marshall @ 2014-03-24 16:16 ` Juanma Barranquero 2014-03-24 17:13 ` Robert Marshall 0 siblings, 1 reply; 135+ messages in thread From: Juanma Barranquero @ 2014-03-24 16:16 UTC (permalink / raw) To: Robert Marshall; +Cc: 17046 On Mon, Mar 24, 2014 at 5:09 PM, Robert Marshall <robert@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. ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-24 16:16 ` Juanma Barranquero @ 2014-03-24 17:13 ` Robert Marshall 2014-03-24 17:24 ` Juanma Barranquero 0 siblings, 1 reply; 135+ messages in thread From: Robert Marshall @ 2014-03-24 17:13 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 17046 Juanma Barranquero writes: > On Mon, Mar 24, 2014 at 5:09 PM, Robert Marshall <robert@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@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@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@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@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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-24 17:13 ` Robert Marshall @ 2014-03-24 17:24 ` Juanma Barranquero 2014-03-24 18:48 ` Robert Marshall 0 siblings, 1 reply; 135+ messages in thread From: Juanma Barranquero @ 2014-03-24 17:24 UTC (permalink / raw) To: Robert Marshall; +Cc: 17046 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. ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-24 17:24 ` Juanma Barranquero @ 2014-03-24 18:48 ` Robert Marshall [not found] ` <CAAeL0SQ=mwj+FAf_vR8F5-9bdFw0FcejGFvfNKAAPNwZHZruHw@mail.gmail.com> 0 siblings, 1 reply; 135+ messages in thread From: Robert Marshall @ 2014-03-24 18:48 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 17046 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 ^ permalink raw reply [flat|nested] 135+ messages in thread
[parent not found: <CAAeL0SQ=mwj+FAf_vR8F5-9bdFw0FcejGFvfNKAAPNwZHZruHw@mail.gmail.com>]
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations [not found] ` <CAAeL0SQ=mwj+FAf_vR8F5-9bdFw0FcejGFvfNKAAPNwZHZruHw@mail.gmail.com> @ 2014-03-24 21:33 ` Robert Marshall 2014-03-24 21:52 ` Juanma Barranquero 0 siblings, 1 reply; 135+ messages in thread From: Robert Marshall @ 2014-03-24 21:33 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 17046 Juanma Barranquero writes: > On Mon, Mar 24, 2014 at 7:48 PM, Robert Marshall <robert@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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-24 21:33 ` Robert Marshall @ 2014-03-24 21:52 ` Juanma Barranquero 2014-03-24 22:43 ` Robert Marshall 0 siblings, 1 reply; 135+ messages in thread From: Juanma Barranquero @ 2014-03-24 21:52 UTC (permalink / raw) To: Robert Marshall; +Cc: 17046 On Mon, Mar 24, 2014 at 10:33 PM, Robert Marshall <robert@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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-24 21:52 ` Juanma Barranquero @ 2014-03-24 22:43 ` Robert Marshall 2014-03-24 23:37 ` Juanma Barranquero 0 siblings, 1 reply; 135+ messages in thread From: Robert Marshall @ 2014-03-24 22:43 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 17046 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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-24 22:43 ` Robert Marshall @ 2014-03-24 23:37 ` Juanma Barranquero 2014-03-25 7:12 ` Robert Marshall 0 siblings, 1 reply; 135+ messages in thread From: Juanma Barranquero @ 2014-03-24 23:37 UTC (permalink / raw) To: Robert Marshall; +Cc: 17046 On Mon, Mar 24, 2014 at 11:43 PM, Robert Marshall <robert@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? ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-24 23:37 ` Juanma Barranquero @ 2014-03-25 7:12 ` Robert Marshall 2014-03-25 10:40 ` Juanma Barranquero 0 siblings, 1 reply; 135+ messages in thread From: Robert Marshall @ 2014-03-25 7:12 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 17046 Juanma Barranquero writes: > On Mon, Mar 24, 2014 at 11:43 PM, Robert Marshall <robert@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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-25 7:12 ` Robert Marshall @ 2014-03-25 10:40 ` Juanma Barranquero 2014-03-25 11:09 ` Robert Marshall 0 siblings, 1 reply; 135+ messages in thread From: Juanma Barranquero @ 2014-03-25 10:40 UTC (permalink / raw) To: Robert Marshall; +Cc: 17046 On Tue, Mar 25, 2014 at 8:12 AM, Robert Marshall <robert@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)))) ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-25 10:40 ` Juanma Barranquero @ 2014-03-25 11:09 ` Robert Marshall 2014-03-25 12:32 ` Juanma Barranquero 0 siblings, 1 reply; 135+ messages in thread From: Robert Marshall @ 2014-03-25 11:09 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 17046 Juanma Barranquero writes: > On Tue, Mar 25, 2014 at 8:12 AM, Robert Marshall <robert@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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-25 11:09 ` Robert Marshall @ 2014-03-25 12:32 ` Juanma Barranquero 2014-03-25 14:57 ` martin rudalics 0 siblings, 1 reply; 135+ messages in thread From: Juanma Barranquero @ 2014-03-25 12:32 UTC (permalink / raw) To: Robert Marshall; +Cc: 17046 On Tue, Mar 25, 2014 at 12:09 PM, Robert Marshall <robert@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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-25 12:32 ` Juanma Barranquero @ 2014-03-25 14:57 ` martin rudalics 2014-03-25 15:48 ` Eli Zaretskii 0 siblings, 1 reply; 135+ messages in thread From: martin rudalics @ 2014-03-25 14:57 UTC (permalink / raw) To: Juanma Barranquero, Robert Marshall; +Cc: 17046 > 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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-25 14:57 ` martin rudalics @ 2014-03-25 15:48 ` Eli Zaretskii 2014-03-26 16:34 ` Juanma Barranquero 0 siblings, 1 reply; 135+ messages in thread From: Eli Zaretskii @ 2014-03-25 15:48 UTC (permalink / raw) To: martin rudalics; +Cc: lekktu, robert, 17046 > Date: Tue, 25 Mar 2014 15:57:27 +0100 > From: martin rudalics <rudalics@gmx.at> > Cc: 17046@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? ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-25 15:48 ` Eli Zaretskii @ 2014-03-26 16:34 ` Juanma Barranquero 2014-03-26 17:08 ` Robert Marshall 0 siblings, 1 reply; 135+ messages in thread From: Juanma Barranquero @ 2014-03-26 16:34 UTC (permalink / raw) To: Eli Zaretskii; +Cc: robert, 17046 On Tue, Mar 25, 2014 at 4:48 PM, Eli Zaretskii <eliz@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. ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-26 16:34 ` Juanma Barranquero @ 2014-03-26 17:08 ` Robert Marshall 2014-03-26 17:15 ` Juanma Barranquero 0 siblings, 1 reply; 135+ messages in thread From: Robert Marshall @ 2014-03-26 17:08 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 17046 Juanma Barranquero writes: > On Tue, Mar 25, 2014 at 4:48 PM, Eli Zaretskii <eliz@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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-26 17:08 ` Robert Marshall @ 2014-03-26 17:15 ` Juanma Barranquero 2014-03-26 17:29 ` Robert Marshall 2014-03-26 17:54 ` Eli Zaretskii 0 siblings, 2 replies; 135+ messages in thread From: Juanma Barranquero @ 2014-03-26 17:15 UTC (permalink / raw) To: Robert Marshall; +Cc: 17046 On Wed, Mar 26, 2014 at 6:08 PM, Robert Marshall <robert@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)))) ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-26 17:15 ` Juanma Barranquero @ 2014-03-26 17:29 ` Robert Marshall 2014-03-26 17:54 ` Eli Zaretskii 1 sibling, 0 replies; 135+ messages in thread From: Robert Marshall @ 2014-03-26 17:29 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 17046 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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-26 17:15 ` Juanma Barranquero 2014-03-26 17:29 ` Robert Marshall @ 2014-03-26 17:54 ` Eli Zaretskii 2014-03-26 18:19 ` Juanma Barranquero 1 sibling, 1 reply; 135+ messages in thread From: Eli Zaretskii @ 2014-03-26 17:54 UTC (permalink / raw) To: Juanma Barranquero; +Cc: robert, 17046 > From: Juanma Barranquero <lekktu@gmail.com> > Date: Wed, 26 Mar 2014 18:15:46 +0100 > Cc: Eli Zaretskii <eliz@gnu.org>, martin rudalics <rudalics@gmx.at>, 17046@debbugs.gnu.org > > On Wed, Mar 26, 2014 at 6:08 PM, Robert Marshall <robert@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? ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-26 17:54 ` Eli Zaretskii @ 2014-03-26 18:19 ` Juanma Barranquero 2014-03-26 19:14 ` Robert Marshall 2014-03-26 23:05 ` Juanma Barranquero 0 siblings, 2 replies; 135+ messages in thread From: Juanma Barranquero @ 2014-03-26 18:19 UTC (permalink / raw) To: Eli Zaretskii; +Cc: robert, 17046 On Wed, Mar 26, 2014 at 6:54 PM, Eli Zaretskii <eliz@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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-26 18:19 ` Juanma Barranquero @ 2014-03-26 19:14 ` Robert Marshall 2014-03-26 20:18 ` Juanma Barranquero 2014-03-26 23:05 ` Juanma Barranquero 1 sibling, 1 reply; 135+ messages in thread From: Robert Marshall @ 2014-03-26 19:14 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 17046 Juanma Barranquero writes: > On Wed, Mar 26, 2014 at 6:54 PM, Eli Zaretskii <eliz@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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-26 19:14 ` Robert Marshall @ 2014-03-26 20:18 ` Juanma Barranquero 2014-03-26 22:58 ` Robert Marshall 0 siblings, 1 reply; 135+ messages in thread From: Juanma Barranquero @ 2014-03-26 20:18 UTC (permalink / raw) To: Robert Marshall; +Cc: 17046 On Wed, Mar 26, 2014 at 8:14 PM, Robert Marshall <robert@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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-26 20:18 ` Juanma Barranquero @ 2014-03-26 22:58 ` Robert Marshall 2014-03-26 23:00 ` Juanma Barranquero 2014-03-27 0:59 ` Juanma Barranquero 0 siblings, 2 replies; 135+ messages in thread From: Robert Marshall @ 2014-03-26 22:58 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 17046 Juanma Barranquero writes: > On Wed, Mar 26, 2014 at 8:14 PM, Robert Marshall <robert@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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-26 22:58 ` Robert Marshall @ 2014-03-26 23:00 ` Juanma Barranquero 2014-03-27 0:59 ` Juanma Barranquero 1 sibling, 0 replies; 135+ messages in thread From: Juanma Barranquero @ 2014-03-26 23:00 UTC (permalink / raw) To: Robert Marshall; +Cc: 17046 On Wed, Mar 26, 2014 at 11:58 PM, Robert Marshall <robert@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? ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-26 22:58 ` Robert Marshall 2014-03-26 23:00 ` Juanma Barranquero @ 2014-03-27 0:59 ` Juanma Barranquero 2014-03-27 7:15 ` Robert Marshall 1 sibling, 1 reply; 135+ messages in thread From: Juanma Barranquero @ 2014-03-27 0:59 UTC (permalink / raw) To: Robert Marshall; +Cc: 17046 On Wed, Mar 26, 2014 at 11:58 PM, Robert Marshall <robert@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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-27 0:59 ` Juanma Barranquero @ 2014-03-27 7:15 ` Robert Marshall 0 siblings, 0 replies; 135+ messages in thread From: Robert Marshall @ 2014-03-27 7:15 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 17046 Juanma Barranquero writes: > On Wed, Mar 26, 2014 at 11:58 PM, Robert Marshall <robert@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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-26 18:19 ` Juanma Barranquero 2014-03-26 19:14 ` Robert Marshall @ 2014-03-26 23:05 ` Juanma Barranquero 2014-03-27 15:06 ` Juanma Barranquero 1 sibling, 1 reply; 135+ messages in thread From: Juanma Barranquero @ 2014-03-26 23:05 UTC (permalink / raw) To: Eli Zaretskii; +Cc: robert, 17046 On Wed, Mar 26, 2014 at 7:19 PM, Juanma Barranquero <lekktu@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. ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-26 23:05 ` Juanma Barranquero @ 2014-03-27 15:06 ` Juanma Barranquero 0 siblings, 0 replies; 135+ messages in thread From: Juanma Barranquero @ 2014-03-27 15:06 UTC (permalink / raw) To: Eli Zaretskii; +Cc: robert, 17046-done Version: 24.4 On Thu, Mar 27, 2014 at 12:05 AM, Juanma Barranquero <lekktu@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. ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-22 21:35 ` martin rudalics 2014-03-22 21:42 ` Juanma Barranquero @ 2014-03-22 22:10 ` Robert Marshall 2014-03-22 22:14 ` Juanma Barranquero 1 sibling, 1 reply; 135+ messages in thread From: Robert Marshall @ 2014-03-22 22:10 UTC (permalink / raw) To: martin rudalics; +Cc: Juanma Barranquero, 17046 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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-22 22:10 ` Robert Marshall @ 2014-03-22 22:14 ` Juanma Barranquero 0 siblings, 0 replies; 135+ messages in thread From: Juanma Barranquero @ 2014-03-22 22:14 UTC (permalink / raw) To: Robert Marshall; +Cc: 17046 On Sat, Mar 22, 2014 at 11:10 PM, Robert Marshall <robert@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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-22 1:53 ` Juanma Barranquero 2014-03-22 9:40 ` martin rudalics @ 2014-03-22 16:56 ` Robert Marshall 2014-03-22 17:39 ` Juanma Barranquero 1 sibling, 1 reply; 135+ messages in thread From: Robert Marshall @ 2014-03-22 16:56 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 17046 Juanma Barranquero writes: > On Fri, Mar 21, 2014 at 6:42 PM, martin rudalics <rudalics@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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-22 16:56 ` Robert Marshall @ 2014-03-22 17:39 ` Juanma Barranquero 0 siblings, 0 replies; 135+ messages in thread From: Juanma Barranquero @ 2014-03-22 17:39 UTC (permalink / raw) To: Robert Marshall; +Cc: 17046 On Sat, Mar 22, 2014 at 5:56 PM, Robert Marshall <robert@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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-21 8:03 ` martin rudalics [not found] ` <21292.6903.499178.348@capuchin.co.uk> @ 2014-03-23 16:07 ` Robert Marshall 1 sibling, 0 replies; 135+ messages in thread From: Robert Marshall @ 2014-03-23 16:07 UTC (permalink / raw) To: 17046 [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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-20 9:08 bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations Robert Marshall 2014-03-20 9:52 ` martin rudalics @ 2014-03-20 12:24 ` Juanma Barranquero 2014-03-20 12:57 ` Robert Marshall 1 sibling, 1 reply; 135+ messages in thread From: Juanma Barranquero @ 2014-03-20 12:24 UTC (permalink / raw) To: Robert Marshall; +Cc: 17046 On Thu, Mar 20, 2014 at 10:08 AM, Robert Marshall <robert@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...) ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-20 12:24 ` Juanma Barranquero @ 2014-03-20 12:57 ` Robert Marshall 2014-03-20 14:02 ` Juanma Barranquero 0 siblings, 1 reply; 135+ messages in thread From: Robert Marshall @ 2014-03-20 12:57 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 17046 Juanma Barranquero writes: > On Thu, Mar 20, 2014 at 10:08 AM, Robert Marshall <robert@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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-20 12:57 ` Robert Marshall @ 2014-03-20 14:02 ` Juanma Barranquero 2014-03-20 16:32 ` Robert Marshall 0 siblings, 1 reply; 135+ messages in thread From: Juanma Barranquero @ 2014-03-20 14:02 UTC (permalink / raw) To: Robert Marshall; +Cc: 17046 On Thu, Mar 20, 2014 at 1:57 PM, Robert Marshall <robert@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). ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-20 14:02 ` Juanma Barranquero @ 2014-03-20 16:32 ` Robert Marshall 2014-03-20 16:54 ` Juanma Barranquero 0 siblings, 1 reply; 135+ messages in thread From: Robert Marshall @ 2014-03-20 16:32 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 17046 Juanma Barranquero writes: > On Thu, Mar 20, 2014 at 1:57 PM, Robert Marshall <robert@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@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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-20 16:32 ` Robert Marshall @ 2014-03-20 16:54 ` Juanma Barranquero 2014-03-20 19:24 ` martin rudalics 0 siblings, 1 reply; 135+ messages in thread From: Juanma Barranquero @ 2014-03-20 16:54 UTC (permalink / raw) To: Robert Marshall; +Cc: 17046 On Thu, Mar 20, 2014 at 5:32 PM, Robert Marshall <robert@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@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))))] ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-20 16:54 ` Juanma Barranquero @ 2014-03-20 19:24 ` martin rudalics 2014-03-20 20:23 ` Juanma Barranquero 0 siblings, 1 reply; 135+ messages in thread From: martin rudalics @ 2014-03-20 19:24 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 17046, Robert Marshall > 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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-20 19:24 ` martin rudalics @ 2014-03-20 20:23 ` Juanma Barranquero 2014-03-21 8:02 ` martin rudalics 0 siblings, 1 reply; 135+ messages in thread From: Juanma Barranquero @ 2014-03-20 20:23 UTC (permalink / raw) To: martin rudalics; +Cc: 17046, Robert Marshall On Thu, Mar 20, 2014 at 8:24 PM, martin rudalics <rudalics@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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-20 20:23 ` Juanma Barranquero @ 2014-03-21 8:02 ` martin rudalics 2014-03-21 16:18 ` Juanma Barranquero 0 siblings, 1 reply; 135+ messages in thread From: martin rudalics @ 2014-03-21 8:02 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 17046, Robert Marshall >> 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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-21 8:02 ` martin rudalics @ 2014-03-21 16:18 ` Juanma Barranquero 2014-03-22 9:39 ` martin rudalics 0 siblings, 1 reply; 135+ messages in thread From: Juanma Barranquero @ 2014-03-21 16:18 UTC (permalink / raw) To: martin rudalics; +Cc: 17046, Robert Marshall On Fri, Mar 21, 2014 at 9:02 AM, martin rudalics <rudalics@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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-21 16:18 ` Juanma Barranquero @ 2014-03-22 9:39 ` martin rudalics 2014-03-22 11:43 ` Juanma Barranquero 2014-03-22 14:39 ` Stefan 0 siblings, 2 replies; 135+ messages in thread From: martin rudalics @ 2014-03-22 9:39 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 17046, Robert Marshall >> 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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-22 9:39 ` martin rudalics @ 2014-03-22 11:43 ` Juanma Barranquero 2014-03-22 13:45 ` martin rudalics 2014-03-22 14:39 ` Stefan 1 sibling, 1 reply; 135+ messages in thread From: Juanma Barranquero @ 2014-03-22 11:43 UTC (permalink / raw) To: martin rudalics; +Cc: 17046, Robert Marshall On Sat, Mar 22, 2014 at 10:39 AM, martin rudalics <rudalics@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). ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-22 11:43 ` Juanma Barranquero @ 2014-03-22 13:45 ` martin rudalics 2014-03-22 14:04 ` Juanma Barranquero 2014-03-22 14:27 ` Eli Zaretskii 0 siblings, 2 replies; 135+ messages in thread From: martin rudalics @ 2014-03-22 13:45 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 17046, Robert Marshall > 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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-22 13:45 ` martin rudalics @ 2014-03-22 14:04 ` Juanma Barranquero 2014-03-22 14:21 ` martin rudalics 2014-03-22 14:27 ` Eli Zaretskii 1 sibling, 1 reply; 135+ messages in thread From: Juanma Barranquero @ 2014-03-22 14:04 UTC (permalink / raw) To: martin rudalics; +Cc: 17046, Robert Marshall On Sat, Mar 22, 2014 at 2:45 PM, martin rudalics <rudalics@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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-22 14:04 ` Juanma Barranquero @ 2014-03-22 14:21 ` martin rudalics 0 siblings, 0 replies; 135+ messages in thread From: martin rudalics @ 2014-03-22 14:21 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 17046, Robert Marshall > 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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-22 13:45 ` martin rudalics 2014-03-22 14:04 ` Juanma Barranquero @ 2014-03-22 14:27 ` Eli Zaretskii 2014-03-22 15:21 ` martin rudalics 1 sibling, 1 reply; 135+ messages in thread From: Eli Zaretskii @ 2014-03-22 14:27 UTC (permalink / raw) To: martin rudalics; +Cc: lekktu, robert, 17046 > Date: Sat, 22 Mar 2014 14:45:01 +0100 > From: martin rudalics <rudalics@gmx.at> > Cc: 17046@debbugs.gnu.org, Robert Marshall <robert@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. ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-22 14:27 ` Eli Zaretskii @ 2014-03-22 15:21 ` martin rudalics 0 siblings, 0 replies; 135+ messages in thread From: martin rudalics @ 2014-03-22 15:21 UTC (permalink / raw) To: Eli Zaretskii; +Cc: lekktu, robert, 17046 >> 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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-22 9:39 ` martin rudalics 2014-03-22 11:43 ` Juanma Barranquero @ 2014-03-22 14:39 ` Stefan 2014-03-22 15:21 ` martin rudalics 1 sibling, 1 reply; 135+ messages in thread From: Stefan @ 2014-03-22 14:39 UTC (permalink / raw) To: martin rudalics; +Cc: Juanma Barranquero, Robert Marshall, 17046 > 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 ^ permalink raw reply [flat|nested] 135+ messages in thread
* bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations 2014-03-22 14:39 ` Stefan @ 2014-03-22 15:21 ` martin rudalics 0 siblings, 0 replies; 135+ messages in thread From: martin rudalics @ 2014-03-22 15:21 UTC (permalink / raw) To: Stefan; +Cc: Juanma Barranquero, Robert Marshall, 17046 > 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 ^ permalink raw reply [flat|nested] 135+ messages in thread
end of thread, other threads:[~2014-03-27 15:06 UTC | newest] Thread overview: 135+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-03-20 9:08 bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations Robert Marshall 2014-03-20 9:52 ` martin rudalics 2014-03-20 12:22 ` Robert Marshall 2014-03-20 13:08 ` martin rudalics 2014-03-20 14:28 ` Robert Marshall 2014-03-20 19:23 ` martin rudalics 2014-03-20 20:25 ` Robert Marshall 2014-03-20 20:37 ` Juanma Barranquero 2014-03-20 20:51 ` Robert Marshall 2014-03-20 20:59 ` Juanma Barranquero 2014-03-21 8:02 ` martin rudalics 2014-03-21 8:03 ` martin rudalics [not found] ` <21292.6903.499178.348@capuchin.co.uk> 2014-03-21 15:07 ` martin rudalics 2014-03-21 16:53 ` Robert Marshall 2014-03-21 17:42 ` martin rudalics 2014-03-22 1:53 ` Juanma Barranquero 2014-03-22 9:40 ` martin rudalics 2014-03-22 11:35 ` Robert Marshall 2014-03-22 13:44 ` martin rudalics 2014-03-22 14:02 ` Juanma Barranquero 2014-03-22 14:20 ` martin rudalics 2014-03-22 14:33 ` Juanma Barranquero 2014-03-22 15:20 ` martin rudalics 2014-03-22 15:26 ` Juanma Barranquero 2014-03-22 15:33 ` martin rudalics 2014-03-22 16:28 ` Robert Marshall 2014-03-22 16:38 ` Juanma Barranquero 2014-03-22 17:00 ` Robert Marshall 2014-03-22 17:34 ` Juanma Barranquero 2014-03-22 18:36 ` Robert Marshall 2014-03-22 19:09 ` Juanma Barranquero 2014-03-22 19:18 ` martin rudalics 2014-03-22 19:22 ` Juanma Barranquero 2014-03-22 18:43 ` martin rudalics 2014-03-22 19:17 ` Juanma Barranquero 2014-03-22 19:34 ` martin rudalics 2014-03-22 20:17 ` Robert Marshall 2014-03-22 21:17 ` Juanma Barranquero 2014-03-22 21:35 ` martin rudalics 2014-03-22 21:35 ` martin rudalics 2014-03-22 21:42 ` Juanma Barranquero 2014-03-22 22:16 ` Robert Marshall 2014-03-23 10:11 ` martin rudalics 2014-03-23 11:14 ` Robert Marshall 2014-03-23 11:39 ` martin rudalics 2014-03-23 12:13 ` Robert Marshall 2014-03-23 13:39 ` Robert Marshall 2014-03-23 13:51 ` martin rudalics 2014-03-23 14:11 ` martin rudalics 2014-03-23 14:30 ` Robert Marshall 2014-03-23 14:55 ` martin rudalics 2014-03-23 15:03 ` martin rudalics 2014-03-23 15:34 ` Robert Marshall 2014-03-23 15:17 ` Robert Marshall 2014-03-23 15:28 ` martin rudalics 2014-03-23 16:10 ` Robert Marshall 2014-03-23 16:37 ` Juanma Barranquero 2014-03-23 16:57 ` martin rudalics 2014-03-23 17:19 ` martin rudalics 2014-03-23 17:07 ` Robert Marshall 2014-03-23 16:50 ` martin rudalics 2014-03-23 17:11 ` Robert Marshall 2014-03-23 17:28 ` martin rudalics 2014-03-23 17:43 ` Robert Marshall 2014-03-23 18:09 ` martin rudalics 2014-03-23 19:06 ` Robert Marshall 2014-03-23 19:11 ` Juanma Barranquero 2014-03-23 19:32 ` Robert Marshall 2014-03-23 20:17 ` Juanma Barranquero 2014-03-23 21:01 ` Robert Marshall 2014-03-23 21:08 ` Juanma Barranquero 2014-03-23 21:17 ` Juanma Barranquero 2014-03-23 21:35 ` Robert Marshall 2014-03-24 0:13 ` Juanma Barranquero 2014-03-24 8:09 ` Robert Marshall 2014-03-24 11:32 ` Juanma Barranquero 2014-03-24 11:36 ` Juanma Barranquero 2014-03-24 12:03 ` Robert Marshall 2014-03-24 12:56 ` Juanma Barranquero 2014-03-24 13:23 ` Robert Marshall 2014-03-24 14:57 ` Juanma Barranquero 2014-03-24 15:22 ` Robert Marshall 2014-03-24 15:41 ` Juanma Barranquero 2014-03-24 16:09 ` Robert Marshall 2014-03-24 16:16 ` Juanma Barranquero 2014-03-24 17:13 ` Robert Marshall 2014-03-24 17:24 ` Juanma Barranquero 2014-03-24 18:48 ` Robert Marshall [not found] ` <CAAeL0SQ=mwj+FAf_vR8F5-9bdFw0FcejGFvfNKAAPNwZHZruHw@mail.gmail.com> 2014-03-24 21:33 ` Robert Marshall 2014-03-24 21:52 ` Juanma Barranquero 2014-03-24 22:43 ` Robert Marshall 2014-03-24 23:37 ` Juanma Barranquero 2014-03-25 7:12 ` Robert Marshall 2014-03-25 10:40 ` Juanma Barranquero 2014-03-25 11:09 ` Robert Marshall 2014-03-25 12:32 ` Juanma Barranquero 2014-03-25 14:57 ` martin rudalics 2014-03-25 15:48 ` Eli Zaretskii 2014-03-26 16:34 ` Juanma Barranquero 2014-03-26 17:08 ` Robert Marshall 2014-03-26 17:15 ` Juanma Barranquero 2014-03-26 17:29 ` Robert Marshall 2014-03-26 17:54 ` Eli Zaretskii 2014-03-26 18:19 ` Juanma Barranquero 2014-03-26 19:14 ` Robert Marshall 2014-03-26 20:18 ` Juanma Barranquero 2014-03-26 22:58 ` Robert Marshall 2014-03-26 23:00 ` Juanma Barranquero 2014-03-27 0:59 ` Juanma Barranquero 2014-03-27 7:15 ` Robert Marshall 2014-03-26 23:05 ` Juanma Barranquero 2014-03-27 15:06 ` Juanma Barranquero 2014-03-22 22:10 ` Robert Marshall 2014-03-22 22:14 ` Juanma Barranquero 2014-03-22 16:56 ` Robert Marshall 2014-03-22 17:39 ` Juanma Barranquero 2014-03-23 16:07 ` Robert Marshall 2014-03-20 12:24 ` Juanma Barranquero 2014-03-20 12:57 ` Robert Marshall 2014-03-20 14:02 ` Juanma Barranquero 2014-03-20 16:32 ` Robert Marshall 2014-03-20 16:54 ` Juanma Barranquero 2014-03-20 19:24 ` martin rudalics 2014-03-20 20:23 ` Juanma Barranquero 2014-03-21 8:02 ` martin rudalics 2014-03-21 16:18 ` Juanma Barranquero 2014-03-22 9:39 ` martin rudalics 2014-03-22 11:43 ` Juanma Barranquero 2014-03-22 13:45 ` martin rudalics 2014-03-22 14:04 ` Juanma Barranquero 2014-03-22 14:21 ` martin rudalics 2014-03-22 14:27 ` Eli Zaretskii 2014-03-22 15:21 ` martin rudalics 2014-03-22 14:39 ` Stefan 2014-03-22 15:21 ` martin rudalics
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.