Subject: bug#76870: 31.0.50; server-start with non-nil arg LEAVE-DEAD can write confusing warnings

From: Eli Zaretskii <[email-masked]>
Date: Sat, 08 Mar 2025 18:04:04 +0200

> Date: Sat, 08 Mar 2025 16:45:27 +0100
> From:  Jens Schmidt via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <[email-masked]>
> 
> * Simplified Reproducer
> 
> Start an Emacs session A with emacs -Q, start an Emacs server in that
> with M-x server-start RET.
> 
> Now start another Emacs session B with emacs -Q and evaluate the
> following with C-j in its *scratch* buffer:
> 
>   (require 'server)
>   server
> 
>   (server-start t)
>   nil
> 
> You get the same warnings as shown in the original reproducer.

What happens in this recipe is expected, and is not a bug.

> However, if there is an external Emacs server running in an Emacs
> session A, then `(server-start t)' from another session B obviously
> cannot just stop that server.  However, the warning issued in session B
> as quoted above mentions that the server cannot be *started*.

Which is the truth: server-start attempted to stop the (non-existent)
local server process, which silently succeeded, and then attempted to
start a new server process, which fails with the above message.

> 1. So I think in case of non-nil LEAVE-DEAD and a running external
>    server, a more appropriate warning would be:
> 
>      ⛔ Warning (server): Unable to stop an external Emacs server.
>      There is an existing Emacs server, named "server"
>      Stop it either in its Emacs session or call M-x server-force-delete to forcibly disconnect it.

This doesn't seem to be very different from the current message.  I
don't think the "in its Emacs session" part is significantly more
clear than "stop the existing server".

> 2. However, one could also argue that, if there is no local server
>    running, a call to `(server-start t)' should be completely silent.
>    That is at least what `(server-start t)' does if there is no server
>    (neither local nor external) running at all.
> 
> 3. Or at least it should be silent if called from a non-interactive
>    context as shown in the original reproducer.
> 
> 4. Or at the very least it should be silent if called from
>    `server-unload-function'.

The only bug here is 4.  Unloading the server feature should not cause
this warning.  All the rest is the intended behavior.