From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Dan Nicolaescu <dann@ics.uci.edu>
Cc: trentbuck@gmail.com, 1058@emacsbugs.donarmstrong.com,
Romain Francoise <romain@orebokech.com>
Subject: bug#1058: 23.0.60; emacs --daemon should not return until socket is ready
Date: Tue, 07 Oct 2008 22:25:44 -0400 [thread overview]
Message-ID: <jwvd4ib6dy0.fsf-monnier+emacsbugreports@gnu.org> (raw)
In-Reply-To: <200810071531.m97FVlPt007507@mothra.ics.uci.edu> (Dan Nicolaescu's message of "Tue, 7 Oct 2008 08:31:47 -0700 (PDT)")
> 1.
>> But is the *Messages* buffer automatically displayed (as is done when
>> starting up normally)?
> Not yet, but it just takes one extra `if' to do it:
Actually, I don't care much that issue right now. I'd rather remove the
issue altogether than try and fix it.
>> This is the main reason why I think that .emacs messages should go
>> to stdout.
> 3. There's no code in emacs now that can do that for interactive
> sessions, and when I looked at this it did not look that it can be a
> small change acceptable during the feature freeze. The `noninteractive'
> code has it's claws in too many places.
I'm not sure it's the case: my Emacs does send the .emacs's messages to
stdout before opening the initial X11 frame and I can't remember having
to make many significant changes for that, mostly I introduced a new var
`uninitialized' (set to nil before loading .emacs and to t afterwards)
and then changed a bunch of places that check `noninteractive' to check
`noninteractive || uninintialized'.
>> Especially since the error might even be something that breaks the
>> server, so you can't connect later on to take a look at the
>> *Messages* buffer.
> 5. Making the output go to stdout does not avoid this problem at all, it
> reduces the possibility somewhat, but it does not avoid it.
To the contrary, it eliminates the problem altogether: no need to access
the *Messages* buffer since you already get the relevant info straight
from stdout.
> 6. But my original code to start the server early minimizes the window
> of opportunity for problems in starting the server, the more .emacs,
> default.el, site-start.el code you run, the more potential for problems
> in starting the server later. Yes, starting the server early was
> entirely intentional.
I see what you mean. It might indeed make things simpler, but it
eliminates a lot of flexibility.
> 7. This bug report is about something else:
> emacs --daemon && emacsclient -c
> not working. Romain's patch looks good, it does not add features, it's
> just a bug fix, so I don't see any reason it cannot go in right now.
Looking at your patch again, I think it's indeed going in the
right direction. A few notes/questions, tho:
I'd rather have just a `daemon-detach' and then be able to call
server-start separately from startup.el. Maybe a way to get that is to
leave the fork in emacs.c and to turn daemon-detach into little more
than close (daemon_pipe[1]). WDYT?
Stefan
next prev parent reply other threads:[~2008-10-08 2:25 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-30 13:43 bug#1058: 23.0.60; emacs --daemon should not return until socket is ready SRS0+wOMF+22+gmail.com=trentbuck
2008-10-01 16:51 ` Dan Nicolaescu
2008-10-01 19:39 ` Romain Francoise
2008-10-01 20:19 ` Andreas Schwab
2008-10-02 6:05 ` Romain Francoise
2008-10-01 23:32 ` Dan Nicolaescu
2008-10-02 6:07 ` Romain Francoise
2008-10-02 8:14 ` Dan Nicolaescu
2008-10-02 12:38 ` Stefan Monnier
2008-10-02 17:26 ` Dan Nicolaescu
2008-10-02 21:32 ` Stefan Monnier
2008-10-02 22:34 ` Dan Nicolaescu
2008-10-02 22:46 ` Trent W. Buck
2008-10-03 1:12 ` Stefan Monnier
2008-10-03 4:52 ` Dan Nicolaescu
2008-10-03 13:00 ` Stefan Monnier
2008-10-03 17:44 ` Dan Nicolaescu
2008-10-13 2:03 ` Dan Nicolaescu
2008-10-13 15:16 ` Stefan Monnier
2008-10-13 17:01 ` Dan Nicolaescu
2008-10-13 19:07 ` Stefan Monnier
2008-10-14 7:26 ` Dan Nicolaescu
2008-10-27 7:04 ` Dan Nicolaescu
2008-10-02 22:42 ` Trent W. Buck
2008-10-02 17:54 ` Romain Francoise
2008-10-02 18:40 ` Dan Nicolaescu
2008-10-06 20:59 ` Dan Nicolaescu
2008-10-07 14:26 ` Stefan Monnier
2008-10-07 15:31 ` Dan Nicolaescu
2008-10-07 23:13 ` Trent W. Buck
2008-10-08 2:03 ` Stefan Monnier
2008-10-08 2:25 ` Stefan Monnier [this message]
2008-10-07 18:45 ` Romain Francoise
2008-10-07 19:01 ` Dan Nicolaescu
2008-10-26 19:24 ` Dan Nicolaescu
2008-10-02 0:50 ` Trent W. Buck
2008-10-02 0:43 ` Trent W. Buck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvd4ib6dy0.fsf-monnier+emacsbugreports@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=1058@emacsbugs.donarmstrong.com \
--cc=dann@ics.uci.edu \
--cc=romain@orebokech.com \
--cc=trentbuck@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.