From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dan Nicolaescu Newsgroups: gmane.emacs.bugs Subject: bug#1058: 23.0.60; emacs --daemon should not return until socket is ready Date: Tue, 7 Oct 2008 08:31:47 -0700 (PDT) Message-ID: <200810071531.m97FVlPt007507@mothra.ics.uci.edu> 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> Reply-To: Dan Nicolaescu , 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 1223395011 8580 80.91.229.12 (7 Oct 2008 15:56:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 7 Oct 2008 15:56:51 +0000 (UTC) Cc: trentbuck@gmail.com, 1058@emacsbugs.donarmstrong.com, Romain Francoise To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Oct 07 17:57:44 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 1KnEqP-0007G6-Ql for geb-bug-gnu-emacs@m.gmane.org; Tue, 07 Oct 2008 17:51:30 +0200 Original-Received: from localhost ([127.0.0.1]:55513 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KnEpL-0006ID-WB for geb-bug-gnu-emacs@m.gmane.org; Tue, 07 Oct 2008 11:50:24 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KnEp5-0006Ar-DY for bug-gnu-emacs@gnu.org; Tue, 07 Oct 2008 11:50:07 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KnEp2-00069l-NA for bug-gnu-emacs@gnu.org; Tue, 07 Oct 2008 11:50:06 -0400 Original-Received: from [199.232.76.173] (port=56014 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KnEp1-00068t-Sf for bug-gnu-emacs@gnu.org; Tue, 07 Oct 2008 11:50:04 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:57469) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KnEoz-0001mP-R5 for bug-gnu-emacs@gnu.org; Tue, 07 Oct 2008 11:50:02 -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 m97FnvGa003797; Tue, 7 Oct 2008 08:49:57 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.13.8/8.13.8/Submit) id m97Fe5EL001547; Tue, 7 Oct 2008 08:40:05 -0700 X-Loop: don@donarmstrong.com Resent-From: Dan Nicolaescu Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Tue, 07 Oct 2008 15:40:05 +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.122339352932620 (code B ref 1058); Tue, 07 Oct 2008 15:40:05 +0000 Original-Received: (at 1058) by emacsbugs.donarmstrong.com; 7 Oct 2008 15:32:09 +0000 Original-Received: from barrelv2.ics.uci.edu (barrelv2.ics.uci.edu [128.195.1.114]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m97FW08e032614 for <1058@emacsbugs.donarmstrong.com>; Tue, 7 Oct 2008 08:32:01 -0700 Original-Received: from mothra.ics.uci.edu (mothra.ics.uci.edu [128.195.6.93]) by barrelv2.ics.uci.edu (8.13.7+Sun/8.13.7) with ESMTP id m97FVmJD013365; Tue, 7 Oct 2008 08:31:49 -0700 (PDT) Original-Received: (from dann@localhost) by mothra.ics.uci.edu (8.13.8+Sun/8.13.6/Submit) id m97FVlPt007507; Tue, 7 Oct 2008 08:31:47 -0700 (PDT) In-Reply-To: (Stefan Monnier's message of "Tue, 07 Oct 2008 10:26:46 -0400") Original-Lines: 56 X-ICS-MailScanner-Information: Please contact the ISP for more information X-ICS-MailScanner-ID: m97FVmJD013365 X-ICS-MailScanner: Found to be clean X-ICS-MailScanner-SpamCheck: not spam, SpamAssassin (score=-1.44, required 5, autolearn=disabled, ALL_TRUSTED -1.44) X-ICS-MailScanner-From: dann@mothra.ics.uci.edu X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Resent-Date: Tue, 07 Oct 2008 11:50:06 -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:21215 Archived-At: Stefan Monnier writes: > > Errors in ~/.emacs show up in the *Messages* buffer (as they do when > > starting up normally). There are multiple issues being discussed here. 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: --- server.el.~1.168.~ 2008-09-24 17:34:59.000000000 -0700 +++ server.el 2008-10-07 08:09:16.000000000 -0700 @@ -606,7 +606,9 @@ Server mode runs a process that accepts (process-put proc 'terminal (frame-terminal frame)) ;; Display *scratch* by default. - (switch-to-buffer (get-buffer-create "*scratch*") 'norecord) + (switch-to-buffer + (get-buffer-create + (if init-file-had-error "*Messages*" "*scratch*")) 'norecord) ;; Reply with our pid. (server-send-string proc (concat "-emacs-pid " 2. During the normal interactive startup the splash screen nowadays covers the *Messages* buffer too fast, so the user can miss the error. I should file a bug about this... > 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. > 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. 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. 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.