emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC] Option to kill `emacs --daemon' when closing the last client f


From: Jean Louis
Subject: Re: [RFC] Option to kill `emacs --daemon' when closing the last client frame
Date: Mon, 25 Oct 2021 09:11:08 +0300
User-agent: Mutt/2.0.7+183 (3d24855) (2021-05-28)

* Jim Porter <jporterbugs@gmail.com> [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/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]