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

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

[Jim Porter]

I've been experimenting with using `emacs --daemon' and found one part 
of it to be somewhat surprising. If I set `ALTERNATE_EDITOR' to the 
empty string and run emacsclient, it runs `emacs --daemon' and connects 
to it; so far so good. But when I close the Emacs client, the Emacs 
daemon sticks around; I'd prefer the daemon to stop as well.

This would allow for a behavior similar to other (graphical) programs: 
if I run `firefox example.com', it starts a new instance as normal. If I 
run it again, it opens a new tab in the existing instance. If I close 
all the Firefox windows, all the associated processes terminate.

I didn't see any options to configure this behavior in Emacs, but 
looking over the code, it shouldn't be that hard for me to write a patch 
to add this as an option. Before I started though, I wanted to see what 
others thought. Is this a behavior others would be interested in? If so, 
are there any other particulars I should take into account in my patch?

- Jim

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

[Tomasz Konojacki]

On Tue, 19 Oct 2021 21:20:35 -0700
Jim Porter <jporterbugs@gmail.com> wrote:

> I've been experimenting with using `emacs --daemon' and found one part of it to be somewhat surprising. If I set `ALTERNATE_EDITOR' to the empty string and run emacsclient, it runs `emacs --daemon' and connects to it; so far so good. But when I close the Emacs client, the Emacs daemon sticks around; I'd prefer the daemon to stop as well.
> 
> This would allow for a behavior similar to other (graphical) programs: if I run `firefox example.com', it starts a new instance as normal. If I run it again, it opens a new tab in the existing instance. If I close all the Firefox windows, all the associated processes terminate.
> 
> I didn't see any options to configure this behavior in Emacs, but looking over the code, it shouldn't be that hard for me to write a patch to add this as an option. Before I started though, I wanted to see what others thought. Is this a behavior others would be interested in? If so, are there any other particulars I should take into account in my patch?
> 
> - Jim

You will get that behaviour if you put (server-start) in your init.el
and set --alternate-editor to the emacs binary, not just an empty string.

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

[Eli Zaretskii]

> From: Jim Porter <jporterbugs@gmail.com>
> Date: Tue, 19 Oct 2021 21:20:35 -0700
> 
> I've been experimenting with using `emacs --daemon' and found one part 
> of it to be somewhat surprising. If I set `ALTERNATE_EDITOR' to the 
> empty string and run emacsclient, it runs `emacs --daemon' and connects 
> to it; so far so good. But when I close the Emacs client, the Emacs 
> daemon sticks around; I'd prefer the daemon to stop as well.
> 
> This would allow for a behavior similar to other (graphical) programs: 
> if I run `firefox example.com', it starts a new instance as normal. If I 
> run it again, it opens a new tab in the existing instance. If I close 
> all the Firefox windows, all the associated processes terminate.

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.

We could add an optional command-line argument to do what you want,
but I wonder why would that be useful, when we already have
kill-emacs.

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

[Jim Porter]

On 10/19/2021 9:36 PM, Tomasz Konojacki wrote:
> On Tue, 19 Oct 2021 21:20:35 -0700
> Jim Porter <jporterbugs@gmail.com> wrote:
> 
>> I've been experimenting with using `emacs --daemon' and found one part of it to be somewhat surprising. If I set `ALTERNATE_EDITOR' to the empty string and run emacsclient, it runs `emacs --daemon' and connects to it; so far so good. But when I close the Emacs client, the Emacs daemon sticks around; I'd prefer the daemon to stop as well.
> 
> You will get that behaviour if you put (server-start) in your init.el
> and set --alternate-editor to the emacs binary, not just an empty string.

Right, that's what I currently do. However, I've run into a couple 
problems that have made me think `emacs --daemon' would be a better 
solution. Under a non-daemon[1] configuration:

1) `org-protocol://' links don't work if Emacs isn't already running. 
This is because org-protocol advises `server-visit-files' to detect when 
a link with that protocol is passed as a file argument on the command 
line. Since this argument is passed to the "alternate" Emacs, it's not 
handled in `server-visit-files' and so the org-protocol code never runs.

2) The first place Emacs is opened is the "primary" instance. This isn't 
usually a problem when you only run Emacs graphically, but if mixing GUI 
and terminal instances, it'd be nice to allow closing the first instance 
and keep the others open. For example, if you start editing in a 
terminal Emacs and open a GUI Emacs client, the GUI Emacs can only live 
as long as the terminal one.

The first issue is probably fixable for non-daemon configurations, but 
the second is more fundamental and pushed me over the edge to (trying 
to) swap to `emacs --daemon'.

- Jim

[1] An "aengel" configuration?

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

[Jim Porter]

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.

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.

In the end though, it's just what I like / what makes the most sense to 
me. If other people see things similarly, I'd be happy to write a patch, 
but if I'm the only one who wants this, then I can always customize my 
.emacs to my liking instead.

> We could add an optional command-line argument to do what you want,
> but I wonder why would that be useful, when we already have
> kill-emacs.

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.

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.

- Jim

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

[Eli Zaretskii]

> From: Jim Porter <jporterbugs@gmail.com>
> Date: Wed, 20 Oct 2021 13:07:02 -0700
> Cc: emacs-devel@gnu.org
> 
> > You will get that behaviour if you put (server-start) in your init.el
> > and set --alternate-editor to the emacs binary, not just an empty string.
> 
> Right, that's what I currently do. However, I've run into a couple 
> problems that have made me think `emacs --daemon' would be a better 
> solution. Under a non-daemon[1] configuration:
> 
> 1) `org-protocol://' links don't work if Emacs isn't already running. 
> This is because org-protocol advises `server-visit-files' to detect when 
> a link with that protocol is passed as a file argument on the command 
> line. Since this argument is passed to the "alternate" Emacs, it's not 
> handled in `server-visit-files' and so the org-protocol code never runs.

This sounds like a problem in org-protocol that should be solved
there.  If doing so requires some core feature we don't have, let's
discuss that missing feature.  But changing the behavior of the
daemon, which will affect also all the other use cases unrelated to
this one, is not TRT, IMO.

> 2) The first place Emacs is opened is the "primary" instance. This isn't 
> usually a problem when you only run Emacs graphically, but if mixing GUI 
> and terminal instances, it'd be nice to allow closing the first instance 
> and keep the others open. For example, if you start editing in a 
> terminal Emacs and open a GUI Emacs client, the GUI Emacs can only live 
> as long as the terminal one.

I don't follow this one.  What exactly do you mean by "primary" here,
and what do you mean by "instance"?  In the scenario you described
there's only one instance of Emacs running, as I'm sure you know very
well.  Please elaborate.

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

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Jim Porter <jporterbugs@gmail.com>
> Date: Wed, 20 Oct 2021 20:43:31 -0700
> 
> > We could add an optional command-line argument to do what you want,
> > but I wonder why would that be useful, when we already have
> > kill-emacs.
> 
> 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.

We could add a new command to the server-client protocol, and make
emacsclient send this command when invoked with the (hypothetical) new
command-line option.

> 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.

That'd require users to modify their init files, which I think is
slightly less desirable than the alternative with a new protocol
command.

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

[Jim Porter]

On 10/20/2021 11:07 PM, Eli Zaretskii wrote:
>> From: Jim Porter <jporterbugs@gmail.com>
>> Date: Wed, 20 Oct 2021 13:07:02 -0700
>> Cc: emacs-devel@gnu.org
>>
>>> You will get that behaviour if you put (server-start) in your init.el
>>> and set --alternate-editor to the emacs binary, not just an empty string.
>>
>> Right, that's what I currently do. However, I've run into a couple
>> problems that have made me think `emacs --daemon' would be a better
>> solution. Under a non-daemon[1] configuration:
>>
>> 1) `org-protocol://' links don't work if Emacs isn't already running.
>> This is because org-protocol advises `server-visit-files' to detect when
>> a link with that protocol is passed as a file argument on the command
>> line. Since this argument is passed to the "alternate" Emacs, it's not
>> handled in `server-visit-files' and so the org-protocol code never runs.
> 
> This sounds like a problem in org-protocol that should be solved
> there.  If doing so requires some core feature we don't have, let's
> discuss that missing feature.  But changing the behavior of the
> daemon, which will affect also all the other use cases unrelated to
> this one, is not TRT, IMO.

Agreed. Before I came across issue (2) below, my plan was simply to fix 
this without changing the daemon's behavior. I think a core fix would be 
generally useful though, and once I've looked into it more, I'll send a 
message to the list with more thoughts.

>> 2) The first place Emacs is opened is the "primary" instance. This isn't
>> usually a problem when you only run Emacs graphically, but if mixing GUI
>> and terminal instances, it'd be nice to allow closing the first instance
>> and keep the others open. For example, if you start editing in a
>> terminal Emacs and open a GUI Emacs client, the GUI Emacs can only live
>> as long as the terminal one.
> 
> I don't follow this one.  What exactly do you mean by "primary" here,
> and what do you mean by "instance"?  In the scenario you described
> there's only one instance of Emacs running, as I'm sure you know very
> well.  Please elaborate.

I hope an example will illustrate what I mean[1]. I start with two 
terminals open, A and B[2]. In terminal A, I run `emacs -nw foo.txt'. In 
terminal B, I run `emacsclient -nw -c bar.txt'. Now, suppose I want to 
stop editing foo.txt in terminal A and go back to doing something else. 
I'd type `C-x C-c', but then my emacsclient in terminal B will close too.

However, using the daemon configuration with ALTERNATE_EDITOR="", I 
could run `emacsclient -nw -c ...' in each terminal. Then when I type 
`C-x C-c' in terminal A, it only kills that client, not the daemon 
process. I can then continue to edit in terminal B without interruption.

Of course, this isn't a bug, it's just how emacs and emacsclient work 
together when not using `emacs --daemon'. It just turned out to be 
inconvenient for how I use Emacs, so I've moved to using `emacs 
--daemon' instead.

- Jim

[1] It might be best to ignore my original terminology since it wasn't 
very clear. However, for completeness, by "primary" I meant "the actual 
`emacs' process", and by "instance" I meant "the set of frames 
associated with a particular Emacs client, including 'no client'".

[2] This happens in a GUI too, but I think it's easier to see with 
terminals.

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

[Jim Porter]

On 10/21/2021 12:34 AM, Eli Zaretskii wrote:
> We could add a new command to the server-client protocol, and make
> emacsclient send this command when invoked with the (hypothetical) new
> command-line option.

That makes sense. I'll put together a patch, at least to demonstrate how 
it would work so others can try it.

- Jim

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

[Eli Zaretskii]

> Cc: me@xenu.pl, emacs-devel@gnu.org
> From: Jim Porter <jporterbugs@gmail.com>
> Date: Thu, 21 Oct 2021 19:42:23 -0700
> 
> I hope an example will illustrate what I mean[1]. I start with two 
> terminals open, A and B[2]. In terminal A, I run `emacs -nw foo.txt'. In 
> terminal B, I run `emacsclient -nw -c bar.txt'. Now, suppose I want to 
> stop editing foo.txt in terminal A and go back to doing something else. 
> I'd type `C-x C-c', but then my emacsclient in terminal B will close too.

No, it should say the session has client, and ask for confirmation.

You also have C-z to temporarily suspend the session on A.

> However, using the daemon configuration with ALTERNATE_EDITOR="", I 
> could run `emacsclient -nw -c ...' in each terminal. Then when I type 
> `C-x C-c' in terminal A, it only kills that client, not the daemon 
> process. I can then continue to edit in terminal B without interruption.
> 
> Of course, this isn't a bug, it's just how emacs and emacsclient work 
> together when not using `emacs --daemon'. It just turned out to be 
> inconvenient for how I use Emacs, so I've moved to using `emacs 
> --daemon' instead.

Which is exactly why we provided the daemon mode, so I see no problem
here, I see a solution for a particular class of use patterns.

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

[Stefan Monnier]

> This would allow for a behavior similar to other (graphical) programs: if
> I run `firefox example.com', it starts a new instance as normal. If I run it
> again, it opens a new tab in the existing instance. If I close all the
> Firefox windows, all the associated processes terminate.

I guess it would make sense to try and distinguish the two cases:

- Eager: `emacs --daemon` is run (typically from something like a login
  script or systemd) before any emacsclient is involved.
- Lazy: `emacs --daemon` is started on-demand by the `-a` option
  of `emacsclient` (or via ALTERNATE_EDITOR).

In the lazy case, we could kill the daemon when the last client exits.


        Stefan

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

[Gregor Zattler]

Hi Eli, emacs developers,
* Eli Zaretskii <eliz@gnu.org> [2021-10-21; 10:34]:
> We could add a new command to the server-client protocol, and make
> emacsclient send this command when invoked with the (hypothetical) new
> command-line option.

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?


>> 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.
>
> 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.

Ciao; Gregor
--
 -... --- .-. . -.. ..--.. ...-.-

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

[Eli Zaretskii]

> From: Gregor Zattler <telegraph@gmx.net>
> Date: Fri, 22 Oct 2021 21:51:17 +0200
> 
> Hi Eli, emacs developers,
> * Eli Zaretskii <eliz@gnu.org> [2021-10-21; 10:34]:
> > We could add a new command to the server-client protocol, and make
> > emacsclient send this command when invoked with the (hypothetical) new
> > command-line option.
> 
> 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.

> >> 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.
> >
> > 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.

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

[Gregor Zattler]

Hi Eli, emacs developers,
* Eli Zaretskii <eliz@gnu.org> [2021-10-23; 09:23]:
>> From: Gregor Zattler <telegraph@gmx.net>
>> Date: Fri, 22 Oct 2021 21:51:17 +0200
>> * Eli Zaretskii <eliz@gnu.org> [2021-10-21; 10:34]:
>> > We could add a new command to the server-client protocol, and make
>> > emacsclient send this command when invoked with the (hypothetical) new
>> > command-line option.
>>
>> 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?  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!?


>> >> 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.
>> >
>> > 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.  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.

Ciao; Gregor
--
 -... --- .-. . -.. ..--.. ...-.-

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

[Eli Zaretskii]

> From: Gregor Zattler <telegraph@gmx.net>
> 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.

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

[Gregor Zattler]

Hi Eli, emacs devs,
* Eli Zaretskii <eliz@gnu.org> [2021-10-23; 11:23]:
>> From: Gregor Zattler <telegraph@gmx.net>
>> Date: Sat, 23 Oct 2021 09:45:00 +0200
>> 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.

To me it would be confusing, if the last emacsclient exiting
from the server kills it, if there is not such command-line
option in it's invocation.  It could be quite a while since
the client which signals this to the server is exited.  Both
emacsclient invocations could be buried in some scripts,
effectively started via desktop events.  This could lead to
situations where the user does not know why the server died
and which are hard to debug.


[...]
>> 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?

Depends on the shell script.  E.g. `crontab -e' calls
$EDITOR or $VISUAL and that's were one would want to edit a
config file.  That's not a problem for me, because I see no
point in using the discussed feature.  I simply want to
state, that adaptions are necessary in both cases.

> 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.

Yes.  I consider this to be a bug, see bug#51360.

Ciao; Gregor
--
 -... --- .-. . -.. ..--.. ...-.-

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

[Gregory Heytings]

>
> I've been experimenting with using `emacs --daemon' and found one part 
> of it to be somewhat surprising. If I set `ALTERNATE_EDITOR' to the 
> empty string and run emacsclient, it runs `emacs --daemon' and connects 
> to it; so far so good. But when I close the Emacs client, the Emacs 
> daemon sticks around; I'd prefer the daemon to stop as well.
>

Just add

(when (daemonp) (run-with-timer 2 2 (lambda () (unless server-clients (save-buffers-kill-emacs)))))

to your init file.

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

[Jim Porter]

On 10/21/2021 11:41 PM, Eli Zaretskii wrote:
>> Cc: me@xenu.pl, emacs-devel@gnu.org
>> From: Jim Porter <jporterbugs@gmail.com>
>> Date: Thu, 21 Oct 2021 19:42:23 -0700
>>
>> I hope an example will illustrate what I mean[1]. I start with two
>> terminals open, A and B[2]. In terminal A, I run `emacs -nw foo.txt'. In
>> terminal B, I run `emacsclient -nw -c bar.txt'. Now, suppose I want to
>> stop editing foo.txt in terminal A and go back to doing something else.
>> I'd type `C-x C-c', but then my emacsclient in terminal B will close too.
> 
> No, it should say the session has client, and ask for confirmation.
> 
> You also have C-z to temporarily suspend the session on A.

Right. I glossed over those parts in an attempt to keep my explanation 
concise.

This was just an example to show how `emacsclient 
--alternate-editor=emacs' requires the initial `emacs' process to live 
as long as all the other clients. This isn't a bug, just an illustration 
of a case where I prefer the way `emacs --daemon' works.

>> However, using the daemon configuration with ALTERNATE_EDITOR="", I
>> could run `emacsclient -nw -c ...' in each terminal. Then when I type
>> `C-x C-c' in terminal A, it only kills that client, not the daemon
>> process. I can then continue to edit in terminal B without interruption.
>>
>> Of course, this isn't a bug, it's just how emacs and emacsclient work
>> together when not using `emacs --daemon'. It just turned out to be
>> inconvenient for how I use Emacs, so I've moved to using `emacs
>> --daemon' instead.
> 
> Which is exactly why we provided the daemon mode, so I see no problem
> here, I see a solution for a particular class of use patterns.

Agreed. There's nothing *wrong* with this behavior per se; I was just 
trying to explain why I prefer how `emacs --daemon' works for my use 
pattern.

- Jim

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

[Gregory Heytings]

>> I've been experimenting with using `emacs --daemon' and found one part 
>> of it to be somewhat surprising. If I set `ALTERNATE_EDITOR' to the 
>> empty string and run emacsclient, it runs `emacs --daemon' and connects 
>> to it; so far so good. But when I close the Emacs client, the Emacs 
>> daemon sticks around; I'd prefer the daemon to stop as well.
>
> Just add
>
> (when (daemonp) (run-with-timer 2 2 (lambda () (unless server-clients 
> (save-buffers-kill-emacs)))))
>
> to your init file.
>

Even better (because it also works with emacsclient -n):

(when (daemonp) (run-with-timer 2 2 (lambda () (when (<= (length (frame-list)) 1) (save-buffers-kill-emacs)))))

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

[Gregory Heytings]

>
> Even better (because it also works with emacsclient -n):
>
> (when (daemonp) (run-with-timer 2 2 (lambda () (when (<= (length (frame-list)) 1) (save-buffers-kill-emacs)))))
>

Slightly improved and submitted in bug#51377.

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

[Jim Porter]

On 10/22/2021 4:58 AM, Stefan Monnier wrote:
>> This would allow for a behavior similar to other (graphical) programs: if
>> I run `firefox example.com', it starts a new instance as normal. If I run it
>> again, it opens a new tab in the existing instance. If I close all the
>> Firefox windows, all the associated processes terminate.
> 
> I guess it would make sense to try and distinguish the two cases:
> 
> - Eager: `emacs --daemon` is run (typically from something like a login
>    script or systemd) before any emacsclient is involved.
> - Lazy: `emacs --daemon` is started on-demand by the `-a` option
>    of `emacsclient` (or via ALTERNATE_EDITOR).
> 
> In the lazy case, we could kill the daemon when the last client exits.

I posted a series of patches going this route here: 
<https://lists.gnu.org/archive/html/bug-gnu-emacs/2021-10/msg02184.html> 
(see also my followups in that bug).

To briefly summarize, I added a `--lazy-daemon' flag that indicates the 
(background) daemon was started on-demand, and then consult that via a 
new function `daemon-type' to adjust the behavior. There's probably more 
work to be done with that (e.g. customization options for users to tweak 
the behavior to their preferences), but it works for me so far.

Hopefully with actual patches showing what I'd like, it'll be easier for 
people to see precisely what behavior I'm after. Of course, if no one 
else has any interest in things working this way, then it might not make 
sense to merge the patches. No matter what, I can always take the Lisp 
portions for my own configuration so that things work the way I want.

- Jim

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

[Jean Louis]

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

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

[Jean Louis]

* Stefan Monnier <monnier@iro.umontreal.ca> [2021-10-22 14:59]:
> > This would allow for a behavior similar to other (graphical) programs: if
> > I run `firefox example.com', it starts a new instance as normal. If I run it
> > again, it opens a new tab in the existing instance. If I close all the
> > Firefox windows, all the associated processes terminate.
> 
> I guess it would make sense to try and distinguish the two cases:
> 
> - Eager: `emacs --daemon` is run (typically from something like a login
>   script or systemd) before any emacsclient is involved.
> - Lazy: `emacs --daemon` is started on-demand by the `-a` option
>   of `emacsclient` (or via ALTERNATE_EDITOR).
> 
> In the lazy case, we could kill the daemon when the last client exits.

Can the variable `server-clients' help to detect how many clients are there? 

Then if so, one can make Emacs Lisp function and put in
configuration file, then such user can have the Emacs Daemon
killed if last client is closed.



-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/fs

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

[Jean Louis]

* Gregory Heytings <gregory@heytings.org> [2021-10-23 22:58]:
> 
> > 
> > I've been experimenting with using `emacs --daemon' and found one part
> > of it to be somewhat surprising. If I set `ALTERNATE_EDITOR' to the
> > empty string and run emacsclient, it runs `emacs --daemon' and connects
> > to it; so far so good. But when I close the Emacs client, the Emacs
> > daemon sticks around; I'd prefer the daemon to stop as well.
> > 
> 
> Just add
> 
> (when (daemonp) (run-with-timer 2 2 (lambda () (unless server-clients (save-buffers-kill-emacs)))))
> 
> to your init file.

I did not see your message, this is exact idea I had, you have already
written it, but did you test it? Does it work?


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

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

[Gregory Heytings]

>
> I did not see your message, this is exact idea I had, you have already 
> written it, but did you test it? Does it work?
>

There's a improved version in bug#51377, which also checks whether there 
are unsaved file-visiting modified buffers and running processes before 
killing the daemon.  And yes, it works.

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

[Jim Porter]

On 10/24/2021 11:11 PM, Jean Louis wrote:
> Why in particular don't you use continuously the Emacs daemon if you
> are already invoking many times emacsclient?

Beyond it just being what I'm used to, the main reason is that I prefer 
to close Emacs when I'm done working on whatever it is I was doing, so 
that when I reopen it later, I have a fresh session with nothing open. 
(I could use `desktop-clear' to do this, but since, in my usage, I'm 
already closing all the Emacs frames to get them out of my way, that 
would just be an extra step I need to remember to do.)

> 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.

In the age of web apps, that's less true than it was before. I may well 
be editing a file in a browser, composing an email, posting on a forum, 
etc. In "richer" web apps, these might auto-save for you if you leave 
the page, but many sites will just prompt you to save or discard your 
work in progress if you close the browser. This behavior is what I've 
customized my Emacs configuration to do.

> 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.

That's why, in my patch[1], I call `save-buffers-kill-emacs' to kill the 
daemon when the last client frame is closed. That way, I'm prompted 
before the daemon stops, and can either save my work or change my mind 
and leave some Emacs frames open.

This has the additional benefit for me that if I shut down my system, I 
generally close all the windows first (or the OS does this for me), 
which means that when the last Emacs frame is closed, I'm prompted to 
save my unfinished work. If I had my configuration set to leave the 
daemon alive and not bother prompting to save when closing the last 
frame, I could still lose my unfinished work when the system actually 
reboots.

That loss of work could probably be resolved via `desktop-mode', but as 
mentioned above, I much prefer having a "fresh" Emacs session when I 
start it up.

- Jim

[1] 
https://lists.gnu.org/archive/html/bug-gnu-emacs/2021-10/msg02184.html 
and https://lists.gnu.org/archive/html/bug-gnu-emacs/2021-10/msg02209.html

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

[Jim Porter]

On 10/24/2021 11:19 PM, Jean Louis wrote:
> * Stefan Monnier <monnier@iro.umontreal.ca> [2021-10-22 14:59]:
>> I guess it would make sense to try and distinguish the two cases:
>>
>> - Eager: `emacs --daemon` is run (typically from something like a login
>>    script or systemd) before any emacsclient is involved.
>> - Lazy: `emacs --daemon` is started on-demand by the `-a` option
>>    of `emacsclient` (or via ALTERNATE_EDITOR).
>>
>> In the lazy case, we could kill the daemon when the last client exits.
> 
> Can the variable `server-clients' help to detect how many clients are there?
> 
> Then if so, one can make Emacs Lisp function and put in
> configuration file, then such user can have the Emacs Daemon
> killed if last client is closed.

Yup, that's what I'm doing now. I use a slightly-tweaked version of the 
patch I posted to bug#51377[1] in my configuration. While I'm happy with 
my configuration now, I wanted to propose adding those changes to Emacs 
itself (with options to tweak the behavior as appropriate) if others 
would find it useful.

- Jim

[1] https://lists.gnu.org/archive/html/bug-gnu-emacs/2021-10/msg02209.html

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

[Peter Oliver]

> > This would allow for a behavior similar to other (graphical) programs: if
> > I run `firefox example.com', it starts a new instance as normal. If I run it
> > again, it opens a new tab in the existing instance. If I close all the
> > Firefox windows, all the associated processes terminate.
> 
> I guess it would make sense to try and distinguish the two cases:
> 
> - Eager: `emacs --daemon` is run (typically from something like a login
>   script or systemd) before any emacsclient is involved.
> - Lazy: `emacs --daemon` is started on-demand by the `-a` option
>   of `emacsclient` (or via ALTERNATE_EDITOR).
> 
> In the lazy case, we could kill the daemon when the last client exits.

The lazy behaviour seems suitable for the new emacsclient.desktop we have in Emacs 28, too.

-- 
Peter Oliver

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

[chad]

[-- Attachment #1: Type: text/plain, Size: 592 bytes --]

On Sun, Oct 24, 2021 at 8:18 AM Gregory Heytings <gregory@heytings.org>
wrote:

>
> >
> > Even better (because it also works with emacsclient -n):
> >
> > (when (daemonp) (run-with-timer 2 2 (lambda () (when (<= (length
> (frame-list)) 1) (save-buffers-kill-emacs)))))
> >
>
> Slightly improved and submitted in bug#51377.
>

Apologies for the thread necromancy; I was away for a long while. While
catching up, I wondered if there was an appropriate hook to use, rather
than a timer. I think that delete-frame-functions may DTRT, but it depends
a bit on the use case.

Hope that helps,
~Chad

[-- Attachment #2: Type: text/html, Size: 975 bytes --]