[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Pretest

From: Lennart Borgman
Subject: Re: Pretest
Date: Mon, 20 Nov 2006 00:02:17 +0100
User-agent: Thunderbird (Windows/20061025)

David Kastrup wrote:
Lennart Borgman <address@hidden> writes:

David Kastrup wrote:
Jason Rumney <address@hidden> writes:

David Kastrup wrote:
Jason Rumney <address@hidden> writes:
In the most important use case, we DO want to wait.
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.

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]