Re: Pretest

[David Kastrup]

Lennart Borgman <address@hidden> writes:

> David Kastrup wrote:
>
>> I'd prefer the approach where emacsclient does not depend on Emacs
>> server to start.
>
> With a little twist your suggestion would be very similar to mine.

Uh, you twist my proposal and then complain about the consequences of
the twist...

> The main part of your suggestion as I see it is that emacsclient
> wait on an intermediate process. This has the advantage that emacs
> could communicate with it and tell emacsclient about errors.

Uh no, it doesn't.  The whole point was that emacsproxy behaves just
like a blackbox that can be used instead of --alternate-editor.

> That is good. Something like this would have the benefits of both
> yours and my suggestion:
>
> 1) If emacsclient could not contact emacs server then it create the
> intermediate process. This then starts emacs and tells emacs to
> start emacs server with the required arguments.

My proposal was all about _not_ needing to start Emacs server in the
first place.  Instead, Emacs is set up such that server-quit will
_not_ attempt talking to some emacsclient, but will rather kill the
emacsproxy it was started from.

> 2) Emacsclient then wait for the intermediate process to
> disappear. After that it checks for errors.

My proposal was all about emacsclient starting the "emacsproxy" like
an editor, waiting for it to finish, and then considering the file
edited.

> 3) If there are errors then it tries to connect to the server again.

It does not need to connect to the server "again" since it never
connected to the server anyhow.

> However it requires some changes to the emacs executable and I do
> not believe it should be implemented now.

Hm.  It requires emacsproxy to call Emacs with something like

--eval '(setq server-proxy-process 54321)'

or probably something like

-f server-proxy-setup 54321

and server-quit to do something like
(signal-process server-proxy-process 'INT)
in an appropriate place.

That's not really "requiring changes to the Emacs executable" in my
book.

There is one utterly unrelated problem I see here: I don't see how
`signal-process' could work reliably on 32bit systems with 32bit
process ids.

Similarly, how would `process-id' work in that case?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum