From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Pretest Date: Sun, 19 Nov 2006 22:49:52 +0100 Message-ID: <857ixr9ke7.fsf@lola.goethe.zz> References: <87slggjtbb.fsf@furball.mit.edu> <455F9024.8080000@student.lu.se> <17759.43936.82301.353794@kahikatea.snap.net.nz> <85irhbg6zx.fsf@lola.goethe.zz> <17760.11257.78362.216206@kahikatea.snap.net.nz> <85wt5reo3b.fsf@lola.goethe.zz> <17760.17309.553008.718144@kahikatea.snap.net.nz> <85slgfcy5v.fsf@lola.goethe.zz> <45606E21.9030000@student.lu.se> <45609A48.2080905@gnu.org> <4560B581.3030201@gnu.org> <851wnzb1sz.fsf@lola.goethe.zz> <4560CDBD.3080308@gnu.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1163973673 17580 80.91.229.2 (19 Nov 2006 22:01:13 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 19 Nov 2006 22:01:13 +0000 (UTC) Cc: Juanma Barranquero , Lennart Borgman , Nick Roberts , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 19 23:01:10 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Gluir-0001Rl-KN for ged-emacs-devel@m.gmane.org; Sun, 19 Nov 2006 23:01:09 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Gluir-0005c9-98 for ged-emacs-devel@m.gmane.org; Sun, 19 Nov 2006 17:01:09 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Gluic-0005Zm-En for emacs-devel@gnu.org; Sun, 19 Nov 2006 17:00:54 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Gluib-0005YQ-NB for emacs-devel@gnu.org; Sun, 19 Nov 2006 17:00:53 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Gluib-0005YD-FI for emacs-devel@gnu.org; Sun, 19 Nov 2006 17:00:53 -0500 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GluYD-0004Rl-Os for emacs-devel@gnu.org; Sun, 19 Nov 2006 16:50:10 -0500 Original-Received: from localhost ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.34) id 1GluYC-0003n5-CZ; Sun, 19 Nov 2006 16:50:08 -0500 Original-Received: by lola.goethe.zz (Postfix, from userid 1002) id EEE9E1C4D3DE; Sun, 19 Nov 2006 22:49:52 +0100 (CET) Original-To: Jason Rumney In-Reply-To: <4560CDBD.3080308@gnu.org> (Jason Rumney's message of "Sun\, 19 Nov 2006 21\:33\:49 +0000") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.90 (gnu/linux) 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:62503 Archived-At: Jason Rumney writes: > David Kastrup wrote: >> Jason Rumney writes: >> >>>> In the most important use case, we DO want to wait. >>>> >> >> Why? > > Because most programs that launch an editor as a subprocess need to > know when editing has finished. So the "most important use case" according to you is basically a command line call, not a GUI call. That was not obvious to me. And we are talking about an emacsclient connection on Windows. When Emacs is already running, emacsclient will connect to Emacs and block while Emacs in its existing frame is working on a file. When one is finished working this file, Emacs would then get emacsclient to exit by telling it it quit. In order to mimic this behavior when Emacs is not already running, you want to have it started in a detached manner, then have emacsclient attach to it once its server is running, and have it exit when the Emacs server tells it to. Wouldn't it be saner if emacsclient just started Emacs (probably with a specific command line option), and when Emacs was finished with editing the respective buffer, it would detach itself from emacsclient which would then exit? That would obliterate all the waiting for server-start issues. It would just mean that server-buffers initiated from the command line instead of emacsclient would exit by detaching themselves from the controlling terminal instead of talking to emacsclient on a socket. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum