Re: error in server-running-p on M$

[Stefan Monnier]

>> As Ulrich points out, we should make sure that we can always somehow
>> start a server.
> OK, but how do you want to do this? Another argument to server-start?
> A configuration variable? What about interactive use?

A config var doesn't sound right.  Programmatically, there's no need to
do anything special.  The problem is for interactive use.  I don't have
a good solution to propose just now, we could just say "to force-start
a sever first do M-x server-force-delete and then M-x server-mode".

> This is getting confusing, so let's sort the cases:

>  1) local socket, client process works => sure, server -> t
>  2) local socket, client process fails => sure, no server -> nil
>  3) TCP sockets, no server file => sure, no server -> nil
>  4) TCP sockets, not 127.0.0.1 => not sure -> remote
>  5) TCP sockets, 127.0.0.1, no process with PID => not sure (could be
> shared dir) -> not-sure
>  6) TCP sockets, 127.0.0.1, process PID, no "emacs" -> not sure (like
> above) -> not-sure
>  7) TCP sockets, 127.0.0.1, process PID, "emacs" -> sure (sort of) -> t

> Now the `t' cases are clear and safe (don't delete the server file),
> and the `nil' ones are too (delete the file, if exists).

> You're suggesting that 4 should return `remote' and be treated like
> `nil' (delete). But 5 and 6 could also be remote, and they must also
> be treated like `nil' (delete), or they won't be useful at all. So,
> there's no real distinction between `remote' and `not-sure', and
> `remote' does not even carry useful information (we could return
> not-sure for some remote servers).

> Now, to be really safe, 5) should be not-sure, but delete, and 6)
> should be not-sure, and don't delete (because Emacs could be running
> with another name).

> Thoughts?

That sounds about right.  The doc could simply say "t, nil, other" where
"other" means that we're not sure and the value returned might give
a hint about why we're not sure.

As for process name, I'd rather not check the name of the process.


        Stefan