From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [RFC] Option to kill `emacs --daemon' when closing the last client frame Date: Sat, 23 Oct 2021 11:23:21 +0300 Message-ID: <83k0i45eva.fsf@gnu.org> References: <87lf2kale2.fsf@no.workgroup> <83zgr05kfk.fsf@gnu.org> <87bl3gchhf.fsf@no.workgroup> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6822"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Gregor Zattler Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Oct 23 10:24:14 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1meCK6-0001Wt-5a for ged-emacs-devel@m.gmane-mx.org; Sat, 23 Oct 2021 10:24:14 +0200 Original-Received: from localhost ([::1]:56416 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1meCK3-0007SK-TC for ged-emacs-devel@m.gmane-mx.org; Sat, 23 Oct 2021 04:24:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48360) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1meCJV-0006lB-4Z for emacs-devel@gnu.org; Sat, 23 Oct 2021 04:23:37 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:54918) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1meCJU-00056i-8V; Sat, 23 Oct 2021 04:23:36 -0400 Original-Received: from [87.69.77.57] (port=1487 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1meCJS-00073f-Mw; Sat, 23 Oct 2021 04:23:36 -0400 In-Reply-To: <87bl3gchhf.fsf@no.workgroup> (message from Gregor Zattler on Sat, 23 Oct 2021 09:45:00 +0200) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:277602 Archived-At: > From: Gregor Zattler > Date: Sat, 23 Oct 2021 09:45:00 +0200 > > >> But what happens then if there are two emacsclients > >> connecting to the daemon, one with this hypothetical command > >> line option, the other one without and the one without is > >> the last client which closes it's connection with the > >> daemon? > > > > The new protocol command will have been sent by the first emacsclient, > > when it starts the server, so which client closes the last is > > immaterial, because the decision when to exit will be by the server > > based on that new server command it received in the beginning. > > Why is the order of events a given? It isn't. > If the protocol command is sent by emnacsclient because of a command > line option, it's up to the user if and in which order s/he chooses > to start emacsclients with/out this command -line option!? Yes, and I don't understand why you are saying this. Once the new server command was sent to the server, the server will kill Emacs when last client connection is closed. Why is that a problem, again? Please describe the entire scenario where you think this is a problem. > >> > That'd require users to modify their init files, which I think is > >> > slightly less desirable than the alternative with a new protocol > >> > command. > >> > >> Only if they want to use that new behaviour. Emacs users in > >> most cases need to do that in order to use newly changed UI > >> features. > > > > Yes, but the same is true for the new emacsclient command-line option, > > except that changing that is easier done as one-time-only thing than > > editing the init files. > > I for instance rarely call emacsclient by name from the > command-line, but only for debugging reasons. In normal > live I call it via shell scripts. These I would have to > adapt, if I would want to make use of the new command-line > option. Adapt how? If your shell scripts are well written, they accept extra command-line options anyhow, right? So all you'd need is to call that script with this additional command-line option, right? > I don't see a difference to the case of > `daemon-kill-when-no-clients' defaulting to nil. At least > this has to be set at only one place and could be done with > the customization interface. I don't necessarily object to the user option as well, but it is only useful if the user wants _all_ of his/her daemon sessions to behave like that.