GNU bug report logs - #1058
23.0.60; emacs --daemon should not return until socket is ready

Previous Next

Full log

Message #95 received at 1058 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Dan Nicolaescu <dann <at> ics.uci.edu>
Cc: 1058 <at> debbugs.gnu.org, trentbuck <at> gmail.com,
        Romain Francoise <romain <at> orebokech.com>
Subject: Re: bug#1058: 23.0.60; emacs --daemon should not return until socket is ready
Date: Thu, 02 Oct 2008 21:12:02 -0400

> Is that desirable?  We seem to be looking at this from different points
> of view.  I want the daemon to start the server early, and that should
> be the only way to interact with it.  You want to have a full blown
> emacs until the server is started...

I think we agree: I also want a full blown Emacs until the server is
started.  But I also want to run some Elisp code (especially the .emacs)
before the server is started.

> IMHO if someone's .emacs wants to chat during startup, then he needs to
> fix his  .emacs if he wants to use --daemon.

Agreed.

> Chatty deamons are evil (or devils?). :-)

But daemons which fork before detecting if there's an error somewhere
and hence don't report such errors are even more evil.

>> That means that detaching needs indeed to be done late if we want to do
>> it right.  Of course, that means it's more difficult to implement since
>> it can be called in many more different contexts (we can/should reject
>> most of them, but we still need to test/detect the undesirable ones).
> Looking at it again, it should not be too bad, tedious, but not complicated.

Could be.

> Depending on what the definition if "right" is... If it means enabling
> interaction before detaching, then you might be right (haven't checked).
> If it means the patch that Romain posted, that should be fine to go in
> now.

I can't tell yet whether Romain's patch does the right thing: do errors
in .emacs get properly reported to stdout?

>> What happens to messages resulting from executing .emacs in solution nb
>> 2 are they sent to stdout or are they silently dropped?
> deamon's stdin/stdout/stderr go to /dev/null.

That's mostly OK, but not before the .emacs (and --eval) get processed.

>> PS: Currently "emacs --daemon" doesn't do anything for me: it
>> immediately (as in "I've never seen Emacs start or stop so fast")
>> returns with no output and no remaining process.

> How about "emacs -Q --daemon" ?

Same thing.

> Is this CVS HEAD, or your famous patched tree?

;-)  CVS HEAD.


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.