[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Thu, 05 Feb 2009 16:51:02 +0100
Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)
On Thu, 5 Feb 2009 06:46:05 -0800 (PST) Dan Nicolaescu <address@hidden> wrote:
> Stephen Berman <address@hidden> 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.
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.