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

[Stefan Monnier]

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

> If you're not going to worry about the non-interactive use, there's no
> need of using another command. Ulrich's original proposal, asking the
> user, would be better IMHO.  (Of course, noninteractive == t would
> turn it off.)

I usually prefer it if the command just fails and lets the user run some
other command to do what she wants.  Sometimes asking the question is
a better option, but here I don't thinkg that its worth it.  The main
problem with asking a question is that it's modal.

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

> Sorry, I don't understand. Do you mean that the documentation would
> say "t, nil, other", but we would return t, nil, and other values that
> give a hint (like not-sure, or remote), or do you mean that we return
> t, nil, other, and the caller must know what to do? I prefer the
> second option.

Second option is fine.

>> As for process name, I'd rather not check the name of the process.
> I'd guess (out of the blue sky) than in a heavily used system the
> probability of a process ID collision between a long-dead process and
> a new one is significant. I'd feel safer checking the name and adding
> a note to the docstring about the dangers of running Emacs servers
> with atypical names. But it is your call, I'll implement what you
> decide.

Most/all Unix locks based on process-ids (like the ones used by Emacs,
for example) don't pay attention to the process name.  So experience
shows it's usually good enough.
We can also reduce the likelihood of leaving behind some obsolete
socket/file using kill-emacs-hook.


        Stefan