Re: Pretest

[David Kastrup <dak@gnu.org>]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

> David Kastrup wrote:

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

In Unix, fork is cheap.  The processes share the same code, and the
data starts out shared (the MMU sets it to read-only, and only when
one of the processes writes to it, a copy is created on which it then
works).  If the fork is done early in the life time of the process and
one of the forked processes touches only small amounts of data (which
would be the case here), the cost is negligible.  Similarly if after
the fork one of the processes does nothing much except change programs
by virtue of an exec call.

I am aware that Windows does not have fork with similar semantics,
which is why I then made a different proposal:

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

It has the advantage that it does not need to wait around, does not
need to rely on "server-start" getting fired up eventually and so on.
It bypasses the complete emacsserver business, and thus would be a
_reliable_ way to start an Emacs that can stay around even when the
socket stuff fails to work for some reason (permissions, file names,
whatever).

In addition, it would provide a separate "start Emacs, and simulate
finishing it when the user wants so" command which could conceivably
be useful in situations outside of the emacsclient/emacsserver
setting.

> For what reason do you want to avoid the wait for the server process
> to start the way I have implemented it?

Because it is not reliable.  It depends on actions in the started
Emacs that are not under the control of emacsclient, and it requires a
separate mechanism not transparent to the user apart from
--alternate-editor.

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

>From code complexity, emacsclient would just pass its options on to
the alternate editor, whether that is called emacsproxy or vi.

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

I'd prefer the approach where emacsclient does not depend on Emacs
server to start.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum