[Top][All Lists]

[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: Eli Zaretskii
Subject: Re: [RFC] Option to kill `emacs --daemon' when closing the last client frame
Date: Sat, 23 Oct 2021 11:23:21 +0300

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

reply via email to

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