Re: initial-frame-alist

[Stephen Berman <stephen.berman@gmx.net>]

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