all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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: Thu, 02 Oct 2008 21:12:02 -0400	[thread overview]
Message-ID: <jwv1vyyjxld.fsf-monnier+emacsbugreports@gnu.org> (raw)
In-Reply-To: <200810022234.m92MYgYp018688@mothra.ics.uci.edu> (Dan Nicolaescu's message of "Thu, 2 Oct 2008 15:34:42 -0700 (PDT)")

> 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






  parent reply	other threads:[~2008-10-03  1:12 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 [this message]
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
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=jwv1vyyjxld.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.