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: Gregor Zattler
Subject: Re: [RFC] Option to kill `emacs --daemon' when closing the last client frame
Date: Sat, 23 Oct 2021 20:41:12 +0200

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



reply via email to

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