From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Lennart Borgman Newsgroups: gmane.emacs.devel Subject: Re: Pretest Date: Mon, 20 Nov 2006 00:02:17 +0100 Message-ID: <4560E279.9050700@student.lu.se> 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> <857ixr9ke7.fsf@lola.goethe.zz> <4560D570.9060103@student.lu.se> <85y7q783ak.fsf@lola.goethe.zz> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1163977396 27005 80.91.229.2 (19 Nov 2006 23:03:16 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 19 Nov 2006 23:03:16 +0000 (UTC) Cc: Juanma Barranquero , Nick Roberts , emacs-devel@gnu.org, Jason Rumney Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 20 00:03:13 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 1Glvgn-0006a0-4k for ged-emacs-devel@m.gmane.org; Mon, 20 Nov 2006 00:03:05 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Glvgm-0001Lw-Kp for ged-emacs-devel@m.gmane.org; Sun, 19 Nov 2006 18:03:04 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GlvgH-000174-CO for emacs-devel@gnu.org; Sun, 19 Nov 2006 18:02:33 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GlvgD-00012X-H9 for emacs-devel@gnu.org; Sun, 19 Nov 2006 18:02:31 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GlvgD-00012A-A7 for emacs-devel@gnu.org; Sun, 19 Nov 2006 18:02:29 -0500 Original-Received: from [80.76.149.212] (helo=ch-smtp01.sth.basefarm.net) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1GlvgA-0002gw-FW; Sun, 19 Nov 2006 18:02:26 -0500 Original-Received: from [83.254.145.24] (port=62153 helo=[192.168.123.121]) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.63) (envelope-from ) id 1Glvg2-0003bV-3k; Mon, 20 Nov 2006 00:02:21 +0100 User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) Original-To: David Kastrup In-Reply-To: <85y7q783ak.fsf@lola.goethe.zz> X-Scan-Result: No virus found in message 1Glvg2-0003bV-3k. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1Glvg2-0003bV-3k 8a3d54e81788e4dcc3708a2bd43f660a 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:62512 Archived-At: David Kastrup wrote: > Lennart Borgman writes: > >> David Kastrup wrote: >>> 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. >> >> I am trying to understand what you mean here, but I fail. Is this >> perhaps something that can be done with X Windows? > > Nothing to do with X11. Thanks. >> And what issues do you mean when you write "waiting for server-start >> issues"? Is it perhaps those I hope I have solved in my code? > > You want to start an Emacs if it is not present, detach it so that its > life time does not depend on emacsserver, wait until it has started a > server (if it does so in the first place), then connect to it, tell it > what buffer to edit, and ask it to tell you when this is done. > > I am proposing that instead one uses something like > > emacsclient -a "emacs -delayed-detach" > > where emacsclient does not actually have a clue that it has started an > Emacs, and does not try talking to it. Instead it waits until emacs > dies. What emacs does instead would, in Unixspeak, be to fork. The > child would then detach itself from the controlling terminal, take the > command line options and start an almost normal Emacs life. When the > user executed a "server-done", however, the child would kill its > parent which would then exit. But would not the fork used in this way mean that we during "waited editing" has two emacs processes (or more)? Would not that defeat some of the benefits of emacs server? > Now under Windows this forking stuff does not work IIRC. Once one > starts a big process like Emacs, it is not cheap to start another copy > from inside. > > So instead of "emacs -delayed-detach" one would rather start something > like "emacsproxy" with the command line arguments. > > emacsproxy would then start the proper Emacs process with its command > line, and the proper Emacs process would, upon getting "server-done" > executed by the user, kill the emacsproxy process. > > So the invocation for emacsclient would be something like > > emacsclient -a emacsproxy Thanks, I believe I understand this part, but it is quite a bit more complicated than what I actually have implemented. For what reason do you want to avoid the wait for the server process to start the way I have implemented it? Doing it that way means that emacsclient always communicates with emacs server in the same way and I think that is very important from a code complexity point of view. One drawback I can see is that you can not know for sure if the server ever starts. Therefore I have added a simple timeout for how long emacsclient waits for emacs server to start.