bug#1058: 23.0.60; emacs --daemon should not return until socket is ready

[Stefan Monnier <monnier@iro.umontreal.ca>]

> 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