From: Stefan Monnier <monnier@IRO.UMontreal.CA>
To: "Juanma Barranquero" <lekktu@gmail.com>
Cc: Eli Zaretskii <eliz@gnu.org>,
Ulrich Mueller <ulm@kph.uni-mainz.de>,
emacs-devel@gnu.org
Subject: Re: error in server-running-p on M$
Date: Wed, 10 Dec 2008 13:30:53 -0500 [thread overview]
Message-ID: <jwvvdtrubs3.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <f7ccd24b0812100459m32d27a23tf93cd9fdd8e493d8@mail.gmail.com> (Juanma Barranquero's message of "Wed, 10 Dec 2008 13:59:13 +0100")
>> 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
next prev parent reply other threads:[~2008-12-10 18:30 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-22 11:44 error in server-running-p on M$ dhruva
2008-11-22 11:58 ` Juanma Barranquero
2008-11-22 12:51 ` Eli Zaretskii
2008-11-22 13:00 ` Juanma Barranquero
2008-11-22 13:20 ` Eli Zaretskii
2008-11-22 13:37 ` Juanma Barranquero
2008-11-22 13:53 ` Eli Zaretskii
2008-11-22 14:13 ` Ulrich Mueller
2008-11-22 14:17 ` Juanma Barranquero
2008-11-22 14:29 ` Ulrich Mueller
2008-11-22 14:36 ` Juanma Barranquero
2008-11-22 15:35 ` Ulrich Mueller
2008-11-22 16:04 ` Juanma Barranquero
2008-11-22 16:52 ` Ulrich Mueller
2008-11-22 21:47 ` Juanma Barranquero
2008-11-23 3:56 ` dhruva
2008-11-23 3:59 ` Juanma Barranquero
2008-11-23 4:01 ` dhruva
2008-11-23 4:03 ` Juanma Barranquero
2008-11-23 4:10 ` dhruva
2008-11-23 4:15 ` Juanma Barranquero
2008-11-23 4:17 ` dhruva
2008-11-23 4:19 ` Juanma Barranquero
2008-11-23 8:14 ` Server protocol (was: Re: error in server-running-p on M$) Ulrich Mueller
2008-11-23 11:33 ` Juanma Barranquero
2008-11-23 16:33 ` dhruva
2008-11-23 17:48 ` Juanma Barranquero
2008-11-23 4:02 ` error in server-running-p on M$ Stefan Monnier
2008-11-23 4:10 ` Juanma Barranquero
2008-11-23 5:21 ` Stefan Monnier
2008-11-23 5:32 ` Juanma Barranquero
2008-11-23 5:57 ` Stefan Monnier
2008-11-23 11:26 ` Juanma Barranquero
2008-11-23 12:46 ` Juanma Barranquero
2008-11-23 13:13 ` Ulrich Mueller
2008-11-24 2:55 ` Stefan Monnier
2008-11-24 14:46 ` Juanma Barranquero
2008-11-24 15:10 ` Ulrich Mueller
2008-11-24 15:16 ` Juanma Barranquero
2008-11-24 15:34 ` Ulrich Mueller
2008-11-24 15:45 ` Juanma Barranquero
2008-12-09 20:46 ` Stefan Monnier
2008-12-10 7:05 ` Chetan Pandya
2008-12-10 12:59 ` Juanma Barranquero
2008-12-10 18:30 ` Stefan Monnier [this message]
2008-12-10 18:47 ` Juanma Barranquero
2008-12-11 2:07 ` Stefan Monnier
2008-12-11 16:30 ` Juanma Barranquero
2008-12-11 18:47 ` Stefan Monnier
2008-12-12 0:40 ` Juanma Barranquero
2008-12-12 4:51 ` Stefan Monnier
2008-12-12 8:19 ` Juanma Barranquero
2008-12-12 18:49 ` Stefan Monnier
2008-12-12 20:20 ` Juanma Barranquero
2008-11-23 3:58 ` Stefan Monnier
2008-11-23 3:59 ` Stefan Monnier
2008-11-23 4:12 ` Juanma Barranquero
2008-11-23 5:19 ` Stefan Monnier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvvdtrubs3.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=lekktu@gmail.com \
--cc=ulm@kph.uni-mainz.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).