From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#1058: 23.0.60; emacs --daemon should not return until socket is ready Date: Tue, 07 Oct 2008 22:25:44 -0400 Message-ID: References: <1222782234_2281@mail.internode.on.net> <200810011651.m91GpAZQ010333@mothra.ics.uci.edu> <87k5csds03.fsf@elegiac.orebokech.com> <200810012332.m91NWJ4s014658@mothra.ics.uci.edu> <874p3vediy.fsf@elegiac.orebokech.com> <200810020814.m928Ed1C016380@mothra.ics.uci.edu> <87myhmdgr8.fsf@elegiac.orebokech.com> <200810062059.m96KxaXM004646@mothra.ics.uci.edu> <200810071531.m97FVlPt007507@mothra.ics.uci.edu> Reply-To: Stefan Monnier , 1058@emacsbugs.donarmstrong.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1223434236 9024 80.91.229.12 (8 Oct 2008 02:50:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 8 Oct 2008 02:50:36 +0000 (UTC) Cc: trentbuck@gmail.com, 1058@emacsbugs.donarmstrong.com, Romain Francoise To: Dan Nicolaescu Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Oct 08 04:51:33 2008 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KnP99-0000Rz-GB for geb-bug-gnu-emacs@m.gmane.org; Wed, 08 Oct 2008 04:51:31 +0200 Original-Received: from localhost ([127.0.0.1]:35365 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KnP85-0003AI-Sn for geb-bug-gnu-emacs@m.gmane.org; Tue, 07 Oct 2008 22:50:25 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KnP7i-0002vA-2f for bug-gnu-emacs@gnu.org; Tue, 07 Oct 2008 22:50:02 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KnP7g-0002tR-I1 for bug-gnu-emacs@gnu.org; Tue, 07 Oct 2008 22:50:01 -0400 Original-Received: from [199.232.76.173] (port=48712 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KnP7g-0002tF-Ct for bug-gnu-emacs@gnu.org; Tue, 07 Oct 2008 22:50:00 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:33931) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KnP7f-0007hj-KR for bug-gnu-emacs@gnu.org; Tue, 07 Oct 2008 22:49:59 -0400 Original-Received: from rzlab.ucr.edu (rzlab.ucr.edu [127.0.0.1]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m982nvlL006129; Tue, 7 Oct 2008 19:49:58 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.13.8/8.13.8/Submit) id m982Z3pT002608; Tue, 7 Oct 2008 19:35:03 -0700 X-Loop: don@donarmstrong.com Resent-From: Stefan Monnier Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Wed, 08 Oct 2008 02:35:03 +0000 Resent-Message-ID: Resent-Sender: don@donarmstrong.com X-Emacs-PR-Message: report 1058 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Original-Received: via spool by 1058-submit@emacsbugs.donarmstrong.com id=B1058.12234327531319 (code B ref 1058); Wed, 08 Oct 2008 02:35:03 +0000 Original-Received: (at 1058) by emacsbugs.donarmstrong.com; 8 Oct 2008 02:25:53 +0000 Original-Received: from ironport2-out.teksavvy.com (ironport2-out.teksavvy.com [206.248.154.182]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m982PoRW001313 for <1058@emacsbugs.donarmstrong.com>; Tue, 7 Oct 2008 19:25:51 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AowFAB+360jO+IH3/2dsb2JhbACBcrxigWqBB4Id X-IronPort-AV: E=Sophos;i="4.33,376,1220241600"; d="scan'208";a="28132099" Original-Received: from 206-248-129-247.dsl.teksavvy.com (HELO pastel.home) ([206.248.129.247]) by ironport2-out.teksavvy.com with ESMTP; 07 Oct 2008 22:25:44 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 538ED8568; Tue, 7 Oct 2008 22:25:44 -0400 (EDT) In-Reply-To: <200810071531.m97FVlPt007507@mothra.ics.uci.edu> (Dan Nicolaescu's message of "Tue, 7 Oct 2008 08:31:47 -0700 (PDT)") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Resent-Date: Tue, 07 Oct 2008 22:50:01 -0400 X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:21252 Archived-At: > 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