From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Nix Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] A myriad of interrelated daemon-mode startup bugs Date: Tue, 13 Nov 2012 18:41:59 +0000 Message-ID: <87zk2lny4o.fsf@spindle.srvr.nix> References: <87haotpg6g.fsf@spindle.srvr.nix> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1352832131 16831 80.91.229.3 (13 Nov 2012 18:42:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 13 Nov 2012 18:42:11 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 13 19:42:20 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TYLRE-0007y7-3r for ged-emacs-devel@m.gmane.org; Tue, 13 Nov 2012 19:42:20 +0100 Original-Received: from localhost ([::1]:46689 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TYLR4-0001b0-H9 for ged-emacs-devel@m.gmane.org; Tue, 13 Nov 2012 13:42:10 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:50525) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TYLQz-0001Zi-1u for emacs-devel@gnu.org; Tue, 13 Nov 2012 13:42:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TYLQw-0001y8-08 for emacs-devel@gnu.org; Tue, 13 Nov 2012 13:42:04 -0500 Original-Received: from icebox.esperi.org.uk ([81.187.191.129]:54465 helo=mail.esperi.org.uk) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TYLQv-0001xs-KU for emacs-devel@gnu.org; Tue, 13 Nov 2012 13:42:01 -0500 Original-Received: from spindle.srvr.nix (nix@spindle.srvr.nix [192.168.14.15]) by mail.esperi.org.uk (8.14.5/8.14.5) with ESMTP id qADIfxno018284; Tue, 13 Nov 2012 18:41:59 GMT Emacs: where editing text is like playing Paganini on a glass harmonica. In-Reply-To: (Stefan Monnier's message of "Tue, 13 Nov 2012 13:34:52 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-DCC-INFN-TO-Metrics: spindle 1233; Body=2 Fuz1=2 Fuz2=2 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 81.187.191.129 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:154854 Archived-At: On 13 Nov 2012, Stefan Monnier spake thusly: >> [Stefan Cc:ed because part of this is fixing lexical-binding fallout, >> and as a way of saying thank you for fixing a bug of mine: here's a >> fix for a bug of yours! :) ] > > Actually, it's got nothing to do with lexical-binding, but is due to > a bug of mine in gv-define-simpler-setter which was fixed yesterday. Oh. you mean I wasted all that time? ;} >> --- lisp/desktop.el.orig 2012-11-13 16:36:38.833375966 +0000 >> +++ lisp/desktop.el 2012-11-13 16:38:18.634889091 +0000 >> @@ -627,6 +627,7 @@ >> (and >> (or (memq desktop-save '(ask ask-if-new)) >> (and exists (eq desktop-save 'ask-if-exists))) >> + (and (not noninteractive)) >> (y-or-n-p "Save desktop? "))))) > > No need for `and' here, but otherwise, that looks OK. Tho maybe a better > fix is to make it so y-or-n-p just returns nil when there's no live > terminal. Good idea. (Whatever part of 'noninteractive' 'no live terminal' equates to.) >> - (cl-letf (((default-file-modes) ?\700)) (make-directory dir t)) >> + (make-directory dir t ?\700) > > The cl-letf ends up doing the exact same thing, via dynamic scoping > (note how it's not a simple `let' and it doesn't bind a variable but > a "place"). Ah! Mind you, there's not much hint in the docs for cl-letf that it's dynamically bound... > I'm not completely opposed to adding a "modes" argument to > make-directory, but I'm not sure it's worth the trouble. It's a potential security hole to make directories with the wrong mode, so it seems like a good idea. (Sure, you can bind `default-file-modes', but could you really call the code above particularly clear?) >> - (server-start) >> + (condition-case err >> + (server-start) >> + (error (message (error-message-string err)))) >> (if server-process >> (daemon-initialized) >> (if (stringp dn) > > I'm not sure I understand enough of what could/should happen. E.g. how > does the above compare to using: > > (unwind-protect > (server-start) > (if server-process > (daemon-initialized) > (if (stringp dn) > ... That works, but it throws away the error message. If `server-start' raised an error, you want to show it to the user before you die. >> + ;; We must pretend to be noninteractive at this point to tell >> + ;; kill-emacs-hook functions that read input if interactive >> + ;; not to do so, since reads from stdin are shared with the >> + ;; parent. >> + (let ((noninteractive t)) >> + (kill-emacs 1))))) > > Actually, `noninteractive' can sometimes interact with the user via > stdin/stdout. OK, so that ugly kludge is presumably unnecessary? Phew. >> - /* End of file in -batch run causes exit here. */ >> - if (noninteractive) >> + /* End of file in -batch run or before the daemon is >> + initialized causes exit here. */ >> + if ((noninteractive) || >> + (IS_DAEMON && !daemon_initialized)) >> Fkill_emacs (Qt); > > How 'bout having a Lisp-exported variable that controls whether to call > kill-emacs here? Then server.el could set this var (after successfully > starting the daemon) to prevent exit. Instead of daemon-initialized? The worry there is that server-start can be called from places *other* than daemonization, and it seems like a layering violation to have it saying 'yeah, you can exit now' if it was called from somewhere else. The relevant thing here isn't really 'a server is started': it's 'we have disconnected from our parent and gone daemon, so having a command loop is acceptable because it won't mislead users into thinking Emacs has hung'. > Also, maybe the right way to solve this is to think harder about what > noninteractive means and how to split it into several variables. > E.g. one meaning is "no input events", another is "I/O is via > stdin/stdout", and another we need is "there's no I/O available right > now". That's exactly what I was thinking while I got repeatedly confused over just what 'noninteractive' meant right now. At the moment, it seems to be used to mean whichever of the above is most convenient at the time :) -- NULL && (void)