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: Mon, 20 Nov 2006 00:31:18 +0100 Message-ID: <85lkm7814p.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> <857ixr9ke7.fsf@lola.goethe.zz> <4560D570.9060103@student.lu.se> <85y7q783ak.fsf@lola.goethe.zz> <4560E279.9050700@student.lu.se> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1163979128 31220 80.91.229.2 (19 Nov 2006 23:32:08 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 19 Nov 2006 23:32:08 +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:32:06 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 1Glw8k-0003c3-RH for ged-emacs-devel@m.gmane.org; Mon, 20 Nov 2006 00:31:59 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Glw8k-0001Wl-BB for ged-emacs-devel@m.gmane.org; Sun, 19 Nov 2006 18:31:58 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Glw8R-0001Tl-DJ for emacs-devel@gnu.org; Sun, 19 Nov 2006 18:31:39 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Glw8Q-0001SZ-9g for emacs-devel@gnu.org; Sun, 19 Nov 2006 18:31:38 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Glw8Q-0001SJ-0X for emacs-devel@gnu.org; Sun, 19 Nov 2006 18:31:38 -0500 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.52) id 1Glw8P-0008GX-Rl for emacs-devel@gnu.org; Sun, 19 Nov 2006 18:31:37 -0500 Original-Received: from localhost ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.34) id 1Glw8M-0005Zk-Rr; Sun, 19 Nov 2006 18:31:36 -0500 Original-Received: by lola.goethe.zz (Postfix, from userid 1002) id 621811C4D3DE; Mon, 20 Nov 2006 00:31:18 +0100 (CET) Original-To: Lennart Borgman In-Reply-To: <4560E279.9050700@student.lu.se> (Lennart Borgman's message of "Mon\, 20 Nov 2006 00\:02\:17 +0100") 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:62513 Archived-At: Lennart Borgman writes: > David Kastrup wrote: >> 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? In Unix, fork is cheap. The processes share the same code, and the data starts out shared (the MMU sets it to read-only, and only when one of the processes writes to it, a copy is created on which it then works). If the fork is done early in the life time of the process and one of the forked processes touches only small amounts of data (which would be the case here), the cost is negligible. Similarly if after the fork one of the processes does nothing much except change programs by virtue of an exec call. I am aware that Windows does not have fork with similar semantics, which is why I then made a different proposal: >> 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. It has the advantage that it does not need to wait around, does not need to rely on "server-start" getting fired up eventually and so on. It bypasses the complete emacsserver business, and thus would be a _reliable_ way to start an Emacs that can stay around even when the socket stuff fails to work for some reason (permissions, file names, whatever). In addition, it would provide a separate "start Emacs, and simulate finishing it when the user wants so" command which could conceivably be useful in situations outside of the emacsclient/emacsserver setting. > For what reason do you want to avoid the wait for the server process > to start the way I have implemented it? Because it is not reliable. It depends on actions in the started Emacs that are not under the control of emacsclient, and it requires a separate mechanism not transparent to the user apart from --alternate-editor. > 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. >>From code complexity, emacsclient would just pass its options on to the alternate editor, whether that is called emacsproxy or vi. > 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. I'd prefer the approach where emacsclient does not depend on Emacs server to start. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum