* initial-frame-alist
@ 2009-02-05 11:24 Stephen Berman
2009-02-05 14:46 ` initial-frame-alist Dan Nicolaescu
` (2 more replies)
0 siblings, 3 replies; 9+ messages in thread
From: Stephen Berman @ 2009-02-05 11:24 UTC (permalink / raw
To: emacs-devel
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: initial-frame-alist
2009-02-05 11:24 initial-frame-alist Stephen Berman
@ 2009-02-05 14:46 ` Dan Nicolaescu
2009-02-05 15:13 ` initial-frame-alist Will Farrington
2009-02-05 15:51 ` initial-frame-alist Stephen Berman
2009-02-05 16:13 ` initial-frame-alist mail
2009-02-05 19:38 ` initial-frame-alist Stefan Monnier
2 siblings, 2 replies; 9+ messages in thread
From: Dan Nicolaescu @ 2009-02-05 14:46 UTC (permalink / raw
To: Stephen Berman; +Cc: emacs-devel
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!
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: initial-frame-alist
2009-02-05 14:46 ` initial-frame-alist Dan Nicolaescu
@ 2009-02-05 15:13 ` Will Farrington
2009-02-05 15:51 ` initial-frame-alist Stephen Berman
1 sibling, 0 replies; 9+ messages in thread
From: Will Farrington @ 2009-02-05 15:13 UTC (permalink / raw
To: Dan Nicolaescu; +Cc: Stephen Berman, emacs-devel
[-- 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 --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: initial-frame-alist
2009-02-05 14:46 ` initial-frame-alist Dan Nicolaescu
2009-02-05 15:13 ` initial-frame-alist Will Farrington
@ 2009-02-05 15:51 ` Stephen Berman
1 sibling, 0 replies; 9+ messages in thread
From: Stephen Berman @ 2009-02-05 15:51 UTC (permalink / raw
To: emacs-devel
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: initial-frame-alist
2009-02-05 11:24 initial-frame-alist Stephen Berman
2009-02-05 14:46 ` initial-frame-alist Dan Nicolaescu
@ 2009-02-05 16:13 ` mail
2009-02-05 23:19 ` initial-frame-alist Stephen Berman
2009-02-05 19:38 ` initial-frame-alist Stefan Monnier
2 siblings, 1 reply; 9+ messages in thread
From: mail @ 2009-02-05 16:13 UTC (permalink / raw
To: emacs-devel
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?
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: initial-frame-alist
2009-02-05 11:24 initial-frame-alist Stephen Berman
2009-02-05 14:46 ` initial-frame-alist Dan Nicolaescu
2009-02-05 16:13 ` initial-frame-alist mail
@ 2009-02-05 19:38 ` Stefan Monnier
2 siblings, 0 replies; 9+ messages in thread
From: Stefan Monnier @ 2009-02-05 19:38 UTC (permalink / raw
To: Stephen Berman; +Cc: emacs-devel
> 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: initial-frame-alist
2009-02-05 16:13 ` initial-frame-alist mail
@ 2009-02-05 23:19 ` Stephen Berman
0 siblings, 0 replies; 9+ messages in thread
From: Stephen Berman @ 2009-02-05 23:19 UTC (permalink / raw
To: emacs-devel
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* initial-frame-alist
@ 2009-12-26 15:15 Julianne
2009-12-28 0:02 ` initial-frame-alist Peter Dyballa
0 siblings, 1 reply; 9+ messages in thread
From: Julianne @ 2009-12-26 15:15 UTC (permalink / raw
To: help-gnu-emacs
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?
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: initial-frame-alist
2009-12-26 15:15 initial-frame-alist Julianne
@ 2009-12-28 0:02 ` Peter Dyballa
0 siblings, 0 replies; 9+ messages in thread
From: Peter Dyballa @ 2009-12-28 0:02 UTC (permalink / raw
To: Julianne; +Cc: help-gnu-emacs
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
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2009-12-28 0:02 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-02-05 11:24 initial-frame-alist Stephen Berman
2009-02-05 14:46 ` initial-frame-alist Dan Nicolaescu
2009-02-05 15:13 ` initial-frame-alist Will Farrington
2009-02-05 15:51 ` initial-frame-alist Stephen Berman
2009-02-05 16:13 ` initial-frame-alist mail
2009-02-05 23:19 ` initial-frame-alist Stephen Berman
2009-02-05 19:38 ` initial-frame-alist Stefan Monnier
-- strict thread matches above, loose matches on Subject: below --
2009-12-26 15:15 initial-frame-alist Julianne
2009-12-28 0:02 ` initial-frame-alist Peter Dyballa
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.