initial-frame-alist

initial-frame-alist

[Stephen Berman]

It appears that setting initial-frame-alist has no effect if Emacs is
started with --daemon; is this intended?  Here's a case in point:

Let ~/.emacs consist of this sexp:

(setq initial-frame-alist
      (append initial-frame-alist '((width . 85) (height . 58))))

Then do this:

$ emacs --daemon
$ emacsclient -c

The resulting frame has default width and height, not those specified in
~/.emacs.  If instead I start Emacs like this:

$ emacs

then the resulting frame does width 85 and height 58.

I note that after starting Emacs like this:

$ emacs -nw -f server-start

and then in another xterm typing:

$ emacsclient -c

the resulting frame has default width and height, not those specified in
~/.emacs.  But this would be expected if the initial frame is the one in
the xterm.  Whereas with --daemon, the apparent initial frame is the one
produced by emacsclient -c.  So is this a bug or expected behavior?  If
the latter, shouldn't it be documented?  (I hope it's relatively easily
fixed bug, since I would like to have setting initial-frame-alist take
effect if Emacs is started with --daemon.)

Steve Berman

Re: initial-frame-alist

[Dan Nicolaescu]

Stephen Berman <stephen.berman@gmx.net> writes:

  > It appears that setting initial-frame-alist has no effect if Emacs is
  > started with --daemon; is this intended?  Here's a case in point:
  > 
  > Let ~/.emacs consist of this sexp:
  > 
  > (setq initial-frame-alist
  >       (append initial-frame-alist '((width . 85) (height . 58))))
  > 
  > Then do this:
  > 
  > $ emacs --daemon
  > $ emacsclient -c
  > 
  > The resulting frame has default width and height, not those specified in
  > ~/.emacs.  If instead I start Emacs like this:
  > 
  > $ emacs
  > 
  > then the resulting frame does width 85 and height 58.
  > 
  > I note that after starting Emacs like this:
  > 
  > $ emacs -nw -f server-start
  > 
  > and then in another xterm typing:
  > 
  > $ emacsclient -c
  > 
  > the resulting frame has default width and height, not those specified in
  > ~/.emacs.  But this would be expected if the initial frame is the one in
  > the xterm.  Whereas with --daemon, the apparent initial frame is the one
  > produced by emacsclient -c.  

It's not, the initial frame is a special frame that cannot be displayed.
Again: emacs --daemon is equivalent to emacs -nw -f server-start
If you try more, you can probably find even more variations of this same
basic issue...

  > So is this a bug or expected behavior?  If the latter, shouldn't it
  > be documented?  (I hope it's relatively easily fixed bug, since I
  > would like to have setting initial-frame-alist take effect if Emacs
  > is started with --daemon.)

Patches are welcome!

Re: initial-frame-alist

[Will Farrington]

[-- Attachment #1: Type: text/plain, Size: 1102 bytes --]


On Feb 5, 2009, at 9:46 AM, Dan Nicolaescu wrote:

> Stephen Berman <stephen.berman@gmx.net> writes:
>
>> It appears that setting initial-frame-alist has no effect if Emacs is
>> started with --daemon; is this intended?  Here's a case in point:
>>  ...
>> the resulting frame has default width and height, not those  
>> specified in
>> ~/.emacs.  But this would be expected if the initial frame is the  
>> one in
>> the xterm.  Whereas with --daemon, the apparent initial frame is  
>> the one
>> produced by emacsclient -c.
>
> It's not, the initial frame is a special frame that cannot be  
> displayed.
> Again: emacs --daemon is equivalent to emacs -nw -f server-start
> If you try more, you can probably find even more variations of this  
> same
> basic issue...
>
>> So is this a bug or expected behavior?  If the latter, shouldn't it
>> be documented?  (I hope it's relatively easily fixed bug, since I
>> would like to have setting initial-frame-alist take effect if Emacs
>> is started with --daemon.)
>
> Patches are welcome!

Is there a reason not to use `default-frame-alist' instead?


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2427 bytes --]

Re: initial-frame-alist

[Stephen Berman]

On Thu, 5 Feb 2009 06:46:05 -0800 (PST) Dan Nicolaescu <dann@ics.uci.edu> wrote:

> Stephen Berman <stephen.berman@gmx.net> writes:
>
>   > I note that after starting Emacs like this:
>   > 
>   > $ emacs -nw -f server-start
>   > 
>   > and then in another xterm typing:
>   > 
>   > $ emacsclient -c
>   > 
>   > the resulting frame has default width and height, not those specified in
>   > ~/.emacs.  But this would be expected if the initial frame is the one in
>   > the xterm.  Whereas with --daemon, the apparent initial frame is the one
>   > produced by emacsclient -c.  
>
> It's not, the initial frame is a special frame that cannot be displayed.

I guess you are referring to FRAME_INITIAL_P.  But AFAICT this is not
the same as the "initial X window" frame created by frame-initialize,
whose parameters are held in initial-frame-alist.  I see now that
startup.el precludes this with --daemon:

  ;; Under X Window, this creates the X frame and deletes the terminal frame.
  (unless (daemonp)
    (frame-initialize))

I wonder if there is a way to make this take account of a subsequent
initial invocation of emacsclient -c.  Hmm...

> Again: emacs --daemon is equivalent to emacs -nw -f server-start
> If you try more, you can probably find even more variations of this same
> basic issue...

I'm not trying to find these cases, it's just that I run up against them
the more I use --daemon with my init-file.

>   > So is this a bug or expected behavior?  If the latter, shouldn't it
>   > be documented?  (I hope it's relatively easily fixed bug, since I
>   > would like to have setting initial-frame-alist take effect if Emacs
>   > is started with --daemon.)
>
> Patches are welcome!

I would be glad to oblige if I had more than (or even just) the vaguest
idea how to go about it.

Steve Berman

Re: initial-frame-alist

[mail]

Stephen Berman <stephen.berman@gmx.net> writes:
> It appears that setting initial-frame-alist has no effect if Emacs is
> started with --daemon; is this intended?  Here's a case in point:
>
> Let ~/.emacs consist of this sexp:
>
> (setq initial-frame-alist
>       (append initial-frame-alist '((width . 85) (height . 58))))
>
> Then do this:
>
> $ emacs --daemon
> $ emacsclient -c
>
> The resulting frame has default width and height, not those specified in
> ~/.emacs.  If instead I start Emacs like this:
>

[ SNIP ... ]

This seems like expected behaviour: there is no frame initially. Having
`emacsclient -c` work differently depending on whether or not it's the
first time it's been invoked seems wrong. If we do want to "fix" this
behaviour, then I suppose initial-frame-alist should apply to a frame in
any case where no other frame exists, ie:

  emacs --daemon
  emacsclient -c
  # initial-frame-alist applies
  emacsclient -c
  # initial-frame-alist does not apply
  # now close all of the emacs windows
  emacsclient -c
  # initial-frame-alist applies again

This behaviour should also happen if emacs was started by `emacs -nw` and
the server started there, for consistency. WDYT?

Re: initial-frame-alist

[Stefan Monnier]

> It appears that setting initial-frame-alist has no effect if Emacs is
> started with --daemon; is this intended?

Yes: it's used for the *initial* frame.  Not the *first* frame.


        Stefan

Re: initial-frame-alist

[Stephen Berman]

On Thu, 05 Feb 2009 09:13:25 -0700 mail@justinbogner.com wrote:

> Stephen Berman <stephen.berman@gmx.net> writes:
>> It appears that setting initial-frame-alist has no effect if Emacs is
>> started with --daemon; is this intended?  Here's a case in point:
>>
>> Let ~/.emacs consist of this sexp:
>>
>> (setq initial-frame-alist
>>       (append initial-frame-alist '((width . 85) (height . 58))))
>>
>> Then do this:
>>
>> $ emacs --daemon
>> $ emacsclient -c
>>
>> The resulting frame has default width and height, not those specified in
>> ~/.emacs.  If instead I start Emacs like this:
>>
>
> [ SNIP ... ]
>
> This seems like expected behaviour: there is no frame initially. Having
> `emacsclient -c` work differently depending on whether or not it's the
> first time it's been invoked seems wrong. 

Is it wrong if it's the only way that initial-frame-alist can be
effectively used with --daemon?

>                                           If we do want to "fix" this
> behaviour, then I suppose initial-frame-alist should apply to a frame in
> any case where no other frame exists, ie:
>
>   emacs --daemon
>   emacsclient -c
>   # initial-frame-alist applies
>   emacsclient -c
>   # initial-frame-alist does not apply
>   # now close all of the emacs windows
>   emacsclient -c
>   # initial-frame-alist applies again
>
> This behaviour should also happen if emacs was started by `emacs -nw` and
> the server started there, for consistency. WDYT?

This would be fine by me.

Steve Berman

initial-frame-alist

[Julianne]

I have compiled emacs-23.1 from ftp.gnu.org on both Fedora 7 and
Fedora 12.  In the .emacs file, I try to set a different background
color for the initial frame versus the default one.  When emacs is
started in either version, the initial frame geometry is as specified,
but the color is that of the default frame.  Any new frames created
follow the default list.

This the snippet from the .emacs file:

;; Setup the default behavior of and display frame created
(setq default-frame-alist
       '((width . 80)(height . 50)
        (top . 15) (left . 560)
        (background-color . "Yellow1")
        (foreground-color . "Black")
        (font . "-*-courier-medium-r-*-*-*-100-*-*-m-*-*-*")
        ))

;; Setup the initial display to be a little differnt
(setq initial-frame-alist
       '((width . 80)(height . 50)
        (top . 10) (left . 15)
        (background-color . "DarkSeaGreen1")
        (foreground-color . "Black")
        (font . "-*-courier-medium-r-*-*-*-100-*-*-m-*-*-*")
        ))

I have seen some discussion of this problem as far back as version 22.
  Has the issue been fixed?

Re: initial-frame-alist

[Peter Dyballa]

Am 26.12.2009 um 16:15 schrieb Julianne:

> When emacs is
> started in either version, the initial frame geometry is as specified,
> but the color is that of the default frame.


Confirmed! (Mac OS X) Interestingly the bug is in the X client(s) (GTK 
+2 and Xaw3d) and also for Mac OS X specific NS/Aqua/Quartz "client"  
Emacs.app. So it's deep in GNU Emacs's guts. And it must be a few  
weeks old. My Emacs.app 23.1.50 is from middle of November... (and I'm  
not often using more than one frame, damned!)

Please send a bug report! Adding my findings (before I'll do so, or  
send me your bug id/bug eMail address to add my findings)

--
Greetings

   Pete

And always remember the last words of my grandfather, who said: “A  
truck!”
				— Emo Phillips