[Top][All Lists]

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

RE: set-frame-size for frame without minibuffer loses mode line

From: Drew Adams
Subject: RE: set-frame-size for frame without minibuffer loses mode line
Date: Tue, 9 Oct 2007 07:19:56 -0700

> > emacs -Q
> >
> > M-: (setq pop-up-frames t)
> > M-: (setq minibuffer-frame-alist (cons (quote (minibuffer . only))
> >                                        minibuffer-frame-alist))
> > M-: (setq default-frame-alist (cons (quote (minibuffer))
> >                                     default-frame-alist))
> > M-: (make-frame minibuffer-frame-alist)
> > C-x 4 d some directory
> >
> > With the dired frame selected:
> > M-: (set-frame-size (selected-frame) 30 40)
> >
> > The dired frame is correctly resized, but an empty extra line appears
> > below the mode line (there is no minibuffer on this frame).
> There is for me, and the default-frame-alist above seems to suggest that
> there should be if I am understanding it correctly.

There is an extra empty line, but there should not be a minibuffer.

An entry of (minibuffer) in `default-frame-alist' means there is no
minibuffer - the `minibuffer' frame parameter value is nil. See node `Buffer
Parameters' of the Elisp manual:

     Whether this frame has its own minibuffer.  The value `t' means
     yes, `nil' means no, `only' means this frame is just a minibuffer.
     If the value is a minibuffer window (in some other frame), the
     new frame uses that minibuffer.

> > With the dired frame selected, repeat the last command (that is,
> > repeat (set-frame-size (selected-frame) 30 40)):
> >
> > C-x ESC ESC
> >
> > Now, both the extra empty "minibuffer" line and the mode line have
> > disappeared.
> I have checked in a change that seems to fix the minibuffer disappearing
> completely. There is still some strange behaviour, such as the extra
> blank line at the bottom of the frame after the first resize, which
> seems to be caused by the menu-bar wrapping automatically when the frame
> is resized, but that happens asynchronously, so the Lisp code makes
> certain assumptions that later turn out to be invalid.

Is there a Lisp patch I can used to check the fix, or is it in C sources?

reply via email to

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