From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jean Louis Newsgroups: gmane.emacs.devel Subject: Re: [RFC] Option to kill `emacs --daemon' when closing the last client frame Date: Mon, 25 Oct 2021 09:11:08 +0300 Message-ID: References: <83h7dbc2sl.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30233"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/2.0.7+183 (3d24855) (2021-05-28) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Jim Porter Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Oct 25 08:17:48 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 1metIq-0007fn-1A for ged-emacs-devel@m.gmane-mx.org; Mon, 25 Oct 2021 08:17:48 +0200 Original-Received: from localhost ([::1]:41256 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1metIo-0000kd-2Q for ged-emacs-devel@m.gmane-mx.org; Mon, 25 Oct 2021 02:17:46 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60174) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1metGw-0007d0-Et for emacs-devel@gnu.org; Mon, 25 Oct 2021 02:15:51 -0400 Original-Received: from stw1.rcdrun.com ([217.170.207.13]:37997) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1metGt-0004N7-FI; Mon, 25 Oct 2021 02:15:49 -0400 Original-Received: from localhost ([::ffff:41.75.189.151]) (AUTH: PLAIN admin, TLS: TLS1.3,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA id 0000000000027F05.0000000061764B90.000001B0; Sun, 24 Oct 2021 23:15:43 -0700 Mail-Followup-To: Jim Porter , Eli Zaretskii , emacs-devel@gnu.org Content-Disposition: inline In-Reply-To: Received-SPF: pass client-ip=217.170.207.13; envelope-from=bugs@gnu.support; helo=stw1.rcdrun.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:277708 Archived-At: * Jim Porter [2021-10-21 06:44]: > On 10/20/2021 5:13 AM, Eli Zaretskii wrote: > > Unlike "other programs", Emacs doesn't aim to support such use > > patterns with the ALTERNATE_EDITOR thing. It is supposed to allow the > > user to invoke emacsclient without knowing whether a server already > > runs, by starting the server the first time. That is why we don't > > kill the server when the last client exits: it is against the use case > > we want to support. > > My expectation (which is really just personal preference informed by other > programs I'm used to) is that since `emacs --daemon' is created on as-needed > basis in this configuration, it would also be killed when it's no longer > needed. If I wanted `emacs --daemon' to live forever, I'd probably just set > it up to start when my system boots. Your particular user habit is not to use continuously running daemon, and then you invoke rather emacs client from time to time to handle some stuff. I am always running Emacs daemon and always using emacsclient. From my perspective your logic and viewpoint is quite different to mine. If I need to kill the daemon I would do M-x save-buffers-kill-emacs -- this would be done rarely. Why in particular don't you use continuously the Emacs daemon if you are already invoking many times emacsclient? > However, I don't know if I can make a particularly compelling argument as to > why this *should* be how things work, aside from just saying that I find the > symmetry of this behavior simpler/easier to remember. It's in the same vein > as a refcounted object in a program (e.g. `std::shared_ptr' for C++ > programmers): I can make new `emacsclient's, which increment the refcount, > and once the refcount drops to 0, the underlying entity (i.e. the daemon) is > automatically cleaned up. What you forgot to mention is that many buffers and files could be open in the same time, some of them unsaved. It is not just a question of emacsclient. A browser may not have "open files", it is not equivalent to Emacs as it has more static configuration. > That's one option, although it might take a bit of work to support that > (assuming I understand what you mean). As far as I understand how > ALTERNATE_EDITOR works, there's not an easy way to automatically start the > Emacs daemon *and* provide it with some extra options. That is, > ALTERNATE_EDITOR="emacs --daemon --foo" would start the daemon, but wouldn't > create a client to connect to it. >From Window Manager, I am using a script to start emacsclient, but if daemon is not running, first daemon has to be invoked, then new frame is opened. Similar from console. > Another method might be to add an option like `daemon-kill-when-no-clients' > that defaults to nil. Then after an `emacsclient' is killed, we can consult > that variable, and if it's true, kill the daemon if there are no remaining > clients. I don't think clients are important there. What is important are buffers and open files, some unfinished work. `daemon-kill-when-no-clients' makes no sense to me. I would not like not even by mistake to accidentally remove the last client and that my buffers and open files are lost because I have set the option to quit that way. I am using daemon option in the first place exactly to avoid the situation you wish to create. I don't want Emacs killed by removing the last frame. If client is open or not, I don't mind. I can always remove the frame. I do mind if buffer is open, notes, temporary buffer with notes, or open files, and would not like losing such. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/