Re: Pretest

[David Kastrup <dak@gnu.org>]

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.

> 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.

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


-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum