[Top][All Lists]

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

Re: Pretest

From: Lennart Borgman
Subject: Re: Pretest
Date: Sun, 19 Nov 2006 23:06:40 +0100
User-agent: Thunderbird (Windows/20061025)

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?

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?

reply via email to

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