[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows
From: |
martin rudalics |
Subject: |
bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations |
Date: |
Sat, 22 Mar 2014 14:44:57 +0100 |
>> > 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
- bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations, (continued)
- bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations, martin rudalics, 2014/03/21
- bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations, martin rudalics, 2014/03/21
- Message not available
- bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations, martin rudalics, 2014/03/21
- bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations, Robert Marshall, 2014/03/21
- bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations, martin rudalics, 2014/03/21
- bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations, Juanma Barranquero, 2014/03/21
- bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations, martin rudalics, 2014/03/22
- bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations, Robert Marshall, 2014/03/22
- bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations,
martin rudalics <=
- bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations, Juanma Barranquero, 2014/03/22
- bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations, martin rudalics, 2014/03/22
- bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations, Juanma Barranquero, 2014/03/22
- bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations, martin rudalics, 2014/03/22
- bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations, Juanma Barranquero, 2014/03/22
- bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations, martin rudalics, 2014/03/22
- bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations, Robert Marshall, 2014/03/22
- bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations, Juanma Barranquero, 2014/03/22
- bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations, Robert Marshall, 2014/03/22
- bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations, Juanma Barranquero, 2014/03/22