Re: Pretest

[Lennart Borgman <lennart.borgman.073@student.lu.se>]

David Kastrup wrote:
> Lennart Borgman <lennart.borgman.073@student.lu.se> writes:
> 
>> David Kastrup wrote:
>>> Jason Rumney <jasonr@gnu.org> writes:
>>>
>>>> David Kastrup wrote:
>>>>> Jason Rumney <jasonr@gnu.org> 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.