all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Jean Louis <bugs@gnu.support>
To: Jim Porter <jporterbugs@gmail.com>
Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
Subject: Re: [RFC] Option to kill `emacs --daemon' when closing the last client frame
Date: Mon, 25 Oct 2021 09:11:08 +0300	[thread overview]
Message-ID: <YXZKfK7RwMc4gHvd@protected.localdomain> (raw)
In-Reply-To: <ed048cc6-fe32-7915-b389-e03d72c85cc9@gmail.com>

* 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/



  parent reply	other threads:[~2021-10-25  6:11 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-20  4:20 [RFC] Option to kill `emacs --daemon' when closing the last client frame Jim Porter
2021-10-20  4:36 ` Tomasz Konojacki
2021-10-20 20:07   ` Jim Porter
2021-10-21  6:07     ` Eli Zaretskii
2021-10-22  2:42       ` Jim Porter
2021-10-22  6:41         ` Eli Zaretskii
2021-10-23 20:38           ` Jim Porter
2021-10-20 12:13 ` Eli Zaretskii
2021-10-21  3:43   ` Jim Porter
2021-10-21  7:34     ` Eli Zaretskii
2021-10-22  2:58       ` Jim Porter
2021-10-22 19:51       ` Gregor Zattler
2021-10-23  6:23         ` Eli Zaretskii
2021-10-23  7:45           ` Gregor Zattler
2021-10-23  8:23             ` Eli Zaretskii
2021-10-23 18:41               ` Gregor Zattler
2021-10-25  6:11     ` Jean Louis [this message]
2021-10-25 17:18       ` Jim Porter
2021-10-22 11:58 ` Stefan Monnier
2021-10-24 21:49   ` Jim Porter
2021-10-25  6:19   ` Jean Louis
2021-10-25 18:06     ` Jim Porter
2021-10-23 19:57 ` Gregory Heytings
2021-10-24 11:54   ` Gregory Heytings
2021-10-24 15:17     ` Gregory Heytings
2021-11-08  5:13       ` chad
2021-10-25  6:20   ` Jean Louis
2021-10-25  7:37     ` Gregory Heytings
  -- strict thread matches above, loose matches on Subject: below --
2021-10-25 22:38 Peter Oliver

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YXZKfK7RwMc4gHvd@protected.localdomain \
    --to=bugs@gnu.support \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=jporterbugs@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.