From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: error in server-running-p on M$ Date: Wed, 10 Dec 2008 21:07:12 -0500 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1228961255 19087 80.91.229.12 (11 Dec 2008 02:07:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 11 Dec 2008 02:07:35 +0000 (UTC) Cc: Eli Zaretskii , Ulrich Mueller , emacs-devel@gnu.org To: "Juanma Barranquero" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 11 03:08:38 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1LAayj-0004Pt-8F for ged-emacs-devel@m.gmane.org; Thu, 11 Dec 2008 03:08:37 +0100 Original-Received: from localhost ([127.0.0.1]:58689 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LAaxY-0006gy-3K for ged-emacs-devel@m.gmane.org; Wed, 10 Dec 2008 21:07:24 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LAaxR-0006dl-Tg for emacs-devel@gnu.org; Wed, 10 Dec 2008 21:07:17 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LAaxP-0006Z0-BU for emacs-devel@gnu.org; Wed, 10 Dec 2008 21:07:16 -0500 Original-Received: from [199.232.76.173] (port=59643 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LAaxP-0006Yt-6l for emacs-devel@gnu.org; Wed, 10 Dec 2008 21:07:15 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:39041) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LAaxN-00068D-In; Wed, 10 Dec 2008 21:07:13 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAO0DQElMCrcb/2dsb2JhbACBbMUegwaBLA X-IronPort-AV: E=Sophos;i="4.33,749,1220241600"; d="scan'208";a="30906393" Original-Received: from 76-10-183-27.dsl.teksavvy.com (HELO pastel.home) ([76.10.183.27]) by ironport2-out.teksavvy.com with ESMTP; 10 Dec 2008 21:07:13 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 2DA8B8224; Wed, 10 Dec 2008 21:07:12 -0500 (EST) In-Reply-To: (Juanma Barranquero's message of "Wed, 10 Dec 2008 19:47:52 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:106784 Archived-At: >> 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